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

From: Stephen Farrell <[email-masked]>
Date: Fri, 20 Sep 2013 17:36:56 +0100

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: [email-masked]
To: Alissa Cooper <[email-masked]>, Sean Turner <[email-masked]>,
Stephen Farrell <[email-masked]>

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

---

From: Brian Trammell <[email-masked]>
Date: Mon, 23 Sep 2013 09:40:57 +0200

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

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 <[email-masked]> wrote:

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

---

From: Robin Wilton <[email-masked]>
Date: Mon, 23 Sep 2013 12:22:09 +0100

I am seriously considering trying to gain enough weight that I can fit this onto myself as a tattoo:

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

;^)

Robin

Robin Wilton

Technical Outreach Director - Identity and Privacy

On 23 Sep 2013, at 08:40, Brian Trammell <[email-masked]> wrote:

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

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 23 Sep 2013 13:24:25 +0100

Hi Brian,

On 09/23/2013 08:40 AM, Brian Trammell wrote:
> 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
> 
>> -------- Original Message -------- Subject: New Version
>> Notification for draft-cooper-ietf-privacy-requirements-00.txt 
>> Date: Fri, 20 Sep 2013 09:23:52 -0700 From:
>> [email-masked] To: Alissa Cooper <[email-masked]>, Sean
>> Turner <[email-masked]>, Stephen Farrell
>> <[email-masked]>
>> 
>> 
>> 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: 
Abstract:
>> 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 [email-masked] 
> _______________________________________________ ietf-privacy mailing
> list [email-masked]

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 23 Sep 2013 10:32:49 -0400

Hi Brian,

Thanks for your comments.

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

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

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

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

Alissa

---

From: Brian Trammell <[email-masked]>
Date: Mon, 23 Sep 2013 17:15:48 +0200

hi Alissa,

> "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 pr…

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

> 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