Minutes IETF106: suit
minutes-106-suit-02

SUIT Working Group at IETF 106 in Singapore

Agenda
------
1) Agenda bashing, Logistics
2) Developers Gatherings
   - Hackathon Report
   - Workshop in January
3) SUIT Architecture
   - draft-ietf-suit-architecture
4) SUIT Information Model
   - draft-ietf-suit-information-model
5) SUIT Manifest Format
   - draft-ietf-suit-manifest
6) Next Steps

Jabber: xmpp:suit@jabber.ietf.org?join
MeetEcho: https://www.meetecho.com/ietf106/suit
Etherpad: https://etherpad.tools.ietf.org/p/notes-ietf-106-suit

Notetakers: Carrick Bartle, Stuart Cheshire

Notes:

1) Agenda bashing, Logistics

Status: 2 drafts in last call, 1 in progress
Milestones: on track
Plan is to submit drafts this month, manifest in March

---

2) Developers Gatherings
   - Hackathon Report
   - Workshop in February (was January)

There was no SUIT work at the IETF 106 hackathon this time
Hannes Tschofenig (ARM) presented information about the upcoming “Securing the
IoT” Hackathon in Berlin, 17-19 February 2020 Would like to have a tutorial on
the first day Work will be done relating to:
    Software Updates for Internet of Things (SUIT)
    Trusted Execution Environment Provisioning (TEEP)
    Remote ATtestation ProcedureS (RATS)
Hackathon is free but need registration info to get a count since there may be
some hardware provided for some things See https://siot-hackathon.github.io/

---

3) SUIT Architecture
https://datatracker.ietf.org/doc/draft-ietf-suit-architecture/

Hannes Tschofenig (ARM) presented a status update on draft-07
Previous version had added extra more text on bootloaders, and added TEEP info
Kathleen Moriarty then posted a review that led to version 7

Hannes discussed the state of the art in security mechanisms (confidentiality,
hash-based sigs). Devices with long lifetimes are at a disadvantage when
classical security mechanisms in unchangeable code in a device no longer work

Dave Thaler: section 3.3 says a mandatory-to-implement set of algorithms "has
to be defined"...  Should it say "is defined in the SUIT manifest"?

Brendan Moran: A set is not currently defined in SUIT manifest, but can't see
anywhere that would be a better place to define it.

ACTION: Brendan to define in the SUIT manifest, and the arch doc should point
to the SUIT manifest document for the set

David Waltermire, NIST: Have you considered requiring 128-bit keys here? 
That's the NIST recommendation for lifetimes > 10 years.

Kathleen Moriarty: draft should mention applicability to higher-end use cases
as well (e.g. those that use classical Linux), not just for lower-end devices

Brendan Moran: right, not prevented from being used by anything else.  I have
heard talk about using this to update Linux and even Windows

Dave Waltermire: SUIT charter also doesn't prevent use for higher-end

Dave Thaler: just specify in architecture doc that it can be used in anything;
it's already in the manifest

Michael Richardson: we've discussed this already, during chartering, we just
have to beat people over the head about this? Updating is totally in scope.
It's a perception issue; trying to address it

Michael Richardson: do we need more examples? Things that SUIT may not seem
appropriate for?

ACTION: Hannes will provide a -08 draft soon after the meeting addressing
examples of update use cases that illustrate use of SUIT in more capable
devices. The chairs will submit this revised draft to the IESG.

---

4) SUIT Information Model
https://datatracker.ietf.org/doc/draft-ietf-suit-information-model/

Brendan Moran, ARM, presented a status update on the Working Group Last Call
Extensive comments from Dave Thaler lead to draft-04.

Emmanuel Baccelli, Inria: We need to be mindful of RAM requirements

Brendan Moran, ARM: This is specifically for integrated (and therefore small)
payloads, e.g. encrypted key, not payload of update

David Thaler, Microsoft: Who is expected to know what payload size will fit in
RAM for any particular device?  Is the manifest author supposed to know it?

Brendan Moran, ARM: This is exactly why I want feedback on this.  Either enough
to fit a wrapped key or up to implementer (Brendan doesn't like latter, but
picking a number out of the air might break things.)

Dave Waltemire: There might not be pre-knowledge of the size

Brendan Moran: Will look at capability reporting, get info from device at time
of manifest creation

Hannes Tschofenig, ARM: The TEEP WG talked about a capability mechanism.  The
manifest has to fit in RAM so you can verify the signature.  The manifest will
generally be very small, so typically not an issue but could get larger, e.g.
if need to include key.

David Thaler, Microsoft: We could define (similar to IPv6 reassembly) a
mandatory minimum size that devices must support; devices are allowed to
support larger if desired.

Brendan Moran: need more time to think about it. I like Dave's suggestion,
except we could end up with devices that use min instead of what they need.

Hannes Tschofenig, ARM, will consider the options and make a recommendation on
the list by the end of this week.

Mohit: can you define max based on large key size?  At least document these
considerations and not give min/max, and implementers would have to do their
own testing.

ACTION: With regards to size of the integrated payload, the draft will not
specify a specific size, but will provide some considerations relative to
possible sizes. Brendan will work on language to post to the list in the next
couple days. The WG will have 2 weeks to provide any final feedback on the
draft. After addressing feedback, the draft will be sent to the IESG.

