Inline.... (prefaced by [DC]) On Fri, Apr 12, 2024 at 9:07 AM Michael Richardson <mcr+i...@sandelman.ca> wrote:
> > Hi, Deb, thank you for the comments. > > Deb Cooley via Datatracker <nore...@ietf.org> wrote: > > > ---------------------------------------------------------------------- > > 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... > > This is not really DISCUSSable. > Some large lighting and microcontroller manufacturers have implemented > RFC8520. > But that’s an issue for 8520 not this document. > We’re not seeking to elevate 8520 at this time: if we were we would provide > interoperation evidence. > [DC]: noted. I will say that much time and effort is being spent on these drafts, hopefully for real systems and real use cases. > > > 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. > > Deb, I think have misunderstood Section 3, and if you did, surely others > will > as well. ALL of section 3 is a risk analysis, and doesn’t go into > resolving > the issues that raised. Section 3 establishes the need for multiple MUD > files being active when devices are at different firmware revisions. > Updating in place is clearly a better choice: when you can do it. > > That’s for Sections 4, 5, and 6. Keep in mind, all of this is about > improving existing deployments of RFC 8520. > We do think the example in Section 3.1 goes off course, and we’ve removed > it. > The device *does* signal which version of MUD file it needs via LLDP or > DHCP > (and perhaps later via SUIT) > [DC] My suggestion then is that you at least change the section title to use the word 'risk', 'threat', or 'vulnerability'. Isn't Section 4 similar (outlining risk for the second option)? If so this comment applies that section as well. Clear and concise language would help both Section 3 and 4. > > > 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? > > As discussed in Eliot's previous message, it’s not possible to update an > 802.1AR > certificate. This is in part because that would require a per-device > action, > and the point of a burned-in certificate is to provide some level of > assurance that it is the manufacturer and not the device that is making > claims about the MUD URL. We might be able to do something with > SUIT, but the manufacturers are not there yet. > [DC] While RFC 8520 mentions various 802.1 protocols, this draft doesn't. The fact that 802.1AR does not allow for key/certificate update, is itself an issue, no? [DC] I could also easily object to the use of the word 'certificate' to represent both private key, certificate, and sometimes certificate validate. It is the fact that the private key is 'burned-in' that is the issue. Certificates are public, and available all over the internet. But RFC8520 is rift with that misuse of that language, so I won't start here. > > > 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. > > We need to make clear which certificate we’re talking about. This is the > detached signature of the MUD file, and the threat occurs when the MUD-URL > itself in Section 4.2 is being emitted via insecure means, such as LLDP or > DHCP, as specified by RFC 8520. > > Malware on the device would modify the MUD URL, as discussed in security > considerations of that document, to choose an inappropriate MUD file that > uses the same trusted CA. > > As you point out, the rules in Section 5.1 limit the risks. Obviously this > is better solved by using more secure communication paths, but for some > manufacturers, especially of older or constrained devices, that’s not > possible. So we are attempting to provide some additional advice in this > insecure case. > > We will clarify the text a little bit to make clear the above. > [DC] Actually since Section 4 is just listing the vulnerabilities and risks, my comment here is OBE. > > > 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. > > We should be clear: it’s not possible to use an SKI for end entity > certificates because those are going to change just as they age. > It is possible for us to use them for CA certificates. > We expect that manufacturers might need to rotate the MUD file End Entity > key pair. > [DC] I thought this section was discussing pinned CA certs? You want to pin the subject name? vice the SKI? or AKI? [this key/cert is on the manufacturer side? and thus can be updated, which is why you want to be able to change the pinned CA cert? no?] > > > > > Section 5.2: Can't this be used all the time? > > If the intended MUD file change is bound to a firmware update, then it > cannot be used when old firmware needs the old MUD file and new firmware > needs the new one. > [DC] in that case, nothing can be changed? > > > > > 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. > > We aren't trying to change the root here, but rather to continue to use the > same End Entity certificate that was used the first time. So SKI pin for > CA, > with SubjectAltName pin for the EE. > [DC] if the CA changes, the EE certificate will also change. Subject Name or SubjectAltName? pick one. The 'sign new with old, and old with new', is useful for other circumstances besides Root CAs. > > > > > Section 7: One might argue that the use of server authenticated TLS > might mitigate a bunch of concerns. > > If we are just repeating RFC8520's concerns, we could remove the section. > The second paragraph suggests server authenticated TLS. > [DC] who knew? I didn't look at the comments on RFC8520 when it was being approved. I'm just suggesting that server authenticated TLS would mitigate all sort of other concerns besides privacy 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). > > I understand the confusion, and maybe section 9.0 is more of a conclusion. > I will rework that section. > > [DC] I don't know what the right answer is, but if Sections 3 and 4 list the risks/vulnerabilities, then maybe you could reference them? > > > > ---------------------------------------------------------------------- > > 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. > > changed match to validate. > [DC] TY > > > Section 9, last sentence: jargon? I'm not sure I know what this > means, and > > English is my (only) language. > > Is it this sentence: > > > There is therefore no significant flag day: MUD controllers may > > implement the new policy without significant concern about backwards > > compatibility. > > [DC] it is. I have no idea what 'significant flag day' means. > > -- > Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > >
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
