Reviewer: Michael Richardson
Review result: Ready with Issues
Reviewer: Michael Richardson
Review result: Has minor Nits
I am the assigned reviewer of this draft for IoTdir.
The draft’s main purpose is to communicate MUD descriptions to a SUIT
(Software Update for IoT) status tracker.
I found this paragraph:
When the MUD URL is included in a certificate then it is
authenticated and integrity protected. However, a certificate
created for use with network access authentication is typically not
SIGNED BY THE ENTITY THAT WROTE THE SOFTWARE AND CONFIGURED the
device, which leads to a conflation of rights.
difficult. I see no reason why they are not related, and I do not see a
conflation of rights at all. Either trust the manufacturer or don't.
What makes use of the certificate use difficult is that it is *NOT* updated
when the software is updated. The next paragraph explains it better.
I would just remove the second sentence from above, as I don't think it adds
anything.
> Attestation-related terminology is defined in [RFC9334].
it would be nice if the specific terms were mentioned as imported.
I think the list is: (Attestation) Evidence, EAT,
section 4.1:
* The onus is placed on the software/firmware author to provide a
MUD file that describes the behavior of the software running on a
device.
I don't see this as a Pro (or Con). Just an is!
* The author explicitly authorizes a key to sign MUD files,
providing a tight coupling between the party that knows device
behavior best (the author of the software/firmware) and the party
that declares device behavior (MUD file signer).
I think that this is really useful/important part that 8520 left out.
In section 5, readers might think that COSE-Thumbprints might only apply to
COSE keys, but they can apply to any kind. That might be worth pointing out.
I'm also concerned that some might think the "ski" is the same as the
RFC5280's SubjectPublicKeyInfo.
At some point I thought that the MUD URL was going to be in the SUIT Report.
Was it at some point? A weakness of this scheme is that the MUD
infrastructure gets to see what MIGHT be installed via SUIT, but isn't sure
when it actually *IS* installed.
As I understand things, I guess the MUD manager is now responsible for
verifying the SUIT Manifest that it retrieved. It seems like it ought to be
the Status Tracker.
I found the Cons section underwhelming.
Some nits:
at:
In case of DHCP
and LLDP the URL is likely unprotected and not bound to the device
itself.
this could reference draft-ietf-opsawg-mud-acceptable-urls section 4.
I found that the description that they could be conveyed in 802.1X to be
overly specific. Any protocol that uses certificates can use the IDevID
extensions, and not every EAP method actually uses certificates; just the TLS
based ones in general. This is a quibble though.
In Diagram "Figure 2", there is the word "Serverdig", and I think it
should just be "Server"?
Would be nice if Section 3 mentioned RFC8995.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
