Minutes IETF118: suit: Tue 16:00
minutes-118-suit-202311071600-00
Meeting Minutes | Software Updates for Internet of Things (suit) WG | |
---|---|---|
Date and time | 2023-11-07 16:00 | |
Title | Minutes IETF118: suit: Tue 16:00 | |
State | Active | |
Other versions | markdown | |
Last updated | 2023-11-09 |
Agenda for SUIT Working Group at IETF 118
1) Logistics
- Agenda Bashing
- Minute Taker
- Jabber Scribe
- Bluesheets
2) Hackathon Summary
- Share things that were learned
3) SUIT Manifest Format
- draft-ietf-suit-manifest-24
- Submitted to IESG for Publication
- Revised I-D Needed to address AD Review
- TEEP depends on this
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
- draft-ietf-suit-trust-domains-05
- WGLC completed; revised I-D needed
- TEEP depends on this
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
- draft-ietf-suit-update-management-04
- WGLC completed 2023-08-14; issue raised
- More feedback needed
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
- draft-ietf-suit-firmware-encryption-18
- Depends on draft-ietf-cose-aes-ctr-and-cbc (with RFC Editor)
- Depends on draft-isobe-cose-key-thumbprint
- WGLC completed 2023-09-11; revised I-D needed
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:
- position independent code (truly independent). It is possible to
produce the code, but it is not done (complexity?). - You can skip the section if you do not support it - where is the
home for the section? Appendix?- Maybe informative (if you apply this pattern, this is applicable
to you... )
- Maybe informative (if you apply this pattern, this is applicable
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
- There have been advances for on-the-fly decryption. If you have such
hardware use it, however there might be some caveats in applying the
key exchange mechanism if it does not align with the hardware you
are using.
Beyond this, we are in a good state for the 2 documents this one depends
on.
Timeframe is beginning of next month.
7) Secure Reporting of Update Status
- draft-ietf-suit-report-07
- Discuss open issues; ready for WG Last Call?
- TEEP depends on this
There is one open question that is problematic (error codes). The CBOR
group thinks ERROR codes are not for interops, they are for
implementation.
If they are not for implementation/debug, we might have a problem.
- CBOR, COSE do not seem to want to take on error codes
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
level
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
section?
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
- draft-ietf-suit-mud-06
- Depends on draft-isobe-cose-key-thumbprint
- In IETF Last Call (ends 2023-11-14); waiting for dependency to catch
up
No comments, waiting for the last call to be over.
9) Mandatory-to-Implement Algorithms for SUIT Manifests
- draft-ietf-suit-mti-03
- Depends on draft-ietf-suit-firmware-encryption
- Depends on draft-ietf-cose-aes-ctr-and-cbc (with RFC Editor)
- WGLC completed 2023-09-19; more review needed
- TEEP depends on this
We do not have a PQC profile - not needed until a KEM/KEX and SIGS are
standardized.
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)
Jabber: xmpp:suit@jabber.ietf.org?join
MeetEcho: https://www.meetecho.com/ietf118/suit
Etherpad: https://notes.ietf.org/notes-ietf-118-suit#
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
progress
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
profile
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
Actions:
- Minimal error codes
- recommendation to encrypt
- profile definition
Brendon attempting to get to an update for suit report this week
Chairs Will start last call when this update gets published
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