Hi Deb,Taking both your messages into account, I agree that we should retitle Section 3 and make clear that we are discussing risks. I also agree that we should clearly reference 802.1AR, and that we state it's limitations. In brief, 802.1AR specifies the form of the Subject, the crypto to be used, and which extensions are required. These sorts of profiles for IOT are pretty common. I also agree that we should take care to separate certs and keys in our language. I wish you had been available to do the 8520 review ;-)
Thanks, On 13.04.2024 15:26, Deb Cooley wrote:
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 >
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
