Subject: [perpass] Few things the IETF might standardize for secure collaboration

From: Cullen Jennings <[email-masked]>
Date: Sun, 20 Oct 2013 18:58:30 -0400

I've been thinking about how to build cloud collaborations systems where the data is encrypted and the cloud does not have the keys. Very interested in hearing others thoughts on how to do this. 

Near the end is a list of things that it would be helpful if the IETF standardized. 

http://www.ietf.org/id/draft-jennings-perpass-secure-rai-cloud-00.pdf

Cullen

---

From: Dan York <[email-masked]>
Date: Mon, 21 Oct 2013 12:11:03 +0000

Cullen,

On 10/20/13 6:58 PM, "Cullen Jennings" <[email-masked]> wrote:

>I've been thinking about how to build cloud collaborations systems where
>the data is encrypted and the cloud does not have the keys. Very
>interested in hearing others thoughts on how to do this.

Good document. In a quick read I naturally have to react to slide 23
(Trusting DNS) and also slide 11 (Certificate Authority).  On slide 23,
you say "Sorry, can't trust this yet.", but what happens as we get more
DNSSEC deployed?  We're already seeing increased validation within caching
resolvers and some measurements are showing around 8% of all DNS queries
coming from resolvers that perform validation.  We're seeing steady growth
in the number of DNSSEC-signed domains.  I know there are those who are
skeptical about DNSSEC deployment, but I'm definitely seeing real
growth... and see a number of trends pointing to that only continuing.

Similarly, on slide 11 you mention the ongoing issue that CA's can issue
bad certs and the goal is to detect this.  We do have an existing
mechanism that can help here.  DANE (RFC 6698) allows the zone operator to
include a fingerprint of a cert (or an entire cert) in a DNS zone and then
sign that with DNSSEC.  Couple that with DNSSEC-validating resolvers and
you've got a way to add an additional layer of trust assertions on top of
the CA infrastructure.  Sure, CAs can still issue bad certs, but if the
cert being offered doesn't match the cert fingerprint securely stored in
DNS then the endpoint should know right then to reject the bad cert.

Typo: slide 8 - I think you meant "in that you" - "The CA is "honest" is
that you can tell if it issues your certiﬁcate to someone else but there
is no way to stop it from doing that"

>Near the end is a list of things that it would be helpful if the IETF

Good list!
Dan

--
Dan York
Senior Content Strategist, Internet Society
[email-masked] <mailto:[email-masked]>   +1-802-735-1624
Jabber: [email-masked] <mailto:[email-masked]>
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/deploy360/

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 21 Oct 2013 06:32:51 -0700

> growth... and see a number of trends pointing to that only continuing.

DNSSEC has two huge issues and one huge potential (untapped) advantage.

Issue #1:  Validation at the wrong place.  Recursive resolver validation is of only small (but non-zero) utility: It allows countering packet-injection (NSA and their foreign competitors), which can otherwise be used to promote a man-on-the-side to a full man-in-the-middle.  But the recursive resolver itself is proven untrustworthy, so its not the point which should conduct validation.

