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

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 21 January 2021 01:08 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id AA2AA3A0C1C for <opsawg@ietfa.amsl.com>; Wed, 20 Jan 2021 17:08:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id gKFHTRcfSIhO for <opsawg@ietfa.amsl.com>; Wed, 20 Jan 2021 17:08:09 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BBBE3A0DBC for <opsawg@ietf.org>; Wed, 20 Jan 2021 17:08:09 -0800 (PST)
Received: from localhost (localhost []) by tuna.sandelman.ca (Postfix) with ESMTP id F000238BA3 for <opsawg@ietf.org>; Wed, 20 Jan 2021 20:10:07 -0500 (EST)
Received: from tuna.sandelman.ca ([]) by localhost (localhost []) (amavisd-new, port 10024) with LMTP id WuVv0WSW1N4i for <opsawg@ietf.org>; Wed, 20 Jan 2021 20:10:06 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca []) by tuna.sandelman.ca (Postfix) with ESMTP id 5272938BA1 for <opsawg@ietf.org>; Wed, 20 Jan 2021 20:10:06 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B63C472 for <opsawg@ietf.org>; Wed, 20 Jan 2021 20:08:05 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "opsawg\@ietf.org" <opsawg@ietf.org>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Wed, 20 Jan 2021 20:08:05 -0500
Message-ID: <29347.1611191285@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/lvaPtulTjLViRznNmfgQ0vbfZqU>
Subject: [OPSAWG] comments on draft-richardson-opsawg-mud-acceptable-urls-03
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Jan 2021 01:08:13 -0000

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 <tangtianqing@huawei.com> 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 <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide