Thanks for that. I look forward to reading the revision. RFC 8520, if only.... [I do get tired of people running up 'oh my, oh my, oh my, our certificates have been exposed!!'. My reply is usally 'so what?'] It is a common mistake, and probably pedantic on my part. But PKI is complicated, and hard to understand. LOL
Deb On Sat, Apr 13, 2024 at 9:42 AM Eliot Lear <l...@lear.ch> wrote: > 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 >> > >> >
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
