Thanks for the site config fix. 802.1AR you say? No mention of 802.1 in the draft at all. If the PKI rules are different in 802, seems like that would be good to at least mention. At least distinguish whether we are talking about L2 or L3 (or app layer - wherever HTTPS lives)
Deb On Thu, Apr 4, 2024 at 8:26 AM Eliot Lear <l...@lear.ch> wrote: > 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 > > >
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
