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

[Robin Wilton <[e-mail]>]

Hi all - 
On 24 Sep 2013, at 12:00, Stephen Farrell wrote:

> 
> Hi Eliot,
> 
> On 09/24/2013 11:41 AM, Eliot Lear wrote:
> 
>> It is worth noting that by
>> the use of the term, one could reasonably argue that TLS is
>> opportunistic encryption because the encryption is not prearranged in
>> advance by two parties.  
> 
> Ignoring the bare-keys TLS draft for the moment, that's not
> correct (and hence not reasonable:-)
> 
> The TLS client has to have a trust anchor to which the TLS
> server's cetificate chains. That is pre-arranged, in current
> browser implementations between the CAs, browsers and web-sites.

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).

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. 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. 

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".

HTH,
Robin