Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-acceptable-urls-02.txt

From: [email-masked]
Date: Fri, 19 Feb 2021 10:20:26 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Operations and Management Area Working Group WG of the IETF.

        Title           : Authorized update to MUD URLs
        Authors         : Michael Richardson
                          Wei Pan
                          Eliot Lear
	Filename        : draft-ietf-opsawg-mud-acceptable-urls-02.txt
	Pages           : 11
	Date            : 2021-02-19

Abstract:
   This document provides a way for an RFC8520 Manufacturer Usage
   Description (MUD) definitions to declare what are acceptable
   replacement MUD URLs for a device.

   RFCEDITOR-please-remove: this document is being worked on at:
   https://github.com/mcr/iot-mud-acceptable-urls

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-acceptable-urls/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-acceptable-urls-02.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-mud-acceptable-urls-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Michael Richardson <[email-masked]>
Date: Sun, 21 Feb 2021 14:07:56 -0500

> https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-mud-acceptable-urls-02

The text of the document has been revised for better flow.
Some content in the introduction has moved to section 3.

Section 4, which is the core of the proposal has been slightly tweaked, but
essentially remains the same: when signaling a changae to the MUD URL via
insecure mechanisms that malware may control (DHCP, LLDP), only changes to
the last component of the MUD URL are permitted.

The new mud file may contain a new MUD-URL, which is substantially different
from the original one, and this allows the manufacturer to re-organize their
site (or even change sites entirely).  But this is controlled because the new
file must be signed by the same signer as the original file.

This document makes some statements in section 3.3 about pinning of the
signing entity.  This language is not at this point normative.

This document has marked itself as a BCP in the header, although it has grown
some BCP14 language.  It seems that it an error, that it should be standards
in order track to Update RFC8520, and should include BCP14 language.
How does the WG feel about that?  The adoption call did not say anything
about intended status.

There is an option issue at the end of section 4:
      XXX: how should the trust anchor for the signature be updated when
      there is Merger&Acquisition)

There are a number of different ways in which this could be handled.
Getting it right, and making it interoperable would require that we make some
more substantive normative statements about how the MUD controller pins the
signing entity from the Manufacturer.

While this seems slightly esoteric to worry about M&A actitivy, establishing
the long-term identity of the manufacturer seems pretty important.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide