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 protected]> 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 protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
