Subject: [Suit] Manifest and architecture drafts updated

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 29 Jan 2018 15:02:32 +0000

Hi all,

we just submitted updates to the manifest and the architecture documents. Here are the two drafts:
https://tools.ietf.org/html/draft-moran-suit-manifest-01
https://tools.ietf.org/html/draft-moran-suit-architecture-01

The architecture document got enhanced to now include a threat analysis, security requirements, user stories, etc. This additional text has been motivated by mailing list discussions late last year. The text explains the presence of attributes in the manifest and the security mechanisms needed to protect them.

Here is the diff:
https://www.ietf.org/rfcdiff?url2=draft-moran-suit-architecture-01

The manifest document has only seen editorial updates, see https://www.ietf.org/rfcdiff?url2=draft-moran-suit-manifest-01

Thanks for the feedback so far.

Ciao
Hannes & Brendan
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.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 31 Jan 2018 16:26:39 -0500

> documents. Here are the two drafts:

Wonderful!

===

Minor quip about suit architecture 3.2, it took me a half a minute to figure
out the difference:

   For an update to be broadcast friendly, it cannot rely on (link layer),
   (network layer), or (transport layer security).

was really:

   For an update to be broadcast friendly, it cannot rely on (link layer,
   network layer, or transport layer) security.

because I couldn't figure out why we couldn't use link layer networking :-(
(The oxford comma neither helped nor hindered).  Mayube it should say:

   For an update to be broadcast friendly, it cannot rely on link layer
   security (e.g: WEP, 802.1x, 802.15.9), network layer security (e.g. IPsec), or
   transport layer security (e.g DTLS, TLS) to provide integrity of the
   information.

===
re: Minimal bootloader section.

Perhaps we should change:
   Note: This is an implementation requirement.
to:
   While the bootloader requirements are an implementation requirement, the
   manifest MUST provide an indication as to what bootloader capabilities
   are required to interpret/validate the image.

===
This brings up the question about knowing what versions are running on what
nodes!  I feel that this is unfortunately out of scope.  It seems like it
out go on a post-it note somewhere for the "recharter-once-we-are-done" list.

===
should 3.8.1 say:
s/Three actors are trusted identified by their public keys./
  Three trusted actors are identified by their public keys./

5. Q:
   -  Is the update older than the active firmware?

are we going to standardize the versioning of the firmware such that third
parties can reason about the ordering of the firmware?  Or is this strictly
between the manufacturer and the device?

11.2.1: Old Firmware.

I think that in the architecture we need some kind of concept of "trial"
upgrade, such new firmware can tried but not yet committed to, from a
point of view of roll back prevention.
This is related in some way to 11.2.10 (Unqualified firmware), as the
operator has to be able to load new firmware in order to qualify it...

11.3.1 (Monotonic Sequence Numbers), seems to provide the mechanism to deal
with this, provided that the operator is in control of the sequences, rather
than the firmware creator.  Should 11.2.1/11.2.10 have a forward pointer?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-