Subject: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 16 Nov 2011 07:41:03 +0100

Hi all, 

I wanted to repeat my comments on the draft from the working group session because I raised my hand when Suresh asked whether this document is a good starting point as a WG item. 

My comments on the microphone concerned two aspects: 

* Scope

At the beginning of the presentation the purpose of the document was advertised to the audience as telling others about the implication of address sharing (because people do not know about that). The expected audience was seen as both inside the IETF (the MTCP group was described as a group that is in need to lean about NATs) and outside the IETF. RFC 6269 already does this. 

It was also stated in the draft as well as in the presentation that recommendations regarding the solutions will be provided. During the working group session I believe we reached an agreement that the document would only document existing solutions and not provide recommendations on what to use for what specific application usages).

Here my concern was that documenting solutions to an unspecified range of problems is somewhat difficult when you talk about pros and cons. During the presentation alone more than three application domains were mentioned, namely denial of service attacks, charging, and authentication without having to re-type the password (a SSO type of solution). Some of you would agree with me that the solution space to only these three application scenarios is much larger than what is described in the document. 

I called it "stupid" to use the IP address for authentication purposes and the presenters made jokes about that statement (in the wrong believe I think they are stupid). Clearly, Joe and Pierre also do not believe that the source IP address can be used for authentication today anymore because that is the main statement of their draft - you have to at least consider the source port as well. I encourage those who believe in these types of "authentication" mechanisms to come to the OAuth working group meeting tomorrow to hear how other people in the industry do authentication today. 

(Btw, I am not the first who had made the observation that IP address for authentication is not such a great idea. Have a look at Steve Bellovin's publication from 1989 with the title "Security Problems in the TCP/IP Protocol Suite".)

* Privacy

The document cites draft-morris-privacy-considerations-03, which is good, but from the writeup in Section 1.2 I had gotten the impression that the authors do not believe in privacy and therefore wash it away with statements like: 
"
   The HOST_ID does not reveal more privacy information than what the
   source IP address does in a non-shared address environment (see
   [I-D.morris-privacy-considerations]).
"

Even if the authors do not believe in privacy (or and maybe other  design properties as well) there may still other people out there who find it important to consider it particularly if it has the potential to void other IETF work.

I would like to avoid the mistake that was made with RFC 6302: on one hand the authors of RFC 6302 assumed that readers have no clue about networking and don't know that they also have to log port numbers (in addition to IP addresses) but on the other hand they assumed they will know a lot about the privacy implications of logging. How likely is that? 

Ciao
Hannes

---

From: Francis Dupont <[email-masked]>
Date: Wed, 16 Nov 2011 08:09:26 +0100

I share your concern about the (or the lack of real) privacy considerations.
I know the IETF is still dominated by people from a country where
privacy is not a fundamental right so can be considered as a side question.
BTW I question if some authors (one lives in the same city than me so
should share my concerns?) intimately believe this whole stuff should
be simply forbidden to preserve the privacy but they don't follow the
right way.

To summarize my position:
 1- I believe this (the devices described in the document) infringes
  my rights as an European citizen (cf European Human Rights) but
  I am not a lawyer so it has to be tested in a court
 2- one is not allow to organize public meetings to discuss how to
  perform clearly illegal actions, in particular from a standardization
  body
 3- as far as I know the legal umbrella of the IETF is the Internet
  Society so I propose suggest if no other way to solve the legal
  issue to sue the Internet Society at the next meeting in Paris in a
  French court on the 1 and 2 basis (e.g., to pay a court bailiff to
  officially see 2...)

Regards

[email-masked]

---

From: <[email-masked]>
Date: Wed, 16 Nov 2011 14:34:20 +0100

Dear Hannes, all,

Thank you for your comments.

We seriously considered the privacy comment; this is why we contacted the IETF privacy mailing list hopping to receive feedback (see http://www.ietf.org/mail-archive/web/int-area/current/msg02958.html) but unfortunately only one comment was received (see http://www.ietf.org/mail-archive/web/ietf-privacy/current/msg00092.html).

>    [I-D.morris-privacy-considerations]).

without explicitly stating what is wrong with that text. 

I would appreciate if you can provide some guidance about the content of the Privacy Section. Thanks.

The document does not advocate for the use of source IP address for implicit identification but only acknowledge (quoting RFC6269) that such systems will break when address sharing is used. 

Cheers,
Med

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de Hannes Tschofenig
> Envoyé : mercredi 16 novembre 2011 07:41
> À : [email-masked]
> Objet : [Int-area] My comments on 
> draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
> 
> Hi all, 
> 
> I wanted to repeat my comments on the draft from the working 
> group session because I raised my hand when Suresh asked 
> whether this document is a good starting point as a WG item. 
> 
> At the beginning of the presentation the purpose of the 
> document was advertised to the audience as telling others 
> about the implication of address sharing (because people do 
> not know about that). The expected audience was seen as both 
> inside the IETF (the MTCP group was described as a group that 
> is in need to lean about NATs) and outside the IETF. RFC 6269 
> already does this. 
> 
> It was also stated in the draft as well as in the 
> presentation that recommendations regarding the solutions 
> will be provided. During the working group session I believe 
> we reached an agreement that the document would only document 
> existing solutions and not provide recommendations on what to 
> use for what specific application usages).
> 
> Here my concern was that documenting solutions to an 
> unspecified range of problems is somewhat difficult when you 
> talk about pros and cons. During the presentation alone more 
> than three application domains were mentioned, namely denial 
> of service attacks, charging, and authentication without 
> having to re-type the password (a SSO type of solution). Some 
> of you would agree with me that the solution space to only 
> these three application scenarios is much larger than what is 
> described in the document. 
> 
> I called it "stupid" to use the IP address for authentication 
> purposes and the presenters made jokes about that statement 
> (in the wrong believe I think they are stupid). Clearly, Joe 
> and Pierre also do not believe that the source IP address can 
> be used for authentication today anymore because that is the 
> main statement of their draft - you have to at least consider 
> the source port as well. I encourage those who believe in 
> these types of "authentication" mechanisms to come to the 
> OAuth working group meeting tomorrow to hear how other people 
> in the industry do authentication today. 
> 
> (Btw, I am not the first who had made the observation that IP 
> address for authentication is not such a great idea. Have a 
> look at Steve Bellovin's publication from 1989 with the title 
> "Security Problems in the TCP/IP Protocol Suite".)
> 
> * Privacy
> 
> The document cites draft-morris-privacy-considerations-03, 
> which is good, but from the writeup in Section 1.2 I had 
> gotten the impression that the authors do not believe in 
> privacy and therefore wash it away with statements like: 
> "
> Even if the authors do not believe in privacy (or and maybe 
> other  design properties as well) there may still other 
> people out there who find it important to consider it 
> particularly if it has the potential to void other IETF work.
> 
> I would like to avoid the mistake that was made with RFC 
> 6302: on one hand the authors of RFC 6302 assumed that 
> readers have no clue about networking and don't know that 
> they also have to log port numbers (in addition to IP 
> addresses) but on the other hand they assumed they will know 
> a lot about the privacy implications of logging. How likely is that? 
> 
> Ciao
> Hannes
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area
>

