[OPSAWG] John Scudder's Discuss on draft-ietf-opsawg-mud-acceptable-urls-11: (with DISCUSS)

[John Scudder via Datatracker <[e-mail]>]

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.