Hi Michael,
thanks for your feedback. In version -08 we have addressed your feedback. A few remarks below:
-----Ursprüngliche Nachricht-----
Von: Suit <suit-bounces@xxxxxxxx> Im Auftrag von Michael Richardson via Datatracker
Gesendet: Mittwoch, 31. Januar 2024 01:04
An: iot-directorate@xxxxxxxx
Cc: draft-ietf-suit-mud.all@xxxxxxxx; last-call@xxxxxxxx; suit@xxxxxxxx
Betreff: [Suit] Iotdir telechat review of draft-ietf-suit-mud-07
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.
[hannes] We have removed the sentence.
> 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,
[hannes] We also made that change; it feels like an omission from our side.
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!
[hannes] We moved the sentence.
* 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.
[hannes] Good point. It didn't cross our mind to highlight this aspect but I believe it is a worthwhile addition.
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.
[hannes] It may have been but I am not the author of the SUIT report and hence I have missed some of the discussions.
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.
[hannes] You could move functionality around, if you want, but it does not make a big difference IMHO.
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.
[hannes] Added this reference.
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"?
[hannes] Probably a copy-and-paste error.
Would be nice if Section 3 mentioned RFC8995.
[hannes] Done.
Ciao
Hannes
_______________________________________________
Suit mailing list
Suit@xxxxxxxx
https://www.ietf.org/mailman/listinfo/suit
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
