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

Hi Brian,

On 09/23/2013 08:40 AM, Brian Trammell 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. 

Yep. And that's tricky. Better wording is very welcome.

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

Well, we don't say that *use* of OE should be the default.
That is, we do not say "OE or better SHOULD be used."

I would like it if we did say that, but I don't think we'd
get IETF consensus for it. The current draft says only that
OE (or better) must be well-defined and leaves it to those
deploying as to whether that's turned on or not. (We could
probably make that clearer I guess, e.g. by saying that OE
or better is mandatory to implement.)

If there are folks who think that we should go further, (and
think that we could get IETF consensus for that,) then please
propose text. I do know there are folks who don't want us to
go that far on the basis that that'd mean the IETF would be
specifying policy and not just protocol. There are also folks
who do middleboxes of various kinds that'd probably be upset
too:-)

Cheers,
S.

> 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."
> 
> 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.
> 
> Cheers,
> 
> Brian
> 
> On Sep 20, 2013, at 6:36 PM, Stephen Farrell
> <stephen.farrell@cs.tcd.ie> wrote:
> 
>> 
>> FYI. Comments welcome.
>> 
>> S.
>> 
>> 
>> -------- Original Message -------- Subject: New Version
>> Notification for draft-cooper-ietf-privacy-requirements-00.txt 
>> Date: Fri, 20 Sep 2013 09:23:52 -0700 From:
>> internet-drafts@ietf.org To: Alissa Cooper <acooper@cdt.org>, Sean
>> Turner <turners@ieca.com>, Stephen Farrell
>> <stephen.farrell@cs.tcd.ie>
>> 
>> 
>> A new version of I-D,
>> draft-cooper-ietf-privacy-requirements-00.txt has been successfully
>> submitted by Alissa Cooper and posted to the IETF repository.
>> 
>> Filename:	 draft-cooper-ietf-privacy-requirements Revision:	 00 
>> Title:		 Privacy Requirements for IETF Protocols Creation date:
>> 2013-09-20 Group:		 Individual Submission Number of pages: 11 URL: 
>> http://www.ietf.org/internet-drafts/draft-cooper-ietf-privacy-requirements-00.txt
>>
>> 
Status:
>> http://datatracker.ietf.org/doc/draft-cooper-ietf-privacy-requirements
>>
>> 
Htmlized:
>> http://tools.ietf.org/html/draft-cooper-ietf-privacy-requirements-00
>>
>>
>>
>> 
Abstract:
>> It is the consensus of the IETF that IETF protocols be designed to 
>> avoid privacy violations to the extent possible.  This document 
>> establishes a number of protocol design choices as Best Current 
>> Practices for the purpose of avoiding such violations.
>> 
>> 
>> 
>> 
>> 
>> Please note that it may take a couple of minutes from the time of
>> submission until the htmlized version and diff are available at
>> tools.ietf.org.
>> 
>> The IETF Secretariat
>> 
>> 
>> 
>> _______________________________________________ perpass mailing
>> list perpass@ietf.org 
>> https://www.ietf.org/mailman/listinfo/perpass
> 
> 
> 
> _______________________________________________ ietf-privacy mailing
> list ietf-privacy@ietf.org 
> https://www.ietf.org/mailman/listinfo/ietf-privacy
> 