Re: [Suit] draft-ietf-suit-architecture-00.txt

[Hannes Tschofenig <[e-mail]>]

Hi Carsten,

 A few remarks below:

-----Original Message-----
From: Suit [mailto:[e-mail]] On Behalf Of Carsten Bormann
Sent: 05 June 2018 11:32
To: [e-mail]
Subject: [Suit] draft-ietf-suit-architecture-00.txt

I had a quick look at this while preparing for the Interop.

Summary: needs work.

The sections are rather inhomogeneous.  The introduction seems to believe this is all about authentication, while Section 3.9 onwards and 4 seem to know that this is really all about authorization.  The introduction claims to be done with just three players, while it later becomes clear there are so many more. etc.  We probably need to make up our minds which of these are part of the “architecture” and which ones are just enabled by the architecture (which may not need to describe every single step of validating an authorization).

[Hannes] The introduction is very short and only focuses on the main aspects to avoid too much repetition. I added an item about authorization to the bullet list. Here is the new text:
----
The firmware update process has to ensure that

- The firmware image is authenticated and attempts to flash a malicious firmware image are prevented.
- Changes to an IoT device, as part of the firmware update process, are properly authorized.
- The firmware image can be confidentiality protected so that attempts by an adversary to recover the plaintext binary can be prevented. Obtaining the plaintext binary is often one of the first steps for an attack to mount an attack.
----

The introduction section itself does not say anything about the involved entities but the terminology lists some of them. I have just posted a mail about the terminology Dave has been suggested. His terminology proposal includes more entities.

The term “claim” is heavily misused.  A claim is just that, a claim.  An instruction to a device to do something is not a claim (at least not without the information what the audience of this instruction is — “all X are instructed to…” is indeed a claim).  In any case, claims (containing instructions or not) always need to be evaluated in the authorization framework of the entity trying to make use of the claim.

[Hannes] Actually, we put this stronger focus on claims in the document because you have been using these terms. We will try to scale down on the claim usage again.

Another example of the seeming naiveté of the introduction: Rollback needs to be properly authorized, not summarily prevented.
(Like any other firmware state change, a.k.a. “upgrade”.)

[Hannes] The requirements section says "Rollback attacks must be prevented". Are you saying that we should instead say that they need to be properly authorized but not prevented?

Most importantly, we need to be very clear what expressions such as “signing the manifest” actually mean, i.e., what exactly is the claim that is signed by that signature.

[Hannes] I believe the details of the signing process will be detailed in the actual solution document.


I also have some editorial comments I’ll send directly to the authors.

Grüße, Carsten

Ciao
Hannes


_______________________________________________
Suit mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/suit
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.