Agenda for SUIT Working Group at IETF 118

1) Logistics

2) Hackathon Summary

3) SUIT Manifest Format

Two major updates following Roman review. Possibly leaving out signature
minimization and leave that to the implementer.
Internationalization is handled with an approach similar to CBOR's Tag
38 - single indicator for all languages.
IPR #3799 has been bandoned. v24 examples were incorrect - new samples
are available in GIT.

4) SUIT Manifest Extensions for Multiple Trust Domains

We have not seen a response to the question on the ML. We are looking
for feedback for the status of delegation chains.

Hannes: I provided some comments and I need to read it again. It had
some open issues back then. I volonteer to review it on the list.
Q: What is the Timeframe?
A: Saturday.

5) Update Management Extensions for SUIT Manifests

Relatively minor update, if there are no reviews we are ready.

Chair: There is an open comment still to be resolved about SHOULD vs.
MAY (needs reasoning/justification).

David Brown: I agree.

An update can/will be there as soon as tomorrow.

6) Firmware Encryption with SUIT Manifests

Lots of updates to the document. Wrote the implementation for ... AES

I am thinking about how to integrate MCR suggestion for better structure
the options for the deployment.
There were three issues bwyond editorial:

RUSS: I am fine if you put the section as Informative
Chair: Maybe this can be moved in the security consideration
Hannes: It might be too long - maybe I can do what Russ suggested

Beyond this, we are in a good state for the 2 documents this one depends
Timeframe is beginning of next month.

7) Secure Reporting of Update Status

There is one open question that is problematic (error codes). The CBOR
group thinks ERROR codes are not for interops, they are for
If they are not for implementation/debug, we might have a problem.

DAVE: in the hackathon we needed a way to commincate the profile back.
We cannot figure out what to do with this case (suits problem).
Brendan: We have a new version tht has that details ... there is a set
of slides flotating around. Disconnet Suit MTI and suit Report.
How do we identify the supported suit cose profiles by the processor?

RUSS: We need to be careful not to over-report. In TLS that has been
used by attackers. We should report errors at a different granularity
to avoid abuse. Let's do the debug thing and we are done.

Chair: We support encryption, as long as you use encryption we should
not care about that.

Brendan: Shall we add super ports considerations in the security
RUSS + Chair: Yes.

Brandon: There are three possible suits errors to report (unsupported
algorithm, cbor parse error and possible signature verification error).
There might be some others.
Chair: We can extend that in the registry.

Brandon: Advise to use encryption in the security considerations

Chair: The goal is to say TEEP that they do not need to do anything (?)

8) Strong Assertions of IoT Network Access Requirements

No comments, waiting for the last call to be over.

9) Mandatory-to-Implement Algorithms for SUIT Manifests

We do not have a PQC profile - not needed until a KEM/KEX and SIGS are

Q: Why the change to ChachaPoly
A: There are implementations that refuse to use AES128. ChaChaPoly is
normally coupled withg EDDSA and it is a viable alternative to AES.

No objection from the WG.

All standing comments have been addressed, we can claim that this one
has passed consensus.

RUSS will be the doc shepard.

10) Any Other Business (if time permits)


Brendan Moran comments on Internationalization
Change from v23 to v24 to handle internationalization of SUIT_Text,
and allows the manifest to contain text in multiple languages,
but this is a breaking change.

Brendan comments on IPR
Previously claimed IPR has been abandoned (no longer an issue)

Dave comments that the internationalized text is ONLY for human display

Brendan comments some of the v24 examples are incorrect; updates in

v25 update is fairly large; aiming for end of November

Open issue from virtual iterim -- trust delegation chains
Question posted to suit list -- no responses so far
Looking for feedback from the group on trust delegation chains
Hannes volunteers to read and provide feedback
Hannes says by Saturday

On to update management draft
Update published
Dave has filed an open issue with shoulds about semvar
Brendon acks
David Brown agrees with Dave Thaler
Brendon plans to update document tomorrow

Hannes is presenting on encrypted payloads (firmware encryption)
Lots of updates since last IETF
Documentation in good shape
AES CBC and CTR mode implemented and released in t_cose
Got a lot of feedback on the document
3 comments beyond editorial
1) position independent code
2) is section (on ... IoT devices with flash memory) normative or not,
perhaps move to appendix. Maybe as security consideration. Maybe preface
it, and reference it from the Security Considerations section.
3) Execute encrypted code in place with decryption on the fly; May need
a separate key exchange for HW that supports this

Hannes aiming for update by the end of the month

Moving on to suit report draft
v07 published incorporating feedback from previous reviews
One open issue relating to error codes, perhaps standard CBOR prase
error codes
Are error codes for interop or are for debug?
No problem if they are for debug, more of an issue if they are
Dave T describes scenario with unsupported profile
Dave T suggests (if I understood correctly) there should be some
mechanism for common error understanding
Brendon describes minor disconnect between MTI and suit report
How does we identify whether a manifest processor supports a particular
Brendon suggests if they support the algorithms for a profile then the
profile is considered to be supported
Some agreement in the room
Russ warns against too much information being reported so as to not
advantage an attacker
Dave T mentions encryption of suit report which denies the attacker
access to this information
Brendon asks whether there should be guidance that suit reports should
be encrypted
Dave T and Russ say YES
Dave W says it sounds like they are for both for interop and for debug
Brendon agrees
Suggestion to establish a registry for error codes
Possibly so that other documents can extend

Moving on to suit mud document
In last call
Few updates -- explanatory text
Ready to go when last ends

On to MTI
MTI is for receiving nodes
No PQC MTI at this point
Brendon thinks this is OK at this point
Brendon thinks current list is comprehensiv and reluctant to expand
Russ supports choices made
Dave T asks about change to add chacha-poly
Brendon says that some implementors relucant to use AES 128 and
chacha-poly is the best alternative
chacha-poly is often paired with eddsa
No objections to this
No open issues. THis has passed consensus.
Russ will continue as document shepard

Roman thanks Russ for previous work as chair
Roman also thank Dave T who will be no longer be chair
Roman looking for a replacement for Dave T to help Dave W

Meeting adjourned