Re: [DMM] Stephen Farrell's Discuss on draft-ietf-dmm-4283mnids-04: (with DISCUSS and COMMENT)

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 05 April 2017 15:38 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAED5129477; Wed, 5 Apr 2017 08:38:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level:
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 WhC9DFYSrT0f; Wed, 5 Apr 2017 08:38:02 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74AA8128DF6; Wed, 5 Apr 2017 08:37:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id F2682BE8E; Wed, 5 Apr 2017 16:37:54 +0100 (IST)
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 aNpXEhqI68Pk; Wed, 5 Apr 2017 16:37:54 +0100 (IST)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 61071BE7C; Wed, 5 Apr 2017 16:37:54 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1491406674; bh=wzKZesVL0qcyWteTWZKp2Xps8mY0Sf5yQSIdj2KCKUk=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=1Z525RL6lBdt8985hueDByso+++sPl0u7wlls41RTVVmuPmB4Wfmq1FTB/bhbNUhZ zBq525OUQIOQy+Ex5FlAdRbDTHRnx1BSkZHldb+PnR2/OJQhSBpylX8+bh9wouqHmo W8cpSXka1WqxcfShmNr5WJIbxFJF/fpAUDL4k7gI=
To: Hakima Chaouchi <hakima.chaouchii@gmail.com>
References: <148720843433.31432.10415791688976362439.idtracker@ietfa.amsl.com> <CABhP2znydr3bpfSM+VvGd8tvOnWvnU9UaAgw0y1cpBy5xS=MUA@mail.gmail.com>
Cc: The IESG <iesg@ietf.org>, max.ldp@alibaba-inc.com, draft-ietf-dmm-4283mnids@ietf.org, dmm-chairs@ietf.org, dmm@ietf.org
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <2b9f1b37-437e-2b1c-fc36-357ef4c430b7@cs.tcd.ie>
Date: Wed, 05 Apr 2017 16:37:52 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CABhP2znydr3bpfSM+VvGd8tvOnWvnU9UaAgw0y1cpBy5xS=MUA@mail.gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="2J0GaGSeMIq4mEvGfBVwh7dhESehecPHJ"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmm/R9m6LxnZq6aSHEpXjQLnW2Bw7ns>
Subject: Re: [DMM] Stephen Farrell's Discuss on draft-ietf-dmm-4283mnids-04: (with DISCUSS and COMMENT)
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Apr 2017 15:38:06 -0000


On 05/04/17 16:30, Hakima Chaouchi wrote:
> Hi there,
> 
> Sorry for catching up the discussion late.

You're so late that I'm no longer on the IESG and hence
Suresh will I guess handle this now ex-DISCUSS:-)

Note though there were other discusses on the draft so
my leaving the IESG does not by itself unblock this.

So I'll leave it to Suresh to figure our the right next
steps. I'm happy to chat more about it then if that's
useful

Cheers,
S.

