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

From: Stephen Farrell <[email-masked]>
Date: Fri, 20 Sep 2013 17:34:26 +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: SM <[email-masked]>
Date: Fri, 20 Sep 2013 22:55:25 -0700

Hello,
>FYI. Comments welcome,

I read draft-cooper-ietf-privacy-requirements-00 quickly.

 From Section 3:

   "standards-track IETF protocols that involve transmission of personal data"

The above only covers sending personal data.  I commented about a 
draft previously [1].  The Gen-ART review [2] mentioned that:

   "Misuse of this specification and many others could harm privacy,
   but that shouldn't necessarily dissuade us from publishing this draft."

The SecDir review didn't consider privacy as a security concern [3].

Would draft-cooper-ietf-privacy-requirements-00 be applicable for the 
above case?

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/ietf/current/msg79722.html
2. http://www.ietf.org/mail-archive/web/ietf/current/msg79959.html
3. http://www.ietf.org/mail-archive/web/secdir/current/msg04083.html

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 21 Sep 2013 13:55:23 +0100

On 09/21/2013 06:55 AM, SM wrote:
> The above only covers sending personal data.  I commented about a draft
> previously [1].  The Gen-ART review [2] mentioned that:
> 

Assuming we get IETF consensus for our proposal, then yes I think
it would cover that case since the personal data concerned is
designed to be transmitted in the DNS protocol.

Since there's currently no way to provide confidentiality for DNS
(a fine thing to think about), then for draft-jabley it would come
down to whether the IETF would have consensus to ignore the BCP in
that case.

I guess this proposed BCP would in such cases move the burden of
proof somewhat from those saying "stop, be more privacy friendly"
to those proposing the new protocol. And I think that'd be a good
change.

S.

---

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:

> FYI. Comments welcome.
> _______________________________________________
> 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

---

From: Avri Doria <[email-masked]>
Date: Wed, 25 Sep 2013 08:08:32 -0400

Hi

Very much support the draft and the idea of creating a BCP.

Have also appreciated the discussion on opportunistic encryption, which I consider akin to a holy grail.  Been thinking about it in a DTN context for a while, but don't feel like I ever got very far.

I am, however, looking at another part of the text.  I appreciate that the requirements are a MUST and that reads well, but, doesn't including a statement "Note that this is contingent on practicality" really downgrade it to a  SHOULD?

I think that "really has to be sent in clear for a protocol to be able to operate" is too hand wavy as a guideline.    Perhaps the draft could go deeper in the kinds of conditions that indicate that:

a) it was really necessary - what are the reasonable conditions for necessity?  
b) an indication of what practical actions have been taken to avoid this insurmountable obstacle and a discussion of which particular  requirements could not be met.
c) a guideline that indications be given on how can these instances be mitigated

This could well be a clue to what sort of information is needed to meet the requirement of explaining why the protocol does not fill the other requirements for protecting private data.

While I think that perhaps that I should go a little further breaking down a-c above, Irealized I would not get this sent of for several weeks if I were to try and go further and actually recommend text on a-c above.

avri

---

From: Scott Brim <[email-masked]>
Date: Wed, 25 Sep 2013 09:28:17 -0400

Makes sense.  That's essentially the recommended way to use SHOULD in 2026.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 25 Sep 2013 15:41:45 +0100

Hi Avri,

On 09/25/2013 01:08 PM, Avri Doria wrote:
> Have also appreciated the discussion on opportunistic encryption,
> which I consider akin to a holy grail.  Been thinking about it in a
> DTN context for a while, but don't feel like I ever got very far.
> 
> I am, however, looking at another part of the text.  I appreciate
> that the requirements are a MUST and that reads well, but, doesn't
> including a statement "Note that this is contingent on practicality"
> really downgrade it to a  SHOULD?

Well, I'd rather keep the MUST, but yes, it needs some kind of
modulation and so is quite like a SHOULD. However, there are a
bunch of people in the IETF who (wrongly, but nonetheless) only
ever pay attention to MUSTs.

What I think we're aiming for is something that's fairly strict
but usable for new protocols but doesn't cause us silly problems
e.g. if we want to revise RFC5322 again. We also want something
that doesn't become an RFC6919 "MUST, but we know you won't."

That's a tricky balance to achieve.

> I think that "really has to be sent in clear for a protocol to be
> able to operate" is too hand wavy as a guideline.    Perhaps the
> draft could go deeper in the kinds of conditions that indicate that:
> 
> a) it was really necessary - what are the reasonable conditions for
> necessity? b) an indication of what practical actions have been taken
> to avoid this insurmountable obstacle and a discussion of which
> particular  requirements could not be met. c) a guideline that
> indications be given on how can these instances be mitigated
> 
> This could well be a clue to what sort of information is needed to
> meet the requirement of explaining why the protocol does not fill the
> other requirements for protecting private data.
> 
> While I think that perhaps that I should go a little further breaking
> down a-c above, Irealized I would not get this sent of for several
> weeks if I were to try and go further and actually recommend text on
> a-c above.

Good points. I suspect we won't be done with this one in the next
week so if you can get the time to propose something that'd be
great. BCP107 does that by saying you MUST have auomated key
management if any of <6 conditions> are met, not sure if that's
a way to go about this though.

S.