Re: [ietf-privacy] NAT Reveal / Host Identifiers

[Stephen Farrell <[e-mail]>]

Hi Med,

On 05/06/14 14:11, [e-mail] wrote:
> Hi Stephen,
> 
> You referred in your message to an old version. 

That was the one for which the adoption call was issued. I
guess just a typo.

I looked quickly at the diff between 04 and 05 and my
conclusion remains the same and most of my comment I think
still apply, despite the removal of the odd requirements
section.

S.

> The latest version of
> the document does not include any requirement, it is only an
> inventory of use cases when problems are encountered. The latest
> version is available at:
> http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-05.
>
>  Some of these use cases are restricted to a single administrative
> domain while others span multiple domain. Privacy concerns are really
> important; these are discussed in RFC6967.
> 
> The use cases are not theoretical ones, but are those where
> complications arise. Explicitly calling out security risks (including
> privacy ones) will benefit to this work. It is really helpful to
> understand the use cases and call out any potential risks rather than
> speculating without actual understanding of what the problem is.
> 
> This document is the opportunity to record security and privacy
> concerns that apply to these use cases. The content of the document
> is not frozen. Adopting it as a WG document will undoubtedly enrich
> it and benefit from other perspectives that those of the authors.
> 
> Cheers, Med
> 
>> -----Message d'origine----- De : ietf-privacy
>> [mailto:[e-mail]] De la part de Stephen
>> Farrell Envoyé : jeudi 5 juin 2014 14:48 À : Hannes Tschofenig;
>> [e-mail] Cc : [e-mail]; Zuniga, Juan Carlos 
>> Objet : Re: [ietf-privacy] NAT Reveal / Host Identifiers
>> 
> 
> Hiya,
> 
> On 05/06/14 08:05, Hannes Tschofenig wrote:
>>>> If you want to review a document with privacy implications
>>>> then have a look at the NAT reveal / host identifier work
>>>> (with draft-boucadair-intarea-host-identifier-scenarios-04
>>>> currently in a call for adoption).
>>>> 
>>>> I had raised my concerns several times now on the mailing list
>>>> and during the meetings.
> 
> I share those concerns. And adopting this without any consideration 
> of BCP188 would fly in the face of a very recent, very thoroughly 
> discussed, IETF consensus. For something like this, the onus ought 
> IMO be on the proposers to have done that work before asking for 
> adoption. Based on the draft, they clearly have not done that.
> 
> We could also ask to add more use-cases:
> 
> use-case#12: spy on everyone more easily, TEMPORA++ use-case#13: sell
> data that's even more fine-grained than clickstreams use-case#14:
> expose your n/w internals to help on path attackers use-case#15:
> track hosts from which people emit "dangerous" utterances 
> use-case#16: block hosts from which people emit "dangerous"
> utterances use-case#17: charge me more for using two of my computers
> in my house
> 
> The set of use-cases presented very much contradicts the explicit 
> claim in the draft that no position is being taken as to the merits 
> of this. IMO that argues strongly to not adopt this.
> 
> One could also comment on the requirements that seem to require new
> laws of physics or are otherwise pretty odd:
> 
> REQ#1: seems to require knowing from packets passing by that a device
> is a "trusted device" (and REQ#15 says that can be done with 16
> bits;-) Hmm... are those qubits maybe?
> 
> REQ#5: *all* IP packets MUST have a HOST_ID... but presumably without
> a flag day. Hmm...
> 
> REQ#6: says this is a transport thing. Eh, why ask INT-AREA?
> 
> REQ#10+REQ#11: MUST be intradomain only but MUST also be inter 
> domain. Hmm...
> 
> REQ#18: receiver MUST "enforce policies like QoS." Huh?
> 
> Such a frankly bogus list of "requirements" also means that this is
> not something that ought be adopted in the IETF.
> 
> I also think that this proposal has previously been proposed in other
> ways and not adopted. Such forum-shopping is yet another reason to
> not adopt it, and certainly not as an area wg thing without any
> broader IETF-wide consideration. (As an aside: having to play
> whack-a-mole with such repeat proposals is one of the downsides of
> area wgs. Not sure if anything can be done about that though.)
> 
> In summary: ignoring BCP188, the selection-bias in use cases, the
> badly thought out "requirements" and forum shopping are all
> independently sufficient reasons to not adopt this. And of course
> that doesn't include all the other issues with potential solutions
> listed in RFC6967 (the reference to which is oddly to the I-D and not
> the RFC).
> 
> My conclusion: this one ought go to /dev/null same as the previous
> attempts to shop the same thing into other parts of the IETF.
> 
> S
> 
> 
>>>> 
>>>> Ciao Hannes
>>>> 
>>>> 
>>>> -------- Original Message -------- Subject: 	[Int-area] Call
>>>> for adoption of
>>>> draft-boucadair-intarea-host-identifier-scenarios-04 Date:
>>>> Thu, 5 Jun 2014 04:20:56 +0000 From: 	Suresh Krishnan 
>>>> <[e-mail]> To: 	Internet Area 
>>>> <[e-mail]>
>>>> 
>>>> 
>>>> 
>>>> Hi all,
>>>> 
>>>> This draft was originally intended to be published as an AD 
>>>> sponsored submission from the OPS area, but the authors have 
>>>> expressed their interest to continue this work in the intarea
>>>> wg given that RFC6269 and RFC6967 originated here. The draft
>>>> has been updated to address the issues brought up during
>>>> earlier discussions on the wg mailing list and the latest
>>>> version of the draft is available at
>>>> 
>>>> 
>>>> 
>>>> http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-
>
>>>> 
scenarios-04
>>>> 
>>>> 
>>>> 
> This call is being initiated to determine whether there is WG
>>>> consensus towards adoption of 
>>>> draft-boucadair-intarea-host-identifier-scenarios-04 as an
>>>> intarea WG draft. Please state whether or not you're in favor
>>>> of the adoption by replying to this email. If you are not in
>>>> favor, please also state your objections in your response. This
>>>> adoption call will complete on 2014-06-19.
>>>> 
>>>> 
>>>> 
>>>> Regards
>>>> 
>>>> Suresh & Juan Carlos
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________ ietf-privacy 
>>>> mailing list [e-mail] 
>>>> https://www.ietf.org/mailman/listinfo/ietf-privacy
>>>> 
>> 
>> _______________________________________________ ietf-privacy
>> mailing list [e-mail] 
>> https://www.ietf.org/mailman/listinfo/ietf-privacy
> 
>