John Scudder has entered the following ballot position for draft-ietf-opsawg-mud-acceptable-urls-11: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-acceptable-urls/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- 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. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg