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

[Stephen Farrell <[e-mail]>]

Hi Eliot,

On 09/24/2013 11:41 AM, Eliot Lear wrote:
> 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. 

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

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

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

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

> And so this raises three questions:
> 
>  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.

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

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.

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

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf-privacy
>