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