Thanks, Eliot… I suspected we were probably all pretty well aligned - I just wanted to draw out that point about explicit vs implicit requirements, rather than disagree with you. Especially about the contents of related RFCs, where your expertise far outstrips mine. ;^)
R Robin Wilton Technical Outreach Director - Identity and Privacy Internet Society email: [email protected] Phone: +44 705 005 2931 Twitter: @futureidentity On 24 Sep 2013, at 14:04, Eliot Lear wrote: > Hi Robin and Stephen, > > On 9/24/13 1:31 PM, Robin Wilton wrote: > >> I tend to Stephen's point of view here. Two parties cannot "bootstrap" a TLS >> session out of nothing. Even if the person on the client side apparently >> does nothing, at the time, to establish an encrypted rather than unencrypted >> session, there are pre-requisites that have to be in place (i.e. >> pre-arranged). > > Although he may not recognize it, I support Stephen's point of view as > well. I just don't think the document he cited does ;-) > >> >> This may seem like a nit-pick, but I have reasons for drawing attention to >> it, and TLS is a good 'case study'. What I've observed in PKI is that >> there's an inverse relationship between adoption volumes and the extent of >> functionality exposed to the user. Put bluntly, if you want PKI to scale, >> keep the user away from it. > > While I have tended to agree (it's a bit of a corollary to what I argued > in Section 5.4.1 in RFC 6837)... > >> At one level, there are sound reasons for that: if you leave it up to users, >> few can be bothered to fiddle with security settings, so the technology goes >> unused. However, there are also risks: the more you insulate the user from >> the realities of securing online interaction, the less likely they are to >> care whether it's happening or not; and, of course, the less likely they are >> to know if it is not happening at all. > > Indeed. Serge Egelman did some related research on this, involving a > popular mobile operating system.[1] >> >> So, I wanted to draw out this aspect because deployments in this area have >> to satisfy quite tricky, but implicit, requirements. Users need information >> that is reliable (a little padlock icon is not useful if it can easily be >> spoofed) and usable (too much detail scares users away; too little means >> they can't make informed decisions if necessary). This means we may have to >> design systems that *appear* opportunistic (such as establishing a TLS >> session with no apparent, explicit action on the part of the user) even >> though they may actually rely on a good deal of prior work to put the >> pre-reqs in place. >> >> Bottom line: we probably need to think carefully about how we define >> "opportunistic". >> > > And that's where I was heading. Moreover, nobody should take their eyes > off the prize when it comes to authenticate encryption. And that's why > the authors of RFC4432 didn't go there. > > Eliot > [1] http://www.guanotronic.com/~serge/papers/soups12-android.pdf
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ ietf-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-privacy
