Last Call Review of draft-ietf-core-dev-urn-08
review-ietf-core-dev-urn-08-secdir-lc-weis-2020-12-03-00

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.