---

From: Scott Brim <[email-masked]>
Date: Wed, 16 Nov 2011 07:26:21 -0800

> We seriously considered the privacy comment; this is why we contacted the IETF privacy mailing list hopping to receive feedback (see http://www.ietf.org/mail-archive/web/int-area/current/msg02958.h…

I have been wanting to comment but I am busy with other meetings.

> I would appreciate if you can provide some guidance about the content of the Privacy Section. Thanks.

Any persistent identifier that can be used for correlation is risky,
because correlation can also be done with higher layer activity, so it
facilitates identification (and that facilitates further correlation,
and so on, until you have enough information to track someone with
ease, even without a host_id).

Scott

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 17 Nov 2011 10:42:08 +0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Scott Brim
> Sent: Wednesday, November 16, 2011 11:26 PM
> To: [email-masked]
> Cc: [email-masked]; JACQUENET Christian OLNC/NAD/TIP
> Subject: Re: [Int-area] My comments on draft-boucadair-intarea-nat-
> reveal-analysis-04 from the meeting
> 
> > We seriously considered the privacy comment; this is why we contacted
> the IETF privacy mailing list hopping to receive feedback (see
> http://www.ietf.org/mail-archive/web/int-area/current/msg02958.html)
> but unfortunately only one comment was received (see
> http://www.ietf.org/mail-archive/web/ietf-
> privacy/current/msg00092.html).
> 

None of the proposals create, or use, a persistent identifier.

Frankly, I find all this new-found privacy concern to be misplaced,
from several perspectives.  Today, users disclose their "identity"
(their IP address) whenever they initiate a connection to a
server -- their TCP SYN contains their IP address.  All of the
proposals are doing the same thing -- they are including an IP
address (or something with less than 32 bits).  

To my knowledge, today's ISPs are not under an obligation 
or requirement to change a subscriber's IPv4 address for 
purposes of privacy.  If my knowledge is inaccurate, and
ISP's are under that obligation, those ISPs can also change
a subscriber's HOST_ID; this can be accomplished by changing
the subscriber's IP address -- like today -- or by changing
the algorithm that calculates HOST_ID every NNN hours.

As for worries HOST_ID creates a persistent identifier, I realize
that adding an identifier is attracting lots of attention and
excitement from the IETF.  Yet, there are other places that
we have even worse correlation but nobody has highlighted:  (a) 
all of the currently-proposed stateless transition mechanisms
require creating the same persistency (A+P, Dual-IVI, 4rd,
SD-NAT, Deterministic NAT, and probably others), and (b)
IPv6's inclusion of MAC address.  As for (b), yes, we have
an RFC on IPv6 privacy addresses, but that doesn't avoid
the problem of correlating to a user and is the _same_
information disclosure as today's publicly-routed IPv4
addresses.

It is clear, though, from the confused comments at the 
microphone and the fact the privacy worry keeps coming
up that we will need a presentation at IETF83 in Paris.

If this privacy concern persists, ISP's will be required
to deploy CGN for privacy.   We do not want that.  Thus,
everyone needs to put their privacy concerns on the table,
so that we can address all of the concerns.

Statements like "this is bad for privacy" are not technical;
statements like yours which talk about a persistent identifier
are technical, and helpful in framing the problems and how
HOST_ID does not make the problem any worse than today's
publicly-routable IPv4 addresses and tomorrow's publicly-
routable IPv6 addresses.

> ease, even without a host_id).

-d

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 17 Nov 2011 10:42:56 +0800

> Behalf Of Francis Dupont
> Sent: Wednesday, November 16, 2011 3:09 PM
> To: Hannes Tschofenig
> Cc: [email-masked]

Technical objections would be useful.  Please make some technical
objections.

-d

---

From: Francis Dupont <[email-masked]>
Date: Thu, 17 Nov 2011 04:26:07 +0100

In your previous mail you wrote:

=> it is not new found, I raised the same issue at least at the last
two IETF meetings. And BTW it is not really a technical issue, it
is a legal one in many countries (I'd like to believe most at the
exception of USA) and as usual with many legal issues we can expect
not very rational arguments from the outside... (cf the embedded MAC
address for IPv6).

To summary I am afraid of the perception of this from the outside,
and I argue the IETF *must not* endorse the document (i.e., publish
it with a draft-ietf-* name) with the privacy considerations in
the current state.

=> unfortunately this is a wish, not an argument, as the real issue
is legal and not technical from the beginning as you should get
from the issue history.

=> in fact the end of your statement is not fun at all: as far as
I know there is a legal lobby in Germany arguing publicly-routable
IPv6 addresses is a threat against privacy...
I repeat this again: ignoring this kind of problems is *not* the right
way to get rid of them.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Thu, 17 Nov 2011 04:31:51 +0100

=> I'll be as friendly as you: don't make this kind of comments
in public without looking at the history of the problem first.

---

From: Joe Touch <[email-masked]>
Date: Wed, 16 Nov 2011 19:35:23 -0800

Hi, all,

I find all of this privacy information misplaced as well.

We are talking about correlating connections, not PEOPLE. Nothing in 
this document is related to the identity of an individual. There are 
other valid recommendations - such as the need to spin IP addresses - 
that are relevant, but NOT appropriate to discuss in this doc.

Yes, the current text on privacy is insufficient, but this document is 
not intended to resolve all privacy issues.

Joe

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 17 Nov 2011 11:35:40 +0800

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, November 17, 2011 11:26 AM
> To: Dan Wing
> Cc: 'Scott Brim'; [email-masked]; [email-masked];
> 'JACQUENET Christian OLNC/NAD/TIP'

Then please make a technical argument.

-d

---

From: "George, Wes" <[email-masked]>
Date: Thu, 17 Nov 2011 03:17:17 -0500

> Behalf Of Dan Wing
> to deploy CGN for privacy.   We do not want that.
>
+1 million. Matter of fact, I've made that exact statement before: http://www.ietf.org/mail-archive/web/int-area/current/msg02963.html

Francois (and others)
If there is a legitimate (and/or legally required) need for privacy that is not being met by existing IETF protocol implementations, I suggest that you write a draft with a clear set of requirements and/or problem statement, perhaps in cooperation with the privacy directorate so that we can solve it, rather than simply trolling with threats of lawsuits and other vague handwaving about privacy issues for EU citizens. We can't fix what we don't understand.

Privacy is a legitimate concern, but I do not want to see us try to bolt on fixes for new privacy requirements to IPv4 life support items without a cohesive strategy regarding what privacy problems we are expected to solve as a whole. No piece-parts solutions.  More importantly, I want to see clear consensus that we should indeed fix these issues in IPv4, rather than simply acknowledging that IPv4 is what it is and working to make sure that IPv6 meets the new requirements for privacy as we move towards it.
In other words, similar to the last presentation in IntArea yesterday, we need to decide whether the answer is "if you want more privacy, move to IPv6, we're not fixing this in IPv4" or not.

Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 17 Nov 2011 09:58:58 +0100

> to deploy CGN for privacy.   We do not want that.

=> nobody wants that but it is the kind of things which can happen
from privacy activists if we continue to provoque them in place to
just not pay more attention to them than needed.

   Francois (and others)

=> I don't know who you are speaking to?

   If there is a legitimate (and/or legally required) need for privacy

=> this is not the point: bt any standard, including technical, the
document is very far to address correctly its impact on privacy.  So
we (me, Francois? and others) simply ask to get this fixed before it
is published with a name beginning by draft-ietf-*. Note this is very
far from being new, I have warned since the first presentation some
meetings ago (March one) than particular care should be required about
the sensible privacy aspect in the document. Now you can read it (if
you haven't yet) and find how this was translated in the current
version, and perhaps you'll understand why this aggravates me a bit.

   simply trolling with threats of lawsuits

=> it is not trolling: the problem of the privacy is a legal one
and as I am a not lawyer individual the best way to get a legal
opinion is from people whom it is the job. Now I expect to get
the privacy considerations fixed (oops, there is not yet such
a section in the document) before having to show our concern
has real basis.

   vague handwaving about privacy issues for EU citizens.

=> I have given the pointers to the European Convention on Human Rights
in a previous message (20110909 according to grep).
   
Regards

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 17 Nov 2011 20:01:49 +0800

Hi Francis,

> version, and perhaps you'll understand why this aggravates me a bit.

I have seen the concerns that you and Hannes have raised, and I have 
requested Alissa to help out the authors with the privacy aspects of 
this document. I can understand why you are objecting to the document 
being published as is, but I would like to understand better why you do 
not want this to be adopted and brought under wg change control so that 
we can make the necessary changes.

Thanks
Suresh

---

From: <[email-masked]>
Date: Thu, 17 Nov 2011 13:19:22 +0100

Dear Hannes, 

> "Security Problems in the TCP/IP Protocol Suite".)

The current text says (http://tools.ietf.org/html/draft-boucadair-intarea-nat-reveal-analysis-04):

   Enabling explicit identification means and adequate security suite is
   more robust than relying on source IP address or HOST_ID.  But
   tension may appear between strong privacy and usability (see Section
   4.2 of [I-D.iab-privacy-workshop]).

Do you think this should be elaborated further? Text is more than welcome.

Cheers,
Med

---

From: <[email-masked]>
Date: Thu, 17 Nov 2011 13:29:07 +0100

Dear Scott,

> ease, even without a host_id).

Yes, using persistent identifiers is risky. We tried to capture this in the current text: (see http://tools.ietf.org/html/draft-boucadair-intarea-nat-reveal-analysis-04):

   The volatility of the HOST_ID information is similar to the source IP
   address: a distinct HOST_ID may be used by the address sharing
   function when the host reboots or gets a new internal IP address.  If
   the HOST_ID is persistent it may be used to track a host (similar to
   persistent IP addresses).

Note than none of the HOST_ID proposals rely on persistent identifiers; the content of the HOST_ID may be:

* An IPv4 address
* Some bits of the IPv4 address
* IPv6 address
* IPv6 prefix
* IP address:Port Number.

Therefore, the information exposed in the HOST_ID is not worse compared to situations where no address sharing is in the path.

For sure, we can add some text to encourage address sharing function to avoid persistent information be leaked in the HOST_ID.

Cheers,
Med

---

From: <[email-masked]>
Date: Thu, 17 Nov 2011 13:58:32 +0100

Hi Francis,

>   I am not a lawyer so it has to be tested in a court

Sorry but I still don't understand your concern here:

* The HOST_ID reveals part or all bits of the internal source IP address.

* When no address sharing is in the path, your IP address is revealed to remote servers. 

Does this mean all ISPs "infringe your rights as en European citizen" by not altering your source IP address? Do you want ISPs deploy onion routing and the like?

Cheers,
Med

---

From: Joe Touch <[email-masked]>
Date: Thu, 17 Nov 2011 05:47:42 -0800

FWIW - I wonder if anyone in the EU so concerned about their privacy has 
a phone number. Or email address - or worse, their own domain ;-)

Joe

---

From: Francis Dupont <[email-masked]>
Date: Thu, 17 Nov 2011 14:57:37 +0100

=> perhaps I was not very clear: my concern is about only a publication
under the draft-ietf-* name of the document in its current state, of
course I am perfectly fine if the WG takes control, makes the changes
I believe are required and then publish it (and I believe Hannes shares
this opinion even I prefer he answers for himself).

Thanks

---

From: Joe Touch <[email-masked]>
Date: Thu, 17 Nov 2011 06:14:43 -0800

On 11/17/2011 5:57 AM, Francis Dupont wrote:
> under the draft-ietf-* name of the document in its current state,

Documents cannot possibly be interpreted as representing the consensus 
of the IETF until issued as RFCs.

If what you say were a real concern, we would never issue draft-ietf-*; 
documents would always need to go from individual direct to RFC.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 17 Nov 2011 17:53:02 -0800

One additional point:

I was not able to locate any text requiring IETF documents to include a 
"Privacy Considerations" section, or to address privacy issues directly.

I saw some recent *drafts* on this issue, but nothing that is agreed to 
currently impact IETF process.

Until those drafts result in such a recommendation or condition, it is 
premature to enforce them - or any requirement on document structure 
that they *might eventually* require.

Joe

---

From: SM <[email-masked]>
Date: Thu, 24 Nov 2011 07:52:41 -0800

At 22:41 15-11-2011, Hannes Tschofenig wrote:
>purposes and the presenters made jokes about that statement (in the 
>wrong believe I think they are stupid). Clearly, Joe and Pierre also 
>do not believe that the source IP address can be used for 
>authentication today anymore because that is the main statement of 
>their draft - you have to at least consider the source port as well. 
>I encourage those who believe in these types of "authentication" 
>mechanisms to come to the OAuth working group meeting tomorrow to 
>hear how other people in the industry do authentication today.

Whether it is "stupid" or not to use IP addresses for authentication 
purposes, the reality is that there are sites that do it.  If OAuth 
is a viable alternative, the draft could point to it.

>other  design properties as well) there may still other people out 
>there who find it important to consider it particularly if it has 
>the potential to void other IETF work.