> 
> If I understood well the discussion; the question here is about 1) how
> those identifiers might violate the user privacy?  2) Is internet getting
> better by including those identifiers?
> 
> I will not discuss the case of IMSI for mobile cellular devices, but in the
> case of RFID I believe:
> 1) regarding point 1 related to privacy, in fact if a device with an RFID
> tag for instance a bank card has to send in clear its numbers as a MNID in
> a packet then of course there is an issue, but I believe that matching the
> MNID with the IP adress will be also secured inside the packet , first the
> identifiers has to be well defined and structured , then work on the
> protocol packet secure exchange of those identifiers.
> 
> 2) regarding point 2, we need to remind that Internet to be part of the
> game of Internet of Things trafic exchange then it has to consider all
> types of communicating devices, knowing that we are talking on the near
> future of billions of sensors, actuators, RFID tags talking, then Internet
> protocols will take care of that and having IDs coressponding to all these
> types is the way to go to better manage for instance the mobility of those
> devices as using the device ID as a non changing reference information, and
> changing the adresses while on move. Other protocols might benefit from
> this ID information such as service discovery or end to end signaling. I
> believe the IETF worked years ago on separating the identifier (locator)
> and the address, this was meant to help the fast mobility management but
> also securing the sender and reciever mutual authentication with trusted
> identifiers. May be  we should think about how to build a secure identifier
> of each node which will be built upon the original identifier (eg IMSI,
> RFID, ...etc) and another type of secure information. In that case privacy
> will be saved as the original identifier is not sent in clear? and more
> functionalities would be introduced using those identifiers. what do you
> think?
> 
> Regards,
> Hakima
> 
> 
> 
> 
> *---------------------------------------------*
> Hakima Chaouchi
> Professor
> Institut Mines Telecom
> Research Group: Emerging Networks and Services toward Internet of Things
> EU AIOTI Alliance member
> eMBA Leading innovation in the Digital World
> 
> 2017-02-16 2:27 GMT+01:00 Stephen Farrell <stephen.farrell@cs.tcd.ie>:
> 
>> Stephen Farrell has entered the following ballot position for
>> draft-ietf-dmm-4283mnids-04: Discuss
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-dmm-4283mnids/
>>
>>
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>>
>> I don't consider that merely mentioning that there are some
>> privacy issues (maybe) is nearly sufficient here.  Instead I
>> would argue that any of these identifier types that could have
>> privacy implications need to be specifically justified or else
>> dropped. By specifically justified, I mean that there ought be
>> an argument (and a fairly holistic one) that the Internet is
>> better, and not worse, if we define a codepoint that allows
>> MIPv6 (and later, other protocols) to use that identifier.  I
>> do accept that my position is perhaps innovative, in terms of
>> IETF processes, so I'll split the discuss into two parts, one
>> process oriented and mostly for the IESG, and the second
>> relating to the content of the draft.
>>
>> (1) For the IESG: is it ok that we introduce (codepoints for)
>> a slew of new long-term stable privacy-sensitive identifiers
>> just because they might someday be needed, or do we need to
>> have specific justification for defining such things? I would
>> argue the latter, but that may need us to validate that there
>> is IETF consensus for that somehow, and perhaps in the
>> meantime hold on to this draft. Part of my reasoning is that
>> once we define such codepoints (e.g. for IMSIs) then that
>> inevitably means that other protocols, and not just MIPv6,
>> will do the same eventually, so accepting this draft basically
>> means accepting that we end up commonly and perhaps
>> carelessly, passing such highly-sensitive information about on
>> the Internet in many protocols and in many contexts.  My
>> argument here I think does adhere to various of our BCPs that
>> do argue for security and privacy, but I do also accept that
>> this may be novel and to some extent goes against another of
>> our generally accepted ideas which is that we benefit from
>> folks documenting things even if those things are sub-optimal
>> in various ways. So I'd argue this is a real case for an IESG
>> discussion - I know what I think, but what do the rest of you
>> think?
>>
>> (2) For the authors: to the extent you are willing to, and
>> want to get ahead of the discussion on point (1) above, can
>> you in fact provide an argument, for each of the identifiers
>> here that have privacy-sensitivity, that the Internet is better
>> overall if we define these codepoints knowing that if we do
>> define a way to represent e.g. an IMSI in MIPv6 that is likely
>> to be copied elsewhere? Note for the authors: I think it's
>> entirely fine for you to do nothing pending the discussion of
>> point (1) above, if that's your preference.
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>>
>> While I'm entirely sympathetic to Mirja's discuss point, I
>> don't think that a statement here can really constrain how
>> these identifiers, once they are defined, are used in other
>> protocols. While there is a chance that some IESG sometime
>> might say "hold on, RFCxxxx (this doc) says you SHOULD encrypt
>> if <that> identifier is used" the chances that a future IESG
>> notice this isn't that high, but it's also even more likely
>> that the designers of future protocols will successfully argue
>> that since not all identifiers are privacy sensitive, their
>> specific protocol need not adhere to the SHOULD. In the end, I
>> think that should or SHOULD will be ineffective.
>>
>>
>> _______________________________________________
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm
>>
>