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

From: Eliot Lear <[email-masked]>
Date: Tue, 24 Sep 2013 12:41:53 +0200

Hi,

I've done a bit of back and forth with Stephen elsewhere, and I have a
few comments about the draft.

Opportunistic encryption really means different things to different
people.  It is actually NOT well defined in RFC 4322, and in that case
they're referring to encryption between L3 endpoints where you retrieve
keying information from the DNS using the KEY record and DNSSEC.  That
is not what is implied by the following paragraph:

>    While existing principles call for strong security, it is important
>    to note that strong security only in cases where the other party can
>    be authenticated does not by itself solve all privacy problems.  To
>    guard against dangers of large-scale privacy attacks, some protection
>    is needed also for other situations.  As a consequence, at minimum,
>    opportunistic encryption needs to be well-defined for almost all new
>    IETF standards track protocols.  In most cases it will be better to
>    (also) specify how to do mutually authenticated encryption.
>    Encryption provides one aspect of privacy protection, namely
>    confidentiality.

That is to say, the concepts of opportunistic and authenticated or
unauthenticated encryption are orthogonal. 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.  If that is the bare minimum, then IMHO that is
largely what is intended by RFC 3365 already.  I more than suspect
that's not what the intent of this draft is.

And so this raises three questions:

 1. First, what is really meant by opportunistic encryption in this case?
 2. What are the appropriate approaches for opportunistic encryption? and
 3. What are the best practices  (i.e., "Do"s and "Don'ts"; after all,
    this is meant to be a BCP)?

Also, some protocols have evolved to allow for sharing of private
information, for better and worse.  There are tradeoffs associated with
privacy versus security (such as the benefit of a transparent malware
scanner).  These tradeoffs should be discussed in security considerations.

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 24 Sep 2013 12:00:18 +0100

Hi Eliot,

On 09/24/2013 11:41 AM, Eliot Lear wrote:
> unauthenticated encryption are orthogonal. 

Its a fair comment to say that we can probably do better describing
this.

> It is worth noting that by
> 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.

> If that is the bare minimum, then IMHO that is

Correct, we are aiming for more than is required by 3365.

>  1. First, what is really meant by opportunistic encryption in this case?

To be honest, I think that's clear already, but we can try hammer it
home:-) Or maybe someone has better text to suggest.

>     this is meant to be a BCP)?

I think both are matters for protocol designers and not really for
the BCP, at least at any level of detail. Given that this BCP is
aiming to still be useful in a decade, such details will change.
It would probably be good to add some more references to examples
though. We can go look for some, but suggestions welcome.

> scanner).  These tradeoffs should be discussed in security considerations.

Yes we need some text like that as alrady noted in the -00.
Send text! (Mind you, personally, I'd rather not get suggested
text that says that transparent HTTP proxies are super-duper
and that turning on encryption is horribly dangerous, but I'm
sure you wouldn't say that anyway:-)

S.

> 
> Eliot
> 
> 
> 
> 
> _______________________________________________
> ietf-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-privacy
>

---

From: Robin Wilton <[email-masked]>
Date: Tue, 24 Sep 2013 12:31:20 +0100

Hi all - 

> 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

---

From: Eliot Lear <[email-masked]>
Date: Tue, 24 Sep 2013 15:04:35 +0200

Hi Robin and Stephen,

> 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 encr…

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

---

From: Robin Wilton <[email-masked]>
Date: Tue, 24 Sep 2013 15:34:36 +0100

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-masked]
Phone: +44 705 005 2931
Twitter: @futureidentity