And if clients are to validate in a mandatory way, they need to be able to get DNSSEC over an alternate means, as many clients can't get DNSSEC over the wire on UDP 53, many others can't get DNSSEC from the recursive resolver, and the combination (can't get either from the wire OR recursive resolver) is high enough that its in the "break 1%" category, which is generally regarded as unacceptable.

Issue #2:  The big threat against DNS, and the big reason you can't trust it, is that the major high-profile attacks have been attacks on the registrar.  DNSSEC does no good, because if you can social engineer the registrar, you can also get new DS records accepted.

Untapped advantage:  Multiple paths of trust.  If, say, TLS was modified to have multiple hostnames, eg
https://www.example.com/www.example.ru/

where the resulting certificate is fetched through DNSSEC, and BOTH domains must agree, in order for the connection to proceed.  This provides a very unique property: it requires that all paths-of-trust be compromised by the same cooperating entity.  That is

. -> .com -> example.com
. -> .ru -> example.ru

both must be compromised by the same entity.  

"I don't trust .com, I don't trust .ru, but I trust they won't collude against me" is a very interesting property that is unique to protocols built on top of DNSSEC-as-a-CA.

--
Nicholas Weaver                  it is a tale, told by an idiot,
[email-masked]                full of sound and fury,
510-666-2903                                 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Wed, 23 Oct 2013 19:18:59 -0400

Cullen,

Nice draft!  I have been thinking about this problem as well and wonder where the line is for those who want protections from monitoring.  What level of protection is needed so that the options we provide make sense and are actually used?  Do we need to go further and what is the demand?

In addition to your proposal, I am wondering if we need alternate algorithms when worried about these use cases (e.g. Twofish instead of AES, etc.).  Also, having the IdP as a service provider may be a showstopper for those concerned with monitoring, why couldn't that service provider be contacted as well?

The point at which encryption is performed is use case dependent.  You mention encryption at the client in the strategy slide, which is very important for this use case (not at the host or storage level).  I would suggest repeating this in the Encrypted Data Content slide - encryption at the client or 'guest' level.  Guest is another term I have been hearing, but I am not sure if it is a common term.

Thanks,
Kathleen 

Sent from my iPhone

On Oct 20, 2013, at 5:57 PM, "Cullen Jennings" <[email-masked]> wrote:

> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass
>

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 23 Oct 2013 22:18:28 -0600

On Oct 21, 2013, at 7:32 AM, Nicholas Weaver <[email-masked]> wrote:

> "I don't trust .com, I don't trust .ru, but I trust they won't collude against me" is a very interesting property

I have thought about this from a game theory point of view. Imagine a game where both player saw all the traffic pass though an under sea fiber optic cable. And then on some day in the future neither player can see any of the traffic unless they one player enables the other. Obviously if they both cooperated, they would be back the how it was at the start of the game. The question of if they will cooperate or not seems to me to depend on how they both use the data they used to get from the fiber optic cable, and the calculus of value of the information to them vs the value of the other player not having the information. 

I get your point but I'm pretty cautious about assumption of who will and will not cooperate when people feel the end result justifies pretty outrageous means of getting to the end result. That said, I'm a fan of the types of check and balances you get when more than one person has to behave badly.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 23 Oct 2013 22:23:42 -0600

HI Dan, 

inline …

> growth... and see a number of trends pointing to that only continuing.

No question that things are going the right direction. Let figure out how we could use this and likely when. In fairness it will take time to build something like I am proposing and DNSSEC will be better then than it is now. 

> DNS then the endpoint should know right then to reject the bad cert.

Using DANE for belt and suspenders on CAs seems good. I also think it would be well worth think about who is in the trust chain for a domain that was in .us vs say .cn and consider how that might all play out from security point of view. I had not thought much about this but it does deserve thinking about what we can do. 

> is no way to stop it from doing that"

oops - yes - The type of thing I was thinking about here are various proposal where CA publish all the certificates they have issued and there are various cryptographic hash chains that make it difficult for them to lie about this. That means a CA might be able to issue your cert to a bad guy but that it would later be possible to detect that. 

>> Near the end is a list of things that it would be helpful if the IETF

Tell me what to add to this list for DNSSEC / DANE that we are not already doing

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 23 Oct 2013 22:29:46 -0600

> Nice draft!  I have been thinking about this problem as well and wonder where the line is for those who want protections from monitoring.  What level of protection is needed so that the options we…

I'v been pitching we need to make it harder for the bad guys and easier for the good guys. I think the lowest hanging fruit right now is mostly in easier for the good guys. Lot so places we have no security because it is inconvenient. Opportunistic encryption for example might make it easier for the good guys to have some encryption even though it was not as good as authenticated encryption. I want to figure out how to make this all cheap and easy for the end user. 

> 
> In addition to your proposal, I am wondering if we need alternate algorithms when worried about these use cases (e.g. Twofish instead of AES, etc.).

I'm not a crypto guy but it seems someone needs to be thinking about this. I sort of mention the formation of a "Suite Z" for people that don't like "Suite B".

>  Also, having the IdP as a service provider may be a showstopper for those concerned with monitoring, why couldn't that service provider be contacted as well?

If Skype is both the service provide and the IdP, well this is not much different than the current situation. But if I could run my own IdP on hardware I trust, or my employer could run an IdP on a server they trust and I trust them, well that would make for a different model. 

> The point at which encryption is performed is use case dependent.  You mention encryption at the client in the strategy slide, which is very important for this use case (not at the host or storage…

Hmm - I'm not familiar with this "Guest" term in this context - can you explain more.

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Thu, 24 Oct 2013 09:11:54 -0400

Thanks for the quick response, comments in-line.

Thanks,
Kathleen 
-----Original Message-----
From: Cullen Jennings [mailto:[email-masked]] 
Sent: Thursday, October 24, 2013 12:30 AM
To: Moriarty, Kathleen
Cc: [email-masked]
Subject: Re: [perpass] Few things the IETF might standardize for secure collaboration

KM> Okay, that's a good goal and this may point to a question of what problems we try to solve in the area of monitoring or that the goal is clear for any of the proposals (not intending to call this one out at all).  We will wind up with different solutions if the focus is on preventing monitoring for those who are blissfully unaware from those who are actively seeking to prevent monitoring.  The latter may not what to trust anymore and may want to use alternate algorithms or add in more complex features to prevent monitoring without worry of configuration complexities or protocol overhead.  Their decisions may or may not be based on cryptographic analysis either.  

KM> I'm not a cryptographer either and a move in this direction (at this point - unless I missed some news) would be suspicion driven rather than through any actual analysis.  The people who are reading what has been published and have purchasing power may not be cryptographers either.  I have only heard of a few requests, so it would be interesting to observe trends in this area to see if something needs to be done so that alternate options are secure IF they are in demand.

KM> Okay, that model makes sense to me.  I asked the question because there is a new service already that offers key management from a service provider, supporting alternate algorithms so that the keys and encryption is not where your data is stored.  I can try to dig up the link.  Someone sent me it to review and my first take on that was if a customer was worried about monitoring, they would not want their keys at any service provider.  

KM> Essentially, the same as client in your description.  I was not sure if it was becoming a common term or if the terminology in that circle was unique :-)  It may very well be unique to them.