Hi Deb, On 04.04.2024 13:45, Deb Cooley via Datatracker wrote:
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...
Hi Deb. There was a config error on a server. It's fixed. Thanks for pointing it out.
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.
This may or may not be possible. It depends on how the MUD URL is communicated. If it's communicated in a certificate, then the cert would have to change, and as 802.1AR makes clear, that's not supposed to happen. I hold out hope that SUIT will provide a better path here, but these are still early days.
I should point out that in the vast majority of cases, a MUD URL rarely has to change because you can have a superset of access that won't be at all harmful (a good example would be adding a new new endpoint that is used by new versions). The corner case is primarily about services being turned off.
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?
See above. Not permitted by 802.1AR. But there may be a more SUITable fix over time.
I'll leave the the rest to Michael. Eliot
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. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
