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.
> 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)
> 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.
> 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.
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
> ----------------------------------------------------------------------
> 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.
> 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.
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