I would like to point out that the author of the draft requested 
feedback on the ietf-privacy mailing list [1] (I could not find the 
original message is not in the archive).  People are going to ignore 
privacy considerations if there isn't any feedback or expertise to 
discuss such issues.

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/ietf-privacy/current/msg00092.html

---

From: SM <[email-masked]>
Date: Thu, 24 Nov 2011 07:57:25 -0800

Hi Francis,
>   French court on the 1 and 2 basis (e.g., to pay a court bailiff to

The legal umbrella of the IETF is the IETF Trust.

Regards,
-sm

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Nov 2011 09:02:46 +1300

> The legal umbrella of the IETF is the IETF Trust.

Only for intellectual property issues. For other liabilities, the
insurance is carried by ISOC as Francis says. But I don't see the
relevance - if operators or users break legal requirements, that is
nothing to do with the IETF anyway. Read the "AS IS" disclaimer found in
older RFCs and now part of the Trust's legal conditions.

   Brian

---

From: SM <[email-masked]>
Date: Thu, 24 Nov 2011 13:22:33 -0800

Hi Brian,
>older RFCs and now part of the Trust's legal conditions.

I think that Francis' point is that the authors are writing a 
specification which, if implemented, may be illegal to deploy in some 
jurisdictions.  It's premature to draw any conclusion about the 
merits of the draft at such an early stage.

There has been a few drafts recently on which questions about privacy 
were raised.  If privacy wasn't an issue, the web would be faster ( 
www.afasterinternet.com ).  The discussions in several working groups 
point to a privacy void, i.e. there isn't any guidance about limiting 
data exposure when designing a protocol.