---

5) SUIT Manifest Format
https://datatracker.ietf.org/doc/draft-ietf-suit-manifest/

Brendan Moran, ARM, presented a status update on SUIT Manifest.
Draft-moran-suit-manifest was previously adopted as a Working Group document.
Now draft-ietf-suit-manifest-02.
Interpreter behavior sections were added to help implementers, and make testing
easier. Required checks: e.g. validation of sigs, vendor ID, dependencies have
been executed Added text fields that had been missing, e.g. to UUID5 function,
json/yaml-source (input file can be incl. in text fields)

The name “SUIT Manifest” suggests this is only for constrained devices, and is
not amenable to discovery via Google searches.

Russ Housley, Vigil Security LLC, suggested changing the name to “Software
Update Manifest”

Dave Thaler: I like "Software Update Manifest"

ACTION: Change the name of the draft to "Software Update Manifest"

Example section is very big, what should we do with it?  Prune some info (JSON
representation), Move to appendix, or Move to another doc?

Dave Thaler: All three WG chairs say to do both of the first two (prune some,
and move to appendix)

Brendan Moran then presented the Map-Test-Execute proposal

Dave Waltermire: Why do you need temporary parameters?

Params won't be applied to system state until tests are done, but need to apply
parameters before tests since the tests work on the parameters. If the tests
succeed, then the temporary parameters become committed.

Dave Waltermire: was confused by the terminology

If using A/B offset, should be required
For single-image devices, not required
want feedback on Map-Test-Execute, especially for multi-component devices

David Waltermire, NIST: Would anyone in the room implement Map-Test-Execute?

No one spoke up.

Brendan Moran: This is essentially a compression scheme for compressing the
manifest itself.  My posting on the list showed what it would do in variety of
circumstances

Henk Birkholz: Many CBOR items still have text values in them.  We are
considering allowing LZ4 compression to a CBOR data item.  The combination of
CBOR and LZ4 also used for DNS benchmarking by ICANN and they liked it; reduced
data significantly.

Brendan Moran: We don't want LZ4, as it requires a 64k table-size

Dave Waltermire: We also have to keep in mind the size reduction vs.
computation cost tradeoff

Henk: Next question, SACM proposed using CWT structure instead of CoSWID CBOR
structure in front of manifest, to ease adoption of the data structure. CWT
parsers are everywhere. SUIT manifest currently has same structure as CoSWID
CBOR item.

Brendan Moran: pro-SUIT tag, prefer it to CWT

Henk Birkholz: will SUIT tag hinder adoption because it's not a CWT and it's
less common?

Brendan Moran: don't think so; this is a specific use-case. wouldn't matter to
me

Dave Waltermire: our charter is to make SUIT manifest format

Hannes: what happens if you take the CWT but not the mandatory fields in there?

Dave Waltermire: Out of time, need to continue discussion on the list

Brendan: We are adding text fields, but they only take the size of a digest to
populate

---

Dave Thaler presented Manifest Requirements from TEEP WG
Some of these requirements are supported already by SUIT

Brendan: having a URI that's not binary download URI is an easy add

Requirement: Need a way to specify "create me a security domain" as an
installation action in manifest

Brendan: already do-able; if need explicit, easy add

Requirement: Ability to update a file that isn’t a binary executable

Brendan: can already update non-executable binary

Henk: if manifest is lacking semantics, can be added by root code exception

Requirement: indicate which TEE a binary should be installed to

Brendan: that's the whole point of component ID, which is what you use there. 
Just need to confirm that this works

Suggestion: add use-case template for TEEP to the SUIT manifest draft along
with the other use case templates?

Brendan Moran: yes, would love to

---

Distributed SUIT Architecture Model - Seoyun Choi, Protocol Engineering Lab,
Sangmyung University
<https://datatracker.ietf.org/meeting/106/materials/slides-106-suit-blockchain-based-firmware-update>
Proposal to use Blockchain, to reduce load on servers, and handle the situation
where an author writes and signs some software and then disappears.

David Waltermire, NIST: Who is going to host the Private Blockchain platform? 
If the software author disappears, won’t the corresponding Private Blockchain
go away at the same time?

Seoyun: Also other articipants who want to be nodes in the blockchain

Brendan: Unclear on what happened after author disappeared. Why is server not
responding?

Seoyun: Because servers are managed by author

Brendan: SUIT was designed for untrusted content distribution networks. Is
blockchain an untrusted content distribution network?

Seoyun: Yes

Brendan: Ok, the existing architecture is already compatible with this

Michael Richardson: The blockchain can just be a URL like any other URL

Michael Richardson, Sandelman Software Works: I like the idea of firmware
images being stored independently of the author who wrote it.  If this is done
using blockchain, what are the incentives for people to do the computational
work to generate the blocks?   Some might have an incentive to do so for
servers that connect externally to get images, and internally to serve them to
private devices.

Stephen Banghart: This sort of thing has been done before, distrbuted files
over blockchain, currently in use for immutable files. Using it for SUIT is
cool, and I don't think we need to change SUIT to support it.

Hannes Tschofenig, ARM: If the author disappears, what happens to the author’s
private key, which is needed to sign future updates?  Being unable to get any
updates in future might be an issue.

Waltermire: Take further discussion to the list, we are out of time

---

END