Ballot for draft-ietf-opsawg-mud-acceptable-urls
Discuss
Yes
No Objection
Abstain
No Record
Summary: Needs a YES. Has 2 DISCUSSes. Needs 2 more YES or NO OBJECTION positions to pass.
I don't have a ton of experience w/ mud, but I do have a fair bit of experience w/ PKI certs. I think there is work to be done on this draft to tighten it up and make it clearer, hence my discuss. Where I could, I have made suggestions. I agree with the other comments on this draft. Shepherd writeup: It would be nice to enumerate the manufacturers that have implemented this concept. The link to 'https://mudmaker.org' causes my browser to throw big flashy warning signs. When I click through them, it tells me to 'GO AWAY'. fun... Section 3.1 upgrade causes vulnerabilities: One would think that this situation should be avoided at all costs. There could be a way for the device to signal which version of F/W it is running, allowing the MUD file to be tailored. Section 3.2: The same applies for this section as well. False positives can be just as dangerous (because they bury the real positives). Section 4: Updating IDevID URLs can't be updated with a F/W update? F/W updates are signed by the manufacturer's signing key, correct? Section 4.2: Just how hard would it be to specify the CA certificate paired with a subject name (subject alt name, or CN)? Seems like this is more secure than your proposed methods. Oddly enough, Section 5.1 proposes this. Section 5, last para: Instead of subject names, SKI should be used [RFC5280, section 4.2.1.2]. This can be easily checked in a certificate validate that is presented. Section 5.2: Can't this be used all the time? Section 5.3.3: Classically to change a 'root' one signs the new with the old and signs the old with the new. If it is done this way, I suspect one could change whatever names, CAs one needs to change. Section 7: One might argue that the use of server authenticated TLS might mitigate a bunch of concerns. Section 9. This is confusing. Please seperate the before issues and the after issues into seperate sections (at least). There are many potential vulnerabilities listed earlier in the draft. Please consolidate those here (possibly with draft section links to where the mitigation is suggested).
Nits: Section 1, para 6: change 'check the signatures, rejecting files whose signatures do not match' to '... whose signatures do not validate'. Using language like 'match' leads to bad behavior, when the entity should be taking a positive action to validate the signature. Section 9, last sentence: jargon? I'm not sure I know what this means, and English is my (only) language.
Despite having reviewed a number of the recent MUD specs, I'm not sufficiently expert in the subject area to be confident all my concerns below are right, so naturally I'm open to correction. That being said, I do have several concerns about the document that I'd like to resolve (either with changes to the document, or a clue bat) before it moves forward. Thanks in advance. ### Section 5.1 -- AND or OR? It matters! Subsequent MUD files are considered valid if: * they have the same initial Base-URI as the MUD-URL, but may have a different final part * they are signed by an equivalent End Entity (same trusted CA and same Subject Name) as the "root" MUD file. It’s not explicit if the requirement is that either condition is fulfilled, or both. I assume the requirement is both, but please make this explicit. I think it would scan better if you got rid of the bullets and just made this a regular sentence, although I guess you’d have to get rid of the “but” clause in the first bullet (which would be an improvement in my book). But do it however you wish, as long as it’s unambiguous. An "and" between the bullets is the minimum fix (assuming I'm right of course). ### Section 5.1 -- what to do with those darn suspicions MUD managers SHOULD keep track of the list of MUD-URLs that they have successfully retrieved, and if a device ever suggests a URL that was previously used, then the MUD manager should suspect that is a rollback attack. What, specifically, is the MUD manager supposed to do if it has this suspicion? I’m somehow picturing the manager giving the client a very stern look 🧐 but otherwise doing nothing, because the developer who implemented it wasn’t given any guidance by the specification. ### Section 5.1 -- any URL that was previously used is suspicious O RLY? Further to the previous, as written it sounds to me as though this could describe a perfectly innocent situation. As in, - Device A of type N with firmware version 1 is powered up and suggests URL foo - MUD manager retrieves foo and adds it to its “successfully retrieved” list - Now device A is upgraded to firmware version 2 and suggests URL bar - MUD manager retrieves bar and adds it to its “successfully retrieved” list - Now a new device B of type N with firmware version 1 is powered up and suggests URL foo - MUD manager consults its list, finds foo was previously retrieved, and becomes suspicious, gives B the stink-eye Perhaps you mean “previously used *by that device*” in which case you should say so (although I still hope you’ll clarify what the manager is supposed to do with its suspicion). Or, perhaps you mean something else entirely, in which case let’s discuss. (Even if it's "by that device" aren't there benign cases, such as a factory reset?) This requirement also appears to fly in the face of Section 6, see below. ### Section 5.3.2 -- new requirement? OR restatement? Note, however, that a 301 Redirect that changed the hostname SHOULD NOT be accepted by MUD controllers. Is this a restatement of a preexisting requirement (in which case a reference is called for) or a new requirement (in which case it seems lacking in detail)? ### Section 6 -- file update mechanisms WUT? The MUD file update mechanisms described in Section 3 requires that the MUD controller poll for updates. I don’t see any such requirement enumerated in Section 3. In fact, Section 3 has no requirements whatsoever, it reads like a litany of complaints about what a bad idea MUD file in-place updating is, as a way of motivating why the methods of Sections 4 + 5 should be used instead. Possibly this is just a combination of my lack of knowledge of the MUD document set, combined with less-than-precise wording of the quoted text. Would it be correct to re-word something like, NEW: If MUD files are updated in place, as discussed in Section 3, the updates will not be detected unless the MUD controller polls to discover them. I.e., write the sentence in terms of natural consequences, without using the r-word ("requires") and without implying that Section 3 describes a mechanism. ### Section 6 -- in-place updates vs. the suspicious nature of the controller Furthermore, the “previously used ... suspect” language I’ve already commented on seems to preclude (or at least cast suspicion on?!?) in-place updates, that you're now telling me are just fine. I'm tempted to suggest you clear this up by removing the Section 5.1 text I quoted earlier, but since I don't have enough knowledge of the problem space, I don't know if that's right. What I do know is that *some* resolution of this contradiction appears called for.
i am not a mud expert, however i found the document well written giving me some indication on the technical objective of MUD and the problem/solution space identified in this draft. [observation about the abstract] i am not convinced that the use of 'to declare' covers 100% the document intent. To me "declare" formally means to make a clear, explicit, or authoritative statement or announcement. The draft prescribe that under certain conditions the behaviors of a specific device, described in the original MUD file will no longer apply and consequently provides mechanisms to access and process an updated MUD file. This suggests the document not only announces a new MUD's validity but also outlines the update process, indicating a scope beyond mere declaration.
Thanks to Darrel Miller for his ARTART review. Like Eric, I also found the sudden writing style shift in Section 5.3.1 to be a bit jarring. Some intro text or a more clear title might be better here.
Thanks to Darrel Miller for the ARTART review. Agree with Darrel's comments. It would be good to choose "MUD manager" (5 instances) over "MUD controller" (24 instances) because RFC 8520 indicates that "MUD controller" is an outdated synonym. Section 4 mentions confusion regarding QRCodes and URLs, given the URL reference is to RFC 3986, which depends on RFC 3490 for IDNA, you way wish to add a reference to https://datatracker.ietf.org/doc/html/rfc5890#section-4.4
I am balloting on this document from a GEN area perspective. ** Section 3.1 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 the 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 contrasts with an alternative situation where the vehicle is parked at, for instance, a remote cabin, and where an upgrade failure could cause a much greater inconvenience. The situation for upgrades of medical devices has even more considerations involving regulatory compliance. I’m having trouble understanding the examples provide and the associated analysis. Editorial recommendation: cut all the text after the first sentence. Otherwise: -- What does vehicles, aircraft and medical devices have to do with MUD? Is there existing and planned penetration of MUD in those markets? -- Per “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 ...” Where does the suggestion that moving cyber-physical systems should upgrade their firmware in use come from? -- What is the basis for the claim that the regulatory compliance of medical devices is more considerations than say of aircraft? ** Reference [falsemalware] "False malware alerts cost organizations $1.27M annually, report says", 18 January 2020, <https://www.scmagazine.com/home/security-news/false- malware-alerts-cost-organizations-1-27m-annually-report- says/ and http://go.cyphort.com/Ponemon-Report-Page.html>. Pick a single URL.
I am supporting John's discuss on mitigation to "rollback attack". If the mitigation is well defined and understood then I would strongly recommend to put a reference to the mitigation.
# Éric Vyncke, INT AD, comments for draft-ietf-opsawg-mud-acceptable-urls-11 Thank you for the work put into this document. Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Henk Birkholz for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric # COMMENTS (non-blocking) ## Section 3.1 About the 2nd paragraph, the conflation of unsecure protocols (telnet) with a no-credential use case is confusing. The issue discussed here is not telnet vs. SSH but poor credentials. Suggest removing telnet/http protocols in the example. The 4th paragraph is important but I fail to see the link with this section "adding capabilities". ## Section 3.3 ALso unsure whether this section should be in this I-D. ## Section 4 References to the protocol for MUD sources are probably welcome. ## Section 4.1 `That it, the signing authority is pinned. ` should this be "that is" ? Also, I am not sure whether all readers will understand what is meant by "pinned". ## Section 5 What is the meaning of the "proposed mechanism" in a standard track document? Let's be more assertive and remove "proposed". Is there a common definition of "lowest Certification Authority (CA)" ? If so, a normative reference is welcome. "SHOULD" is used twice, when can an implementation deviate from the "SHOULD" ? I.e., why not a "MUST". ## Section 5.1 Where is "Base-URI" defined in this (or in another document) defined ? To be honest, I was about to ballot a blocking DISCUSS on this point. s/it contains the same series of segments/it contains the same serie of segments/ ? In `if a device ever suggests a URL that was previously used` how can a device downgrade to a previous firmware ? ## Section 5.3.1 Is this just an example ? If so, let's be clear in the section title. Last paragraph, should it be a "MUST" in `The manufacturer must continue to serve`. ## Section 5.3.2 Why can an implementation deviate from the `SHOULD NOT` ? ## Section 6 Should this section use more normative uppercase verbs ? ## Section 7 Is there any change wrt to RFC 8520 privacy considerations ? # NITS (non-blocking / cosmetic) I find the use of "!" in an IETF document rather unusual, but this is a matter of taste. ## Section 5.1 s/series of segment/series of segments/ ?
I agree with many things from the SecDir review from Christian Huitema: https://datatracker.ietf.org/doc/review-ietf-opsawg-mud-acceptable-urls-11-secdir-telechat-huitema-2024-04-02/ I think the concept of small vs big changes is problematic. There is also the issue of any lower version being seen as a roll back attack. If successfull, it would prevent an administrator to downgrade the MUD file after finding that it is preventing proper functioning. A device has a firmware version and a MUD file that belongs to that version. It seems this draft says that the MUD file can be upgraded to firmware versions it was not intended for. It seems the simple fix is to not do that. Updating a MUD file to plug a security hole seems the wrong mechanism. Instead of updating the MUD file, the firmware should be updated (and that firmware should come with a new MUD file covering that firmware version) So I am confused about the mechanim of the firmware handing a URL to the MUD manager, who then picks up the MUD file from the manufacturor. In a way, one could see this as a firmware that has a bit of external firmware hosted elsewhere. And these two can get out of sync. To me that just seems like broken firmware and building a protocol mechanism to resolve this seems the wrong way to fix this. Similarly, changing a MUD file location seems to be something that should be addressed in a firmware update - including updating the location of future firmware updates. I don't see a way for this document to resolve my issues, so instead of balloting DISCUSS, I am ABSTAINing.