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
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
