Draft: draft-ietf-suit-information-model

Commentary: Address review comments from :
Mailing list commentary: 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 do n'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 is n'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 do n'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 :
Paragraph (version A):
Vulnerabilities with Internet of Things (IoT) devices have raised the
need for a solid and secure firmware update mechanism that is also
suitable for constrained devices.  Ensuring that devices function and
remain secure over their service life requires such an update
mechanism to fix vulnerabilities, to update configuration settings,
as well as adding new functionality.
Paragraph (version B):
Vulnerabilities with Internet of Things (IoT) devices have raised the
need for a reliable and secure firmware update mechanism that is also
suitable for constrained devices.  Ensuring that devices function and
remain secure over their service life requires such an update
mechanism to fix vulnerabilities, to update configuration settings,
as well as adding new functionality.
Paragraph (version A):
This document treats devices with a homogeneous storage architecture
as devices with a heterogeneous storage architecture, but with a
single storage subsystem.
Paragraph (version B):
Secure time and secure clock refer to a set of requirements on time
sources.  For local time sources, this primarily means that the clock
must be monotonically increasing, including across power cycles,
firmware updates, etc.  For remote time sources, the provided time
must be guaranteed to be correct to within some predetermined bounds,
whenever the time source is accessible.
Paragraph (version B):
The term Envelope is used to describe an encoding that allows the
bundling of a manifest with related information elements that are not
directly contained within the manifest.
Paragraph (version B):
The term Payload is used to describe the data that is delivered to a
device during an update.  This is distinct from a "firmware image" as
described in I-D.ietf-suit-architecture because the payload is often
in an intermediate state, such as being encrypted, compressed and/or
encoded as a differential update.  The payload, taken in isolation,
is often not the final firmware image.
Paragraph (version A):
A monotonically increasing sequence number.  For convenience, the
monotonic sequence number MAY be a UTC timestamp.  This allows global
synchronisation of sequence numbers without any additional
management.  This number MUST be easily accessible so that code
choosing one out of several manifests can choose which is the latest.
Paragraph (version B):
A monotonically increasing sequence number.  For convenience, the
monotonic sequence number MAY be a UTC timestamp.  This allows global
synchronisation of sequence numbers without any additional
management.  This number MUST be possible to extract with a simple,
minimal parser so that code choosing one out of several manifests can
choose which is the latest without fully parsing a complex structure.
Paragraph (version A):
If Class ID is not implemented, then each logical device class MUST
use a unique trust anchor for authorisation.
Paragraph (version B):
If Class ID is not implemented, then each logical device class MUST
use a unique trust anchor for authorization.
Paragraph (version A):
When a precursor image is required by the payload format, a precursor
image digest condition MUST be present in the conditions list.  The
precursor image may be installed or stored as a candidate.
Paragraph (version A):
Enables feature: differential updates.
Paragraph (version B):
When a precursor image is required by the payload format (for
example, differential updates), a precursor image digest condition
MUST be present.  The precursor image MAY be installed or stored as a
candidate.
Paragraph (version A):
This element is OPTIONAL.
Paragraph (version A):
This element tells a device the time at which the manifest expires
and should no longer be used.  This is only usable in conjunction
with a secure source of time.
Paragraph (version A):
This element is OPTIONAL and may enable user stories where a secure
source of time is provided and firmware is intended to expire
predictably.
Paragraph (version B):
This element tells a device the time at which the manifest expires
and should no longer be used.  This element SHOULD be used where a
secure source of time is provided and firmware is intended to expire
predictably.  This element may also be displayed (e.g. via an app)
for user confirmation since users typically have a reliable knowledge
of the date.
Paragraph (version A):
A representation of the Processing Steps required to decode a
payload.  The representation MUST describe which algorithm(s) is used
and any additional parameters required by the algorithm(s).  The
representation MAY group Processing Steps together in predefined
combinations.
Paragraph (version B):
A representation of the Processing Steps required to decode a
payload, in particular those that are compressed, packed, or
encrypted.  The representation MUST describe which algorithm(s) is
used and any additional parameters required by the algorithm(s).  The
representation MAY group Processing Steps together in predefined
combinations.
Paragraph (version A):
In a heterogeneous storage architecture, a storage identifier is
insufficient to identify where and how to store a payload.  To
resolve this, a component identifier indicates which part of the
storage architecture is targeted by the payload.  In a homogeneous
storage architecture, this element is unnecessary.
Paragraph (version A):
This element is OPTIONAL and only necessary in heterogeneous storage
architecture devices.
Paragraph (version B):
In a device with more than one storage subsystem, a storage
identifier is insufficient to identify where and how to store a
payload.  To resolve this, a component identifier indicates which
part of the storage architecture is targeted by the payload.
Paragraph (version B):
This element is OPTIONAL and only necessary in devices with multiple
storage subsystems.
Paragraph (version A):
This is not strictly a manifest element.  Instead, the manifest is
wrapped by a standardised authentication container.  The
authentication container MUST support multiple signers and multiple
signature algorithms.
Paragraph (version B):
The Signature element MUST contain all the information necessary to
cryptographically verify the contents of the manifest against a root
of trust.  Because the Signature element authenticates the manifest,
it cannot be contained within the manifest.  Instead, the manifest is
either contained within the signature element, or the signature
element is a member of the Manifest Envelope and bundled with the
manifest.
Paragraph (version B):
This element MAY be provided either by the manifest envelope
serialization or by another serialization of authentication objects,
such as a COSE (RFC8152) or CMS (RFC5652) signature object.  The
Signature element MUST support multiple actors and multiple
authentication methods.  It is NOT REQUIRED for a serialization to
authenticate multiple manifests with a single Signature element.
Paragraph (version A):
A manifest MUST NOT be considered authenticated by channel security
even if it contains only channel information (such as URIs).  If the
authenticated remote or channel were compromised, the threat actor
could induce recipients to query traffic over any accessible network.
Lightweight authentication with pre-existing relationships SHOULD be
done with MAC.
Paragraph (version B):
A manifest MUST NOT be considered authenticated by channel security
even if it contains only channel information (such as URIs).  If the
authenticated remote or channel were compromised, the threat actor
could induce recipients to execute queries over any accessible
network.  Where public key operations require too many resources, the
recommended authentication mechanism is MAC with a per-device pre-
shared key.
Paragraph (version A):
Instructions that the device should execute when processing the
manifest.  This information is distinct from the information
necessary to process a payload.  Additional installation instructions
include information such as update timing (for example, install only
on Sunday, at 0200), procedural considerations (for example, shut
down the equipment under control before executing the update), pre-
and post-installation steps (for example, run a script).
Paragraph (version B):
Instructions that the device should execute when processing the
manifest.  This information is distinct from the information
necessary to process a payload.  Additional installation instructions
include information such as update timing (for example, install only
on Sunday, at 0200), procedural considerations (for example, shut
down the equipment under control before executing the update), pre-
and post-installation steps (for example, run a script).  Other
installation instructions could include requesting user confirmation
before installing.
Paragraph (version A):
Load-time metadata provides the device with information that it needs
in order to load one or more images.  This is effectively a copy
operation from the permanent storage location of an image into the
active use location of that image.  The metadata contains the source
and destination of the image as well as any operations that are
performed on the image.
Paragraph (version B):
Typically, loading is done by copying an image from its permanent
storage location into its active use location.  The metadata allows
operations such as decryption, decompression, and unpacking to be
performed during that copy.
Paragraph (version A):
The Payload element provides a recipient device with the whole
payload, contained within the manifest superstructure.  This enables
the manifest and payload to be delivered simultaneously.
Paragraph (version A):
The Key Claims element is not authenticated by the manifest-element-
signature, instead, it provides a chain of key delegations (or
references to them) for the device to follow in order to verify the
key that authenticated the manifest using a trusted key.
Paragraph (version B):
The Payload element is contained within the manifest or manifest
envelope.  This enables the manifest and payload to be delivered
simultaneously.  Typically this is used for delivering small payloads
such as cryptographic keys, or configuration data.
Paragraph (version B):
The manifest-element-signature is NOT REQUIRED to cover the
delegation chain.  The delegation chain offers enhanced authorization
functionality via authorization tokens.  Each token itself is
protected and does not require another layer of protection and
because the delegation chain is needed to verify the signature, it
must be placed in the Manifest Envelope, rather than the Manifest.
Paragraph (version B):
The exact mitigation for this threat depends on where the threat
comes from.  This requires careful consideration by the implementor.
If the threat is from a network actor, including an on-path attacker,
or an intruder into a management system, then a user confirmation can
mitigate this attack, simply by displaying an expiration date and
requesting confirmation.  On the other hand, if the user is the
attacker, then an online confirmation system (for example a trusted
timestamp server) can be used as a mitigation system.
Paragraph (version B):
Mitigated by: req-sec-exp, req-use-mfst-pre-check,
Paragraph (version A):
An authorised actor, but not the Author, uses an override mechanism
(user-story-override) to change an information element in a manifest
signed by the Author.  For example, if the authorised actor overrides
the digest and URI of the payload, the actor can replace the entire
payload with a payload of their choice.
Paragraph (version B):
An authorized actor, but not the Author, uses an override mechanism
(user-story-override) to change an information element in a manifest
signed by the Author.  For example, if the authorized actor overrides
the digest and URI of the payload, the actor can replace the entire
payload with a payload of their choice.
Paragraph (version B):
For example: Information about an installation-time confirmation
system that must be used to allow the installation to proceed.
Paragraph (version A):
It MUST be possible to authenticate a manifest multiple times so that
authorisations from multiple parties with different permissions can
be required in order to authorise installation of a manifest.
Paragraph (version B):
It MUST be possible to authenticate a manifest multiple times so that
authorizations from multiple parties with different permissions can
be required in order to authorize installation of a manifest.