[OPSAWG] AD review of draft-ietf-opsawg-mud-acceptable-urls-09

["Rob Wilton (rwilton)" <[e-mail]>]

Hi authors, WG,

Here is my AD review of draft-ietf-opsawg-mud-acceptable-urls-09.

I reviewed this doc slightly out of sequence because it was related to other MUD files that I was reviewing and also my recent discuss on draft-ietf-suit-mud-07<https://datatracker.ietf.org/doc/draft-ietf-suit-mud/>.

I think that the document is fine and reasonably clear but could do with a bit of language clean up and clarity in a few places.  I’ve included my review comments below and also some grammar nits from a grammar tool at the end.


I think that these updates should be pretty easy to do, so if you are able to act on them and preferably get a revised ID by this Thursday, then it increases the chance that I can get this processed through the IESG evaluation before Mahesh takes over.



Moderate level comments:



(1) p 2, sec 3.  Updating the MUD files in place



Would it a better title for this section be: "Possible issues with updating MUD files in place"?







Minor level comments:



(2) p 1, sec 1.  Introduction



   [RFC8520] provides a standardized way to describe how a specific

   purpose device makes use of Internet resources and associated

   suggested network behavior.  The behaviors are described in a MUD

   file hosted in its manufacturer's server.  The device provides a MUD

   URL to the network manager, which can locate this MUD file and

   determine the required network authorization of the device.



"specific purpose device" sounds like slight strange phrasing to me.





(3) p 2, sec 1.  Introduction



   [RFC8520] does not specify how MUD controllers establish their trust

   in the manufacturers' signing key: there are many possible solutions

   from manual configuration of trust anchors, some kind of automatic

   configuration during onboarding, but also including to Trust on First

   Use (TOFU).  How this initial trust is established is not important

   for this document, it is sufficient that some satisfactory initial

   trust is established.



"but also including to" doesn't scan well to me.





(4) p 3, sec 3.1.  Adding capabilities



   While there is an argument that old firmware was insecure and should

   be replaced, it is often the case that the upgrade process involves

   downtime, or can introduce risks due to needed evaluations not having

   been completed yet.  As an example: moving vehicles (cars, airplanes,

   etc.) should not perform upgrades while in motion!  It is probably

   undesirable to perform any upgrade to an airplane outside of its

   service facility.  A vehicle owner may desire only to perform

   software upgrades when they are at their residence.  Should there be

   a problem, they could make alternate arrangements for transportation.

   This is constrasted with the situation when the vehicle is parked at,

   for instance, a remote cabin.  The situation for upgrades of medical

   devices has even more considerations involving regulatory compliance.



Perhaps change: This is contrasted with ... => This contrasts this with an alternative situation where the vehicle is parked at, for instance, a remote cabin, where an upgrade failure could cause a much greater inconvenience.





(5) p 5, sec 4.  Updating the MUD URLs



   The QRcode mechanism is usually done via paper/stickers, and is

   typically not under the control of the device itself at all.

   However, being applied by a human and not easily changed, a MUD URL

   obtained in this fashion is likely trustworthy.  (It may not, due to

   mixups in labeling represent the correct device, but this is a human

   coordination issue, and is out of scope for this document.)



Is this definitely trustworthy?  E.g., we have a spate of scams in the UK where folks put new QR codes on the parking machines directly folks to pay at fraudulent websites instead.  This scenario is obviously different, but would presunably still allow a supply-chain attack to occur?





(6) p 6, sec 4.2.  Concerns about same-signer mechanism



   This works as long as manufacturers use a single key to sign all

   products.  Some manufacturers could sign each product with a

   different key.  Going logically down this path, if all these product

   keys are collected into a single PKI, signed by a common

   certification authority.



The second sentence doesn't make sense to me.  Or otherwise, as a paragraph it is incomplete.





(7) p 6, sec 5.  Proposed mechanism



Perhaps rename this section to "Proposed mechanism for updating MUD URLs"?





(8) p 7, sec 5.  Proposed mechanism



   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.



When could this actually change?  I.e., if it only accepts MUD files with the same base URL then, by definition, they must all be peers of each other, right?  Ah, the MUD-URL in the new MUD file can be used to give a new canonical path of where the MUD file should be found.  I think that this text would benefit from being a lot clearer.





(9) p 8, sec 5.1.1.  Changing file structure



   The manufacturer simply changes the MUD-URL contained with the files

   at the old location to have a value of

   https://example.com/mudfiles/toasters/model1945/mud.json.  The

   manufacturer must continue to serve the files from the old location

   for some time, or to return an HTTP 301 (Moved Permanently)

   redirecting to the new location.



