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

From: Jari Arkko <[email-masked]>
Date: Mon, 4 Jan 2021 15:48:26 +0200

Brian: 

Many thanks for your review. I’m going through the various review comments and taking them into account. I agree with the three points you made. A new version will be submitted soon, for the moment you can see the changes in https://arkko.com/ietf/core/draft-ietf-core-dev-urn-from--08.diff.html and https://arkko.com/ietf/core/draft-ietf-core-dev-urn.txt

Jari

> On 3 Dec 2020, at 21.57, Brian Weis via Datatracker <[email-masked]> wrote:
> 
> Reviewer: Brian Weis
> Review result: Serious Issues
> 
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should
> treat these comments just like any other last call comments.
> 
> The summary of the review is Ready with nits.
> 
> This document generally defines a new URN namespace for hardware
> device identifiers, and then further defines the URN body layout
> for several types of devices, where devices are identified by a
> global identity (e.g., a MAC address, organizational-specific serial
> number, etc.).
> 
> Long-term identifiers have privacy considerations, and these are
> well documented here.
> 
> Here are some things that ought to be thought about:
> 
> (1) The Security Considerations section seems to focus on concerns
> around devices not allowing the device identifiers to be modified,
> and gives rather broad advice about a DEV URN implementation
> faithfully representing the device. It would be good for this section
> to also warn implementors of the risks of a DEV URN being transmitted
> without integrity protection. That is, if the device faithfully
> represents itself, a man in the middle changing the DEV URN in a
> protocol may cause the system using the device to not manage the
> device properly, or in some manner inappropriately adjust the privileges
> allowed by the device within that system.
> 
> (2) Section 1 says about privacy “Note that long-term stable unique
> identifiers are problematic for privacy reasons and should be used
> with care or avoided as described in [RFC7721].” Given the later
> guidance that “The DEV URN type SHOULD only be used for persistent
> identifiers”, I think the “or avoided” portion of that sentence is
> inappropriate for this document.
> 
> (3) Section 5 begins with “The following three examples provide
> examples of MAC-based, 1-Wire, and Cryptographic identifiers”. There 
> are now more than three examples provided (thanks for that!), and 
> it appears that cryptographic identifiers have ben removed in an
> earlier draft.
> 
> 
> -- 
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 4 Jan 2021 15:10:30 +0100

On 2021-01-04, at 14:48, Jari Arkko <[email-masked]> wrote:
> 
>  https://arkko.com/ietf/core/draft-ietf-core-dev-urn-from--08.diff.html

So you can’t have a number zero?
Might be worth calling out alongside the fact that there are no leading zeroes.

(From a maintainability POV, calling positive-only numbers “number” in the ABNF is a trap waiting for the next extension.  These are all PENs, no?)

Grüße, Carsten

---

From: Jari Arkko <[email-masked]>
Date: Tue, 5 Jan 2021 11:02:18 +0200

Thanks Carsten. Will change it.

Jari

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 5 Jan 2021 10:45:13 +0100

> Thanks Carsten. Will change it.

Thanks — -09 looks good!

(Inconsequential typo in Appendix A, though: s/ABN/ABNF/)

Grüße, Carsten