Subject: [Suit] I-D Action: draft-ietf-suit-architecture-00.txt

From: [email-masked]
Date: Sun, 03 Jun 2018 20:39:44 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Software Updates for Internet of Things WG of the IETF.

        Title           : A Firmware Update Architecture for Internet of Things Devices
        Authors         : Brendan Moran
                          Milosch Meriac
                          Hannes Tschofenig
	Filename        : draft-ietf-suit-architecture-00.txt
	Pages           : 18
	Date            : 2018-06-03

Abstract:
   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.  Incorporating such update
   mechanism to fix vulnerabilities, to update configuration settings as
   well as adding new functionality is recommended by security experts.

   This document lists requirements and describes an architecture for a
   firmware update mechanism suitable for IoT devices.  The architecture
   is agnostic to the transport of the firmware images and associated
   meta-data.

   This version of the document assumes asymmetric cryptography and a
   public key infrastructure.  Future versions may also describe a
   symmetric key approach for very constrained devices.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-suit-architecture/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-suit-architecture-00
https://datatracker.ietf.org/doc/html/draft-ietf-suit-architecture-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 5 Jun 2018 11:31:36 +0200

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).

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.

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”.)

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.

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

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 6 Jun 2018 09:49:00 +0000

Hi Carsten,

 A few remarks below:

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

Summary: needs work.

[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.

[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.

[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?

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

Grüße, Carsten

Ciao
Hannes

_______________________________________________
Suit mailing list
[email-masked]
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.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 6 Jun 2018 11:59:16 +0200

> [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.

That is not the right direction of fixing this.  

The point is to actually define what precisely is being claimed, without resorting to diffuse context-dependent language.  
Once you do this, the security improves immensely, because the signed item can no longer be misused in a different context.

Grüße, Carsten