Regards,
-sm

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Nov 2011 10:50:00 +1300

On 2011-11-25 10:22, SM wrote:
> jurisdictions.  

It would not be the first or last RFC with that characteristic.

> It's premature to draw any conclusion about the merits
> of the draft at such an early stage.
> 

I'm certainly in favour of discussing privacy issues in specifications
where this is relevant.

   Brian

---

From: Joel jaeggli <[email-masked]>
Date: Thu, 24 Nov 2011 13:50:58 -0800

On 11/24/11 13:22 , SM wrote:
> jurisdictions.  It's premature to draw any conclusion about the merits

Lots of things done on the internet using internet standards no less are
potentially or actually illegal somewhere.

I can roll my IETF timeline back to the last decade of the 20th century
and cruise the various debates, on the presence or lack thereof of
encryption, export/import restriction, lawful interception, and more
recently both privacy and identity exposure requirements.

If I were to come to ay conclusion, it's likely that it would be that
there are no axioms.

having had the pleasure as an operator of deploying services in
jurisdictions with something approaching mutually exclusive requirements
I'm going not expect that we can satisfy everyone.

---

From: Francis Dupont <[email-masked]>
Date: Fri, 25 Nov 2011 19:27:48 +0100

I would like to point out that the author of the draft requested 
   feedback on the ietf-privacy mailing list [1] (I could not find the 
   original message is not in the archive).

