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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 05 June 2014 13:24 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: ietf-privacy@ietfa.amsl.com
Delivered-To: ietf-privacy@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF1F1A0075; Thu, 5 Jun 2014 06:24:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKh0lc2Ebbor; Thu, 5 Jun 2014 06:24:21 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 53E061A00C6; Thu, 5 Jun 2014 06:24:21 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A8814BF8B; Thu, 5 Jun 2014 14:24:14 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9jNI1DFMgvw; Thu, 5 Jun 2014 14:24:12 +0100 (IST)
Received: from [10.87.48.12] (unknown [86.44.75.78]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A1B92BED0; Thu, 5 Jun 2014 14:24:12 +0100 (IST)
Message-ID: <53906F7C.1090500@cs.tcd.ie>
Date: Thu, 05 Jun 2014 14:24:12 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: mohamed.boucadair@orange.com, Hannes Tschofenig <hannes.tschofenig@gmx.net>, "int-area@ietf.org" <int-area@ietf.org>
References: <E87B771635882B4BA20096B589152EF628724B2C@eusaamb107.ericsson.se> <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> <787AE7BB302AE849A7480A190F8B9330013CAF@OPEXCLILM23.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B9330013CAF@OPEXCLILM23.corporate.adroot.infra.ftgroup>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf-privacy/I4lV5spq7C65ETyI0jDsC7Qhazs
Cc: "ietf-privacy@ietf.org" <ietf-privacy@ietf.org>, "Zuniga, Juan Carlos" <JuanCarlos.Zuniga@InterDigital.com>
Subject: Re: [ietf-privacy] NAT Reveal / Host Identifiers
X-BeenThere: ietf-privacy@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Internet Privacy Discussion List <ietf-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-privacy>, <mailto:ietf-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-privacy/>
List-Post: <mailto:ietf-privacy@ietf.org>
List-Help: <mailto:ietf-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-privacy>, <mailto:ietf-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jun 2014 13:24:24 -0000

Hi Med,

On 05/06/14 14:11, mohamed.boucadair@orange.com 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:ietf-privacy-bounces@ietf.org] De la part de Stephen
>> Farrell Envoyé : jeudi 5 juin 2014 14:48 À : Hannes Tschofenig;
>> int-area@ietf.org Cc : ietf-privacy@ietf.org; 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 
>>>> <suresh.krishnan@ericsson.com> To: 	Internet Area 
>>>> <int-area@ietf.org>
>>>> 
>>>> 
>>>> 
>>>> 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 ietf-privacy@ietf.org 
>>>> https://www.ietf.org/mailman/listinfo/ietf-privacy
>>>> 
>> 
>> _______________________________________________ ietf-privacy
>> mailing list ietf-privacy@ietf.org 
>> https://www.ietf.org/mailman/listinfo/ietf-privacy
> 
>