[OPSAWG] Deb Cooley's Discuss on draft-ietf-opsawg-mud-acceptable-urls-11: (with DISCUSS and COMMENT)

[Deb Cooley via Datatracker <[e-mail]>]

Deb Cooley 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:
----------------------------------------------------------------------

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).


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


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.