=> yes, the author didn't receive the help we could expect to fix
the privacy text issue...

   People are going to ignore privacy considerations if there isn't
   any feedback or expertise to discuss such issues.
   
=> here my feedback was the same from the beginning: the privacy
impact of the nat-reveal I-D is sensible and must be correctly
handled. I'd like to have been more positive...

Regards

---

From: Joe Touch <[email-masked]>
Date: Fri, 25 Nov 2011 12:09:40 -0800

On Nov 24, 2011, at 1:22 PM, SM wrote:

> I think that Francis' point is that the authors are writing a specification

Full stop.

We are writing a comparison of existing approaches. There is no specification in this doc.

> which, if implemented, may be illegal to deploy in some jurisdictions.  It's premature to draw any conclusion about the merits of the draft at such an early stage.

It's premature to put requirements on this document which do not exist throughout the IETF.

If there are "privacy considerations" requirements defined in an RFC, please point to them.

Otherwise, this thread is what is truly premature.

Joe

---

From: Francis Dupont <[email-masked]>
Date: Fri, 25 Nov 2011 21:46:12 +0100

=> the word "may" is the right one. If the spec should stay about
technical stuff IMHO it is an error to ignore its impact on privacy.
In a document produced by a standardization body, this could be
even considered as a provocation. But the solution is easy: add
a privacy consideration section which explains the technical impact
and show the IETF doesn't endorse in any way the not-technical aspects
of the implementation of methods described in the spec.

   It's premature to draw any conclusion about the 
   merits of the draft at such an early stage.
   
=> if it is about the not-technical merits this should stay true
for the whole life of the document...

