Thanks for the quick response, comments in-line. Thanks, Kathleen -----Original Message----- From: Cullen Jennings [mailto:[email protected]] Sent: Thursday, October 24, 2013 12:30 AM To: Moriarty, Kathleen Cc: [email protected] Subject: Re: [perpass] Few things the IETF might standardize for secure collaboration
On Oct 23, 2013, at 5:18 PM, "Moriarty, Kathleen" <[email protected]> wrote: > 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? 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. 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. > > 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". 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. > 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. 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. > > 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. Hmm - I'm not familiar with this "Guest" term in this context - can you explain more. 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. > > Thanks, > Kathleen > > Sent from my iPhone > > On Oct 20, 2013, at 5:57 PM, "Cullen Jennings" <[email protected]> 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. >> >> 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 >> >> _______________________________________________ >> perpass mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/perpass >> _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
