Re: [ietf-privacy] draft-cooper-ietf-privacy-requirements-00.txt

[Eliot Lear <[e-mail]>]

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