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 _______________________________________________ ietf-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-privacy
