Last Call Review of draft-ietf-core-dev-urn-08

Request Review of draft-ietf-core-dev-urn
Requested rev. no specific revision (document currently at 10)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2020-12-02
Requested 2020-11-18
Authors Jari Arkko, Cullen Jennings, Zach Shelby
Draft last updated 2020-12-03
Completed reviews Secdir Last Call review of -08 by Brian Weis (diff)
Genart Last Call review of -08 by Christer Holmberg (diff)
Opsdir Last Call review of -08 by Dan Romascanu (diff)
Iotdir Telechat review of -09 by Dave Thaler (diff)
Iotdir Telechat review of -09 by Russ Housley (diff)
Genart Telechat review of -09 by Christer Holmberg (diff)
Assignment Reviewer Brian Weis 
State Completed
Review review-ietf-core-dev-urn-08-secdir-lc-weis-2020-12-03
Posted at
Reviewed rev. 08 (document currently at 10)
Review result Serious Issues
Review completed: 2020-12-03


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.