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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <noreply@xxxxxxxx> 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
> last-call@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/last-call

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux