[Suit] AD Review of draft-ietf-suit-information-model-07

[Roman Danyliw <[e-mail]>]

Hi!

I conducted an AD review of draft-ietf-suit-information-model-07.  Thanks for the thorough and systematic treatment of the security considerations.  More detailed feedback is below:

** Abstract.  Per "... have raised the need for a solid ... firmware update mechanism", could an alternative to the colloquial "solid" be used.

** Section 3.2.  Per "This number MUST be easily accessible so that code choosing one out of several manifests can choose which is the latest", what are the additional properties of this number?  I don't follow how "easy accessib[ility]" is related to the ability to compare several values to "choose which is the latest".  Do you mean that "its' not buried somewhere at the end in a complicated encoding"-kind of accessible?

**Section 3.5.  What is a conditions list?  This is this first use of the word in the text; and it isn't defined in the architecture document.

** Section 3.5 and 3.9.  Both of these sections call out a "enables feature" mapping.  Where is the full list of these features?  Why don't the other manifest elements have that mapping?

** Section 3.7 and 4.3.3 Both of these section make references to "secure time" or a "secure clock".  Is there a reference to provide on what that bar might be?

** Section 3.15:  There is an implicit design here around what is "wrapping" the manifest that I'd like to clarify.  Specifically:

-- Per "This is not strictly a manifest element", if so, editorially, why it is listed as a manifest element?

-- This section doesn't explicitly describe what a "Signature" element is.  What information does it encode? 

-- Per "The authentication container MUST support multiple signers and multiple signature algorithms", what is the scope of the signatures (i.e., which subset of the manifest elements?)?  Do the multiple signatures always sign the same thing?

-- What exactly is a manifest vs. "a standardized authentication container"?  Can a standardized authentication container have multiple manifests?

-- What is the relationship between this "standardized authentication container" and a "manifest superstructure"?

-- What other information elements go into the "authentication container"?

** Section 3.15.  Per "Lightweight authentication with pre-existing relationships SHOULD be done with MAC"

-- What is a "lightweight authentication"?

-- If it's not done with a MAC (which is a SHOULD), how is this done?

-- Can "pre-existing relationship" be clarified.?

** Section 3.20 - 3.24.  These sections do not provide guidance on whether these elements are OPTIONAL or REQUIRED.

** Section 3.9, 3.16, 3.21.  To check my understanding of the order in which 3.9, 3.16 and 3.21 are applied -- Section 3.9 is used to guide the decode a payload, Section 3.16 is applied to decide when to run the payload and Section 3.21 used to guide how to load the payload when it is decide it should be run?

** Section 3.21 and 4.5.10.  My read of Section 3.21's "This is effectively a copy operation from the permanent storage location of an image into the active use location of that image.  The metadata ..." left me with the impression of a very narrow capabilities.  However, Section 4.5.10 suggests a richer capability "It MUST be possible to specify additional metadata for load time processing of a payload, such as cryptographic information, load-address, and compression algorithm."  I would have expected that richer description in the definition of the information element, not in a requirement.

** Section 3.23.  Per "The Payload element provides a recipient device with the whole payload ...", the text current defines the "Payload" element name by simply repeating the word "payload". Is "payload" the same as draft-ietf-suit-architecture definition of "firmware image"?  If so, it would be worth saying that.  If not, what is the relationship between them?

** Section 3.24.  Can you clarify the statement of the key claim not being authenticated.  I'm taking "authenticated" to mean not signed by the Signature element -- assuming this is in the manifest, what other information elements are in the manifest but not authenticated?

** Section 4.2.2.  Editorially, this attack is titled "ROLLBACK".  This characterization doesn't seem right as the device isn't being downgraded to a version older than it is currently running.  It just isn't getting the latest version.

** Section 4.2.2.  I think we need to soften the "mitigated by" language.  REQ.SEC.EXP is invoking an optional features usable only when certain devices (i.e., those with secure clocks)

** Section 4.2.2.  Is there another exposure here to discuss with the use of Expiration Time if the author goes out a business?  Consider if the device is running version 1 and is offline for a while.  The author publishes version 2 with important patches but puts an "expired time" in it.  The author goes out of business.  The device wakes up and tries to download the v2 from the firmware server but rejects it because it has expired.  Now the device is permanently vulnerable even though a "fix" is available.

** Section 4.2.5.  The reference for the mitigated by should be Section 4.3.6 (not 4.3.5).

** Section 4.2.7.  In the spirit of inclusive and more precise language, s/THREAT.NET.MITM/THREAT.NET.ONPATH/ (or some other way to say "on-path attacker" instead of "man-in-the-middle")  

Regards,
Roman