Possibly it would be cleared to also indicate that the file must also be served at the new location at the same time.  I.e., for a period of time, the same mud file is served up at two different locations, only one of which is regarded as being tbe canonical path.





(10) p 8, sec 5.1.2.  Changing hosting URLs



   The manufacturer simply changes the MUD-URL contained with the files

   at the old location to have a value of

   https://example.com/mudfiles/toasters/model1945/mud.json.  The

   manufacturer has to continue to host at the old location until such

   time as it is sure that all MUD controllers have loaded the new data,

   and that all devices in the field have upgraded their URL.  A 301

   Redirect that changed the hostname SHOULD NOT be accepted by MUD

   controllers.



I'm not really convinced that this example is materially different from the one above.





(11) p 9, sec 7.  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.



Should this be "The MUD URL could contain sensitive model and ..., thus, the MUD URL ..."?







Nit level comments:



(12) p 4, sec 3.2.  Removing capabilities



   In this case, the old device will be performing unwanted connections,

   and the MUD controller will be alerting the network owner that the

   device is misbehaving rather than not upgraded.  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].



"not upgraded" => "not being upgraded"





(13) p 5, sec 4.1.  Leveraging the manufacturer signature



   When the first time a signature of the MUD file related to a

   particular device-type is verified by the MUD controller, the

   identity of the signing authority is recorded.  That it, the signing

   authority is pinned.  This policy means that subsequent MUD files

   must be signed by the same entity in order to be accepted.



"When the first time" => "The first time".





(14) p 5, sec 4.1.  Leveraging the manufacturer signature



   The trust and acceptance of the first signer may come from many

   sources, for example, it could be manual configured to trust which

   signer, or using the IDevID mechanism for the first MUD URL and the

   signer of the corresponding MUD file is more trustworthy, or the MUD

   controller can use a Trust on First Use (TOFU) mechanism and trusts

   the first signer by default.



"... manual configured to trust which signer" doesn't scan well.  Perhaps something like "... manually configured to trust particular signers, or, as a more trustworthy approach, use the IDevID mechanism for the first MUD URL and as the signed of the corresponding MUD file, "?





(15) p 6, sec 4.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.  This could be a

   policy OID, or could involve some content in a subjectAltName.

   Future work could go in this direction.  This document proposes a

   simpler solution.



Probably "that direction" is better than "this direction".





(16) p 9, sec 6.  Polling for changes in MUD files



   The manufacturer SHOULD serve mud files from a source for which ETag

   Section 2.3 of [RFC7232] may be generated.  Static files on disk

   satisfy this requirement.  MUD files generated from a database

   process might not.  The use of ETag allows a MUD controller to more

   efficiently poll for changes in the file.



s/mud/MUD/





(17) p 10, sec 9.  Security Considerations



   3.  somehow get the manufacturer to sign the alternate MUD



... alternative MUD file.



Grammar warnings from tooling:

Grammar Warnings:
Section: 3.1, draft text:
It is probably undesirable to perform any upgrade to an airplane outside of its service facility.
Warning:  This phrase is redundant. Consider using outside.
Suggested change:  "outside"

Section: 5.1.2, draft text:
The manufacturer has to continue to host at the old location until such time as it is sure that all MUD controllers have loaded the new data, and that all devices in the field have upgraded their URL.
Warning:  "It is sure" is uncommon. Consider using certain.
Suggested change:  "certain"

Section: 7, draft text:
Thus the MUD URL identifies the make, model and revision of a device.
Warning:  A comma may be missing after the conjunctive/linking adverb 'Thus'.
Suggested change:  "Thus,"

Section: 9, draft text:
Prior to the standardization of the process in this document, if a device was infiltrated by malware, and said malware wished to make accesses beyond what the current MUD file allowed, the the malware would have to:
Warning:  Possible typo: you repeated a word
Suggested change:  "the"

Section: 9, draft text:
A manufacturer which has not managed their MUD files in the the way described here can deploy new directories of per-product MUD files, and then can update the existing MUD files in place to point to the new URLs using the MUD-URL attribute.
Warning:  Possible typo: you repeated a word
Suggested change:  "the"

Section: 9.1, draft text:
Developers should be aware that many enterprise web sites use outsourced content distribution networks, and MUD controllers are likely to cache files for some time.
Warning:  Nowadays, it's more common to write this as one word.
Suggested change:  "websites"


Thanks,
Rob