Subject: [OPSAWG] comments on draft-richardson-opsawg-mud-acceptable-urls-03

From: Michael Richardson <[email-masked]>
Date: Wed, 20 Jan 2021 20:08:05 -0500

It was clarified to me privately that the title was misleading, and these
comments relate to draft-richardson-opsawg-mud-acceptable-urls-03
rather than draft-lear-opsawg-sbom-access-00!

Let me start a new thread then.

tangtianqing <[email-masked]> wrote:
    > I’ve read this draft and I support the adoption. Besides that, I have
    > some comments below:

    > 1)

    > 1.  Introduction While MUD files may include signatures, it is not
    > mandatory to check them, and there is not a clear way to connect the
    > entity which signed the MUD file to the device itself. A malicious
    > device does not need to make up a MUD file if there is already an
    > available, and already trusted MUD file which it can use to impersonate
    > the device.

    > Comment > I think not checking signatures will cause significant
    > vulnerability, and I also find RFC8520 doesn’t mention whether it’s
    > mandatory to check signatures. Therefore, I am confused that if there
    > is any special purpose or consideration not to check signatures of MUD
    > files.

    > 2)

    > 1. Introduction One defense against this is to not trust MUD URLs which
    > are different from the one that was placed in an IDevID. Or if the
    > initial MUD URL was not taken from an IDevID, it could be trusted on
    > first use.

    > Comment > What does "this" mean? Does it refer to the problem that a
    > device is unable to verify if the MUD URL belongs to itself, or the
    > method above that cannot connect the MUD file signer with the device
    > itself?

    > Comment > If IDevID mechanism is applied, why other MUD URLs exist? Or
    > is it better here to say “MUD controller shouldn’t trust other MUD URLs
    > than the one placed in an IDevID”?

    > 3)

    > 2.1.2. Removing capabilities In this case the old device will be
    > performing unwanted connections, and the MUD controller when be
    > alerting the device owner that the device is mis-behaving. This causes
    > a false positive situation (see [boycrieswolf]), leading to real
    > security issues being ignored. This is a serious issue as documented
    > also in [boywolfinfosec], and [falsemalware].

    > Comment > What does “real security issues” mean? Does it means that the
    > device owner mistakenly judge that the device is not upgraded as
    > misbehaving?

    > 4）

    > 2.1.3. Significant changes to protocols [I-D.reddy-opsawg-mud-tls]
    > suggests MUD definitions to allow examination of TLS protocol
    > details. Such a profile may be very specific to the TLS library which
    > is shipped in a device. Changes to the library (including bug fixes)
    > may cause significant changes to the profile, requiring changes to the
    > profile described in the MUD file. Such changes are likely neither
    > forward nor backward compatible with other versions, and in place
    > updates to MUD files are therefore not indicated.

    > Comment > In my understanding, I think version updates should take
    > compatibility into consideration, even for bug fixes. So why do you
    > think they are likely not compatible with other versions?

    > 5)

    > 3. Threat model for MUD URLs Only the DHCP and LLDP MUD URL mechanisms
    > are sufficiently close to the firmware version that they can be easily
    > updated when the firmware is updated.

    > Comment > There is no need to limit this draft to DHCP and LLDP
    > mechanisms.  Although the IDvID mechanism makes the MUD URL in the
    > IDvID certificate unchangeable, it can be assumed that a new MUD URL is
    > carried in the firmware when the device is updated. If the new MUD URL
    > matches the rules defined in this draft, then it can be considered
    > reasonable.

    > 6)

    > 3.2. Concerns about same-signer mechanism It is possible to invent
    > policy mechanisms that would link the EE certificate to a value that is
    > in the MUD file.

    > Comment > What is the function of linking the EE certificate to a value
    > that is in the MUD file? How can it solve the problems brought by
    > pinning the CA certificate or pinning the EE certificate?

    > 7)

    > 5. Changes to RFC8520 MUD files contain a self-referential MUD-URL
    > attribute that point to a MUD file located on the vendor’s web site.  .
    > Comment > This sentence may be mistaken as that the MUD-URL attribute
    > in multiple MUD files points to the same MUD file. However, in fact,
    > the MUD-URL attribute in a certain MUD file points to the MUD file
    > itself.

    > 8)

    > 5. Changes to RFC8520 The URL found in the MUD-URL attribute is to be
    > called the canonical MUD URL for the device.

    > Comment > How to understand the meaning of “canonical MUD URL”?

    > 9)

    > 5. Changes to RFC8520 The MUD-SIGNATURE attribute in the MUD file
    > SHOULD be a relative URI (see [RFC3986] section 4.2) with the
    > (hierarchical) base URL for this reference being the MUD-URL attribute.

    > Comment > Does this sentence mean that The MUD-SIGNATURE attribute in
    > the MUD file includes base URI?  Comment > Does “base URL” here has the
    > same meaning with “Base-URI” mentioned in the draft?

    > 10)

    > 5. Changes to RFC8520 Once the new MUD file is accepted, then it
    > becomes the new "root" MUD file, and any subsequent updates must be
    > relative to the MUD-URL in the new file.

    > Comment > I feel that it’s better to make this requirement normative
    > here. Is it appropriate to use “MUST” or “SHOULD”?

    > 11) 6. Privacy Considerations The MUD URL contains sensitive model and
    > even firmware revision numbers. Thus the MUD URL identifies the make,
    > model and revision of a device.

    > Comment > It may be recommended that MUD URLs use a random character
    > string instead of the plaintext information, because the plaintext
    > information is easy to guess (i.e. “The MUD URL contains sensitive
    > model…”)

    > 12)

    > 5. Changes to RFC8520 Subsequent MUD files are considered valid if: *
    > have the same initial Base-URI as the MUD-URL, but may have a different
    > final part…

    > Comment > I suggest that describe “MUD URL”, “MUD-URL”, and “mud-url”
    > in advance due to their different meanings.

    > 13)

    > 7. Security Considerations …depend upon the MUD-manager either not
    > checking signatures, or…

    > Comment > I suggest that replace “MUD-manager” with MUD controller for
    > consistency.

    > Best wishes, Tianqing Tang

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