=> IMHO this should change. We solved a similar issue about security,
there is no reason the same method won't work for privacy.
And we should agree to deny privacy issues is not the right way,
shouldn't we?

Regards

---

From: Joe Touch <[email-masked]>
Date: Fri, 25 Nov 2011 13:05:21 -0800

On Nov 25, 2011, at 12:46 PM, Francis Dupont wrote:
...
> And we should agree to deny privacy issues is not the right way,

If and when a document describing the privacy considerations requirements has passed IETF review, sure.

Right now, that document is an individual submission with no track.

It is quite premature to be holding up this document on an issue that the IETF has not yet decided on.

Joe

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 25 Nov 2011 16:24:32 -0500

> there is no reason the same method won't work for privacy.

This claim requires an adequate operationalization of "privacy".  What
exactly does one mean by this?  Most of the claims I hear about it,
including a number of the windy assertions that there is a fundamental
right (whatever that is) to it, seem never to state what exactly it is
supposed to mean.

None of this is to say it is impossible to add what you suggest.  But
it needs something more than to say "privacy" over and over again: to
begin with, how is one supposed to have any clue what features might
have privacy implications if one simply doesn't know what "privacy"
means?

To lean on your analogy a little, security discussions often exhibit
the sorts of problems I'm talking about here, too.  That is nowise an
argument that we don't need the sort of operational definition I'm
talking about.  On the contrary, many of the nastier security
discussions I've ever seen boil down to a disagreement about the
boundaries of the term "security".

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Sat, 26 Nov 2011 19:21:07 +0100

If and when a document describing the privacy considerations
   requirements has passed IETF review, sure.
   
=> to wait this document is published as a RFC to add a privacy
consideration section to the nat-reveal I-D is no more reasonable
to block all documents related to privacy until it is published...

=> perhaps you are not about the same 'that document' than me, cf
draft-iab-privacy-considerations-01.txt which is far to be an
individual submission without a clear future.

   It is quite premature to be holding up this document on an issue
   that the IETF has not yet decided on.
   
=> as there is a solution proposed by a third party and I wish to
leave the possible announce to him I moved to offline...

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sat, 26 Nov 2011 19:44:52 +0100

=> it is in the European Convention on Human Rights as a legal
principle so there is at least a basis but I am afraid it won't really
help. As a (French) lawyer explained to me one day, a legal text must be
as less accurate as possible so it can be applied to more than one
particular case so a legal principle...

=> it is clearly a job for the IAB and fortunately this seems to have
been well understood (cf draft-iab-privacy-considerations)

=> I am sure it is easy to find some examples where a particular point
is viewed in favor or against the security according to different people.
And we can expect some trade-offs between security and privacy too...

Regards

PS: http://en.wikipedia.org/wiki/European_Convention_on_Human_Rights
(see the article 8 about privacy).

---

From: JFC Morfin <[email-masked]>
Date: Sun, 27 Nov 2011 02:36:23 +0100

In order to help the debate on privacy, I have gathered the different 
quoted documents at: http://iucg.org/wiki/Privacy.
I hope this may help.

My feeling is that the debate is desynchronized:
- IETF wishes to protect communications and now contents (what the 
content is about)
- EC wishes to protect correspondance whatever the technology.
jfc

---

From: Joe Touch <[email-masked]>
Date: Sat, 26 Nov 2011 17:40:37 -0800

> to block all documents related to privacy until it is published...

That has not been yet requested. If it were, I would be glad to raise it as a process issue. 

Again, stop holding this doc to requirements that gave not been agereed by the IETF as a whole. 

> individual submission without a clear future.

Is hasn't been last called either. And its core definitions refer to a induvidual submission. 

> leave the possible announce to him I moved to offline...

Based on input from a directorate that is proposed in a doc that is still a draft. 

This isn't useful. 

The privacy considerations IAB doc is misguided IMO. We don't need a required section for every squeaky wheel. These are security issues and not sufficiently agreed at this time to establish requirements IMO. 

Joe

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 26 Nov 2011 23:40:04 -0500

Joe,
	I am missing something.
	There is an observation that the behavior described in this document 
has privacy implications.
Either that statement is true, or it is not.  If it is not true, then 
there is no need to do anything.
However, it appears likely the statement is true.

	If it is true that this document has privacy implications, then the 
general rule that says that we should document what we know about would 
seem to come into play.  It would seem sensible to include a description 
of known privacy implications in the document.

	This seems to be the case even if the absence of any document from 
anyone, with or without IETF consensus, on the more general issue of 
looking for privacy issues.

Yours,
Joel

On 11/26/2011 8:40 PM, Joe Touch wrote:
>
>
> On Nov 26, 2011, at 10:21 AM, Francis Dupont<[email-masked]>  wrote:
>

---

From: Joe Touch <[email-masked]>
Date: Sun, 27 Nov 2011 08:29:17 -0800

On Nov 26, 2011, at 8:40 PM, Joel M. Halpern wrote:

> Joe,
> 	I am missing something.
> 	There is an observation that the behavior described in this document has privacy implications.
> Either that statement is true, or it is not.  If it is not true, then there is no need to do anything.
> 	If it is true that this document has privacy implications, then the general rule that says that we should document what we know about would seem to come into play.  It would seem sensible to include a description of known privacy implications in the document.

1) it is true that this - and many docs in the IETF - have privacy implications

2) it is equally true that there are NO CURRENT GUIDELINES on how to address these issues

This is a case of a sudden realization that we all *want* to address privacy. I don't. I don't think it's relevant when all that's being discussed are IP addresses. Nothing about the Internet architecture is intended to keep such addresses private - in fact, quite the opposite. The IAB's current soapbox on this issue is a *start* to that discussion, but hasn't been decided as IETF position yet.

> 	This seems to be the case even if the absence of any document from anyone, with or without IETF consensus, on the more general issue of looking for privacy issues.

You could claim that there are a few who are significantly concerned about whether this doc should address privacy, but I didn't recall a consensus call on that. A consensus call on the properties of a doc that hasn't been adopted by the WG seems premature (process-wise) anyway.

IMO, if the WG adopts this doc then it should have such input, and the decision as to how to address it should be made by the WG. That would start with at least some common agreement on what privacy means and what goals we should have for privacy. HOWEVER - that is the purpose of the IAB's documents, and they (again) are still being developed.

Some *WANT* to address these issues in current documents. I claim they are jumping the gun, and need to wait for a common understanding of the goals and terms to be determined first.

There is no current IAB or IESG recommendation to hold documents based on the emerging discussion on privacy.

Joe

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 27 Nov 2011 23:13:37 -0500

Francis,

As a preliminary note, I will suggest to you (as I know has been
suggested to you repeatedly in the past) that your quoting conventions
are so unconventional as to inspire confusion.  If you want to stick
with them in personal mail, then the damage accrues only to those who
correspond with you.  On a public mailing list, you might consider
everyone else's experience.

That said,

> particular case so a legal principle...

You appear to be claiming the in above that we are suppose to write
"Privacy Considerations" without a clear definition of what could
possibly be covered, except maybe "everything".

Ok, here's more boilerplate for you:

    Privacy Considerations

    This document may affect the privacy of someone on the Internet,
    according to the definition of privacy in your jurisdiction.  You
    are encouraged to consider that.

That's all we can say, AFAICT from your response.

> (see the article 8 about privacy).

Yes, of course.  We should base new policies on the official opinion
of all the people who can be bothered to work on Wikipedia articles.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: JFC Morfin <[email-masked]>
Date: Mon, 28 Nov 2011 11:34:43 +0100

>possibly be covered, except maybe "everything".

Andrew,

we are to reach a rough consensus. One cannot build a consensus in 
opposing some of the members. Whatever their motivations.

Now, how to do it? The need is not to cover everything, but to cover 
everything in our bailywick that may affect everything as defined by 
the obligations of the various national legal cultures. So, the point 
seems rather simple: to cover our tracks. Whatever privacy may be, 
the technical matter is about not giving away/leaking undisclosed 
(meta)data through what we permit to do. So the Internet works better 
(RFC 3935) not worse.

Questions:

1. which information do we use?
2. which information do we introduce?
3. in which way do/canwe expose them?
4. which steps do we already take not to (over)expose them?
5. are there additional step we could consider to cover our tracks?

If the responses do not gain the support of every people (for 
whatever reason) there will not be a consensus and nothing will be published.

jfc

---

From: Francis Dupont <[email-masked]>
Date: Mon, 28 Nov 2011 13:59:33 +0100

Again, stop holding this doc to requirements that gave not been
   agereed by the IETF as a whole.
   
=> I clarified my objection to the nat-reveal document: I really want
to get it with a privacy considerations section and I have no technical
concerns about it (i.e., even I don't like the methods it describes
I share the idea to not leave ISPs invent their own shaky methods).

   Based on input from a directorate that is proposed in a doc that is
   still a draft.
   
=> it doesn't matter as soon as we can put a name on it (i.e., what
matters is the result, there is no need to fix the process first when
we can get it).

   The privacy considerations IAB doc is misguided IMO. We don't need
   a required section for every squeaky wheel.

=> perhaps but the idea is to enforce authors to not ignore the
question.  It worked well for security which at its time was far to be
easy too. So IMHO it is the hard but right way, i.e., without this we
can get documents with a real impact on privacy but no argument about
it (and I am afraid you are contributing to prove this :-).

Regards

PS: I propose to use our energy to other things...

---

From: <[email-masked]>
Date: Mon, 28 Nov 2011 14:05:25 +0100

Hi Francis,
 
> [mailto:[email-masked]] De la part de Francis Dupont
> Envoyé : lundi 28 novembre 2011 14:00
> À : Joe Touch
> Cc : [email-masked]
> Objet : Re: [Int-area] My comments on 

As you know there is already a "Privacy" Section in the document: http://tools.ietf.org/html/draft-boucadair-intarea-nat-reveal-analysis-04#section-1.2

I know it is incomplete but I really would like to capture the privacy concerns you have in that section. Thanks.

