Re: [ietf-privacy] [perpass] New Version Notification for draft-cooper-ietf-privacy-requirements-00.txt

[Brian Trammell <[e-mail]>]

hi Alissa,

On 23 Sep 2013, at 16:32 , Alissa Cooper <[e-mail]> wrote:

> Hi Brian,
> 
> Thanks for your comments.
> 
> On Sep 23, 2013, at 3:40 AM, Brian Trammell <[e-mail]> wrote:
> 
>> hi Stephen, all,
>> 
>> (copying ietf-privacy as requested in the draft)
>> 
>> I've read the draft; it's a very good and welcome start at extending 6973 to a set of concrete recommendations for protocol design. I've got one comment on opportunistic encryption, though:
>> 
>> In section 3, halfway down the page: "...at minimum, opportunistic encryption needs to be well-defined for almost all new IETF standards track protocols." 
>> 
>> I understand the rationale behind that "almost", but the lines around it will need to be very clearly drawn. On brief consideration, I cannot think of a single _new_ protocol for which opportunistic encryption shouldn't be the default, for reasons other than interoperability with an existing protocol that has a significant installed base. Even in such cases, I think it would be useful to be very clear that communication in the clear for interoperability is an exception, a "legacy" mode, "to be deprecated", or other not-very-happy-sounding words that mean "we realize we're stuck with it in this case but that's really no excuse."
> 
> I have not been super comfortable with the "almost" either. I've been thinking instead of something like:
> 
> "As a consequence, at minimum, opportunistic encryption needs to be well-defined for new IETF standards track protocols. This requirement may be waved only in exceptional circumstances where the protocol's utility would be eliminated or severely diminished if opportunistic encryption were defined."

This is a better version of what I've been trying to come up with. (Nit: s/waved/waived/)

>> The information radiated even from protocols which have no obvious connection with personal data can be correlated with other information which can paint a very rich behavioral picture, that only takes one unprotected link in the chain to associate with an identity. Opportunistic encryption everywhere reduces the content of this radiated information, as well as reducing the risk of unprotected links holding some associable identifier. So exceptions will have to be very well justified if an aim of this work is protection of privacy against pervasive surveillance.
> 
> I'm not ready to ink this on my skin, but it does seem like good text to add to the document, with minimal tweaks. :)

Now that I've seen the direction this draft is going in, I'm hoping to get back to -perpass-ppa soon, to move it more in the direction of a catalog of information radiation to look for.

Cheers,

Brian