Re: [Last-Call] [core] Genart last call review of draft-ietf-core-dev-urn-08

Jari Arkko <jari.arkko@piuha.net> Mon, 04 January 2021 15:06 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24AED3A0DCD; Mon, 4 Jan 2021 07:06:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.003
X-Spam-Level:
X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 0qlobdJNMXyu; Mon, 4 Jan 2021 07:06:13 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id BA00B3A0DBB; Mon, 4 Jan 2021 07:06:13 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 5060266019D; Mon, 4 Jan 2021 17:06:12 +0200 (EET)
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ty5YXKIbf6WE; Mon, 4 Jan 2021 17:06:08 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id D0EE966012A; Mon, 4 Jan 2021 17:06:07 +0200 (EET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <160608671301.5921.450198697310395020@ietfa.amsl.com>
Date: Mon, 04 Jan 2021 17:06:07 +0200
Cc: gen-art@ietf.org, last-call@ietf.org, draft-ietf-core-dev-urn.all@ietf.org, core@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <FCB35115-EE76-40B7-9FF4-0F2A7AD4083D@piuha.net>
References: <160608671301.5921.450198697310395020@ietfa.amsl.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/SrPl0GAZ_dcQtYmBqVPpqs-BtE8>
Subject: Re: [Last-Call] [core] Genart last call review of draft-ietf-core-dev-urn-08
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Jan 2021 15:06:16 -0000

Christer,

Many thanks for your review!

Inline:

> Section 6.1. says:
> 
> "The URNs generated according to the rules defined in this document
> result in long-term stable unique identifiers for the devices."
> 
> - What are those rules?
> 
> In Section 3.3 I do see the following statement:
> 
> "The DEV URN type SHOULD only be used for persistent identifiers, such
> as hardware-based identifiers or cryptographic identifiers based on
> keys intended for long-term usage."
> 
> Is that what you refer to as rules? Or, have I missed something?
> 
> Also, to me the statement seems like an important applicability statement for
> DEV URNs. If so, should there be a separate Applicability (or similar) section
> earlier in the document, which points it out?

I think we created confusion with the way that the 6.1 sentence was formulated. There’s no specific rules; we were just trying to refer to the use of DEV URNs, and make the point that if you keep sending your MAC address in some protocol, it may actually create a privacy problem as others may be able to track you based on that identity (among others).

We were also not trying to make any new applicability statement in the security considerations, beyond what was already said earlier in the document.

I have reformulated the text, it now reads:

  DEV URNs often represent long-term stable unique identifiers for
   devices.  Such identifiers may have privacy and security implications
   because they may enable correlating information about a specific
   device over a long period of time, location tracking, and device
   specific vulnerability exploitation [RFC7721]. 

Does this clarify the issue?

The full new version with other changes is at https://arkko.com/ietf/core/draft-ietf-core-dev-urn-from--08.diff.html

> Section 3.1. says:
> 
> "The DEV URNs identify devices with device-specific identifiers such as network
> card hardware addresses."
> 
> - Can there be multiple DEV URNs associated with a single device?

Yes. Section 3.3. says this now in the new version:

           And of course, a single device may	
 	   (and often does) have multiple identifiers, e.g,. identifiers	
 	   associated with different link technologies it supports.

> Section 3.1. says:
> 
> "DEV URN is global in scope."
> 
> - What does that actually mean?

See RFC 8141 S6.4.1 item 2; we’re requested to specify the scope of the applicability, and it is not e.g. a single nation of company.

But I changed the text to read:

   DEV URNs are
   scoped to be globally applicable (see [RFC8141] Section 6.4.1) and
   enable systems to use these identifiers from multiple sources in an
   interoperable manner.

> In the Introduction, SenML and RD are given as examples where the URN may be
> useful. It would be nice to exactly see some usage examples of the URN. Section
> 5 only contains examples of the URN itself.

That would be good, thanks for the suggestion. I added one example.

Jari