Cheers,
Med

---

From: Francis Dupont <[email-masked]>
Date: Mon, 28 Nov 2011 14:36:45 +0100

As a preliminary note, I will suggest to you that your quoting
   conventions ...
   
=> as I can't see a difference between mine and yours I suggest
to address this in private.

   > particular case so a legal principle...
   
=> I (mis?)interpreted your message as asking for a formal definition
of the term "privacy" so I tried to answer.

   
=> you are free to follow the pointer to the text itself and not stop
at the comments which, I agree, can't be blindly assume as impartial.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Mon, 28 Nov 2011 16:19:03 +0100

As you know there is already a "Privacy" Section in the document:
   http://tools.ietf.org/html/draft-boucadair-intarea-nat-reveal-analysis-04#section-1.2
   
=> you refer to this statement:
   The HOST_ID does not reveal more privacy information than what the
   source IP address does in a non-shared address environment
if it is not false it is very far to be complete: the HOST_ID (and other methods)
should be compared to a shared address environment without HOST_ID (and
any other method) too.

   I know it is incomplete but I really would like to capture the
   privacy concerns you have in that section.
   
=> it should be fine to explain the IETF doesn't endorse the use of this, etc.
I leave the wording to better skilled people, the idea is: the document explains
"if you have to do it, you should do it this way" and no more.

Regards

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 28 Nov 2011 10:37:30 -0500

> of the term "privacy" so I tried to answer.

I think I said I wanted an "operational definition", which while
perhaps more or less formal always provides all the necessary and
sufficient conditions for something to qualify under the term.  The
definition you proffered (you seemed to say) you understood to be
ambiguous.  If it's ambiguous, then it cannot possibly be an
operational definition (or anyway, not a good one).  So it doesn't
meet the need, and I therefore think we can't add a Privacy
Considerations section to documents (yet).

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Joe Touch <[email-masked]>
Date: Mon, 28 Nov 2011 07:53:15 -0800

On 11/28/2011 4:59 AM, Francis Dupont wrote:
....
> easy too.

It worked *after* the requirement for a security considerations section 
was agreed by the IETF. That is not yet the case with privacy 
considerations.

...
> PS: I propose to use our energy to other things...

I plan to use mine raising concerns with the IAB's soapbox on this issue.

Joe

---

From: Francis Dupont <[email-masked]>
Date: Mon, 28 Nov 2011 17:28:15 +0100

In your previous mail you wrote:

>  > => I (mis?)interpreted your message as asking for a formal
>  > definition of the term "privacy" so I tried to answer.
>  
>  I think I said I wanted an "operational definition"

=> BTW what is the operational definition of security (just to know)?

Regards

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 28 Nov 2011 11:55:04 -0500

> => BTW what is the operational definition of security (just to know)?

I think I observed in my original remarks that this is a problem that
also happens in discussions of security.  That some other topic has
such a problem is not a good reason to repeat that problematic
structure with privacy.

A

-- 
Andrew Sullivan
[email-masked]

---

From: JFC Morfin <[email-masked]>
Date: Tue, 29 Nov 2011 13:16:45 +0100

>such a problem is not a good reason to repeat that problematic

This is why I said this is a typical Wittgensten situation.

Not only the problem is (if I read you correctly) a language problem 
in describing the issue, but now you make the need to resolve the 
problem a language metaproblem. The Internet architecture has 
supposedly not initally considered security and we have difficulty 
enough to add it now: so, not need to add the privacy burden.

Your solution is therefore that this privacy issue should not to be 
addressed within the IETF Internet end to end layers scope. It seems 
also is the position of Joe Touch (at least until an IETF community 
consensus has not been reached).

However,

1) they also are not considered on the user side.
2) some are considering that privacy is part of security.

This means that

1) the proper way to address them is by subsidiarity (on a per 
national law, corporate practice, personnal need, etc.) and that the 
proper place where they are to be addressed is at the fringe to 
fringe IUI layers (Internet/Intelligent Use Interface)

2) we are therefore in a similar architectural configuration as in 
the IDNA2008 case. As you may recall (my clarification appeals) IESG 
and IAB made clear these IUI layers were no part of the IETF charter 
as also to be shared with other convergent technologies, but:
- are to be adequately supported on the Internet side (IAB works on 
IDNs support exploration, as they explore Privacy)
- proposed me to start a BOF on the matter - but I am not an IETF 
engineer and this issue belong to the IUsers emerging community I 
liaise through the [email-masked] (I keep cc'ed)

I therefore read you as supporting the idea that IRT. security and 
privacy issues, things are similar to mapping for languages and 
scripts. Security and privacy should therefore be addressed by 
subsidiarity in the context of the "Internet use": the Internet 
protocols having to make sure this IS possible in being definitly 
stable and clearly documented (like in the DNS case) for the IUI 
designers to build on them.

(At IUse level we consider that the split is through the 
MUST/SHOULD/MAY sequence, where we read IETF's "MUST"s as untangible 
"IS/ARE" we can trust).

I certainly do support that clarification.

jfc