Dave Thaler provided a working group overview. There is only a single item remaining in the charter, the manifest format, which is nearing completion. As a result, a rechartering discussion was held at the end of the meeting to review proposed charter text.
Hannes Tschofenig provided an update on hackathon activities before IETF 111.
Overall holding hackathons in a remote format has been working well. It's worth participating given that many new ideas and improvements to SUIT and TEEP drafts have resulted.
Brendan Moran presented slides on the topic of the SUIT manifest format.
(Slide 3) There was some discussion around use of URIs or URI References. Use of URI References require resolving the reference against a base URI (what the reference was relative to). It was proposed (by Brendan Moran) that this behavior be implementation-defined, since there are many cases where the base is known by the implementation. Michael Richardson and others indicated that relative references must work in a deterministic way (at least to some degree), since they are used to refer to other dependencies. This includes air-gapped environments.
Brendan suggested that if your MUD files are associated with your manifest and network infrastructure knows that, then infrastructure could be aware of this context supporting URI resolution.
Christian Amsüss suggested that there is value in providing an explicit base. This could be provided in the Critical Metadata and can then be used in the Integrity Check Values) and any other place where there is a need to resolve a relative URI. This would be better than a try-this-and-then-try-that approach.
Brendan suggested that it might be best to work with what we know and then work down from there. This might work with some careful wording.
Brendan asked for time to think more about this and to propose new text. Henk Birkholz suggested some examples would be beneficial to illustrate some of the edge cases.
(Slide 4) Brendan asked if a list of URIs should be supported in the core specification that would allow a device to find future manifests. Dave Thaler suggested that this might be better addressed in a future extension. No concerns were raised about deferring this to an extension.
(Slide 5) Brendan asked if we should support computing a digest of an integrated payload. This could be addressed using a new condition, since integers are cheap and size is not an issue in these manifests. Russ Housley suggested that it isn't exactly cheap, since code must be prepared to handle (or ignore) it.
He asked what component ID should be used for an integrated payload verification. He is leaning towards treating this the "same as installation ID", where it might be copied to if it is copied at all. This might also be a candidate for extension.
Brendan suggested the decision on if this should be addressed in the core or in an extension is tied to use of integrated payloads. If they are not used extensively, it might not make sense to include this in the core. Russ suggested that this question is important to answer before making a decision.
Michael suggested if the payload is part of the manifest, then verifying the manifest might be enough.
ACTION: Brendan will propose text on the list, where a decision can be made based on input.
(Slide 6) Currently, integrated payload references require a string->int conversion. Use of strings increase the manifest size.
(Slide 7) A shorter URI reference can be used with strings. Benefit of strings is avoiding collision with future extensions and the need for string->int conversion. Brendan would like to change this in the draft.
(Slide 9) Michael asked if there is a Github issue for this. There doesn't yet appear to be one. He also suggested that mixing string and integer keys is possible in CBOR. Error handling would need to cover when the string->integer fails, or when someone decides to use hex numbers, etc.
Christian Amsüss supported use of strings.
ACTION: Brendan will propose text on the list, where a decision can be made based on input.
(Slide 10) Brendan asked if we should define MTI signature algorithm(s)?
Brendan suggested to use HSS-LMS as the MTI algorithm. Russ Housley was the original advocate of these algorithms.
The discussion focused on the following points.
Brendan reiterated the problem with constrained devices is that it may not be possible to add multiple algorithms; he likes the hash-based signature approach if he had to choose one. This may cause fragmentation or noncompliant implementations. If we want to do this, we have to provide measurements on the required code size, and demonstrate it's worthwhile. A really small implementation would help settle the issue. It would be good if someone in this group could produce really small HSS-LMS implementations.
Russ added that we should see what the code size is for elliptic curve vs. HSS-LMS. This means the question is Merkle tree vs. elliptic curve. He has an open-sourced Python implementation of HSS-LMS. Based on this implementation, the vast bulk of code is on signer side; the code for a validator is straightforward and simple.
Brendan questioned if the validator is small enough.
Michael suggested we should make HSS-LMS be the MTI for any device with an expected lifetime of more than about 2 years. (Where smartphones fit into "2 years" is a marketing problem.)
Roman Danyliw (as AD) suggested that this is a big decision for us. The WG shouldn't make this on assumptions. Real numbers are needed to allow us to talk through what the tradeoffs are. A bad decision can lock us in badly.
Brendan agreed that more research is needed. We need to collect feedback from implementers to determine whether this is a real stumbling bock. It won't be possible to make a decision today about the MTI crypto issue.
Roman Danyliw (as AD) agreed that we need implementers to help us understand the engineering envelope.
Michael suggested that the current thinking is around mcuboot. We're lacking sufficient implementations for the signing process with Merkel tree-based signatures, but not for the classical asymmetric signatures and trees of certificates. Unclear on the others how that's done on layer 8. Maybe some trial, maybe with NIST would help here?
Brendan said that NIST has only just declared winners, they only just became NIST approved. This is not about technology (that's old), but about lack of tooling. Tooling for hash-based signatures is just not quite at the same level as other approaches. Maybe the right answer is to make one of existing asymmetric algorithms MTI for now, and then issue a bis to deprecate and make HSS-LMS mandatory (even with warning now)? He is worried about limiting the audience that will adopt this.
Russ suggested calling it a MUST (on asymmetric) and a SHOULD (on hash-based), with a note that hash-based is coming.
Roman suggested the NIST NCCoE might entertain such an evaluation project.
Michael warned, and Alexey agreed, that supporting both is back to the code size argument. It's not likely that we'll ever get to hash-based as a MUST if we start with SHOULD. Pushback will be too great.
Alexey Melnikov suggested, and Hannes agreed, we should try a Hackathon with HSS-LMS and see how much push back we get?
Dave Thaler suggested that knowing the (size) number will help with limiting options, but will it change the implementation considerations?
Michael suggested that if we have HSS-LMS as MUST, then we likely never need to shift. That's where the win is. If we start it anywhere else, then the shift is very hard, and if we ever need to do it, it's likely to be too late. This is very much like a Climate Change or Y2K kind of decision.
Tadahiko Ito suggested he is interested in the operation of stateful hash algorithms.
The Chairs polled the room with the question "Do you prefer hash-based signature over elliptic curve?" 10 hands were raised, with 3 hands not raised. There seems to be consensus towards a preference for hash-based signatures.
The chairs asked, to verify, if those who prefer ECC, have any new technical input that has not yet been discussed?
Rich Salz suggested he has no strong feelings either way, just concerned about brand-new crypto in brand-new thing (the manifest). If the WG is good with a new approach, he's fine with being in the rough.
Russ highlighted that all of these algorithms are over 20 years old, just in case there is concern about patents.
Rich agreed. He's not concerned about security, just about any burden that's a barrier to acceptance.
Brendon suggested that we can reduce the burden by putting signature calculations (not hashes) into the SUIT parsing process. Then SUIT parser has to supply it, it's part of the package. Maybe that's an option?
Ira McDonald indicated that LMS has a bunch of fresh implementers due to NIST PQC competition and some very good analysis work.
(Slides 11-13) The manifest format's document structure is viewed as "too complex" from out-of-WG reviews, largely due to the document's size of 113 pages for draft -14. This is long for a simple concept. This may cause readers to think it's overly complicated.
Brendan suggested to reduce the page content by reducing the core spec to a smaller set of use cases. Additional use cases can be addressed in separate documents that are extensions to the base specification. During the discussion, it was also suggested that breaking extensions out may help with getting the base specification to WGLC earlier (i.e., compression, differential updates).
Brendan raised the concern that reducing the base too much may cause the reader of the base specification to think it does not cover their use case. Some functionality like including multiple firmware images is easy to support. Other functionality like handling dependencies is more complicated.
Hannes suggested that some aspects of the manifest specification start out looking straightforward, but after some engineering issues have been identified that complicate writing the draft (e.g., firmware encryption). This may also happen with other features (e.g., delegation chains). It might be worthwhile to split out some of these features, allowing more time to develop the use cases along with good examples.
Brendan supported this, indicating with encryption that key distribution was missed in early drafts and caught after some significant work on the feature.
Dave Thaler asked what a good rationale would be for splitting. A good rationale could help confirm that the split is the correct split. He proposed that we split on mandatory vs. optional. Everything that is optional can be put into a separate document. Dave also suggested that people employ a bad practice of defining compliance at the granularity of RFCs. If the base is just MTI, then there will be no harm in such a case.
Dave asked how close the proposals on slides 12 and 13 match his rationale. Brendan confirmed that he applied Dave's rationale in the proposals. Dave asked the working group if there were other features that they need supported in the base specification.
Is there working group support for this restructuring?
Michael Richardson supported the proposal. He agreed that the working group will find more issues in split-out features due to more review under less time pressure. He was concerned about the overall number of extensions this may cause. He suggested that the core might include informative references to some key extensions. This could help the reader understand that their use case is supported. Brendan suggested that he hadn't considered that, but will look for opportunities to do this.
Dave Thaler indicated that there have been no arguments raised against splitting. Given this, a split will allow the base document to go to WGLC as soon as possible. We need to deal with crypto MTI per the previous discussion.
He asked if there are other open questions on the base document. Brendan suggested that digests of integrated payload needs work, but that is reasonably straightforward and can be added to the base document.
Dave Thaler suggested that a WGLC can begin once the draft is updated based on the split.
Hannes presented slides on firmware encryption within SUIT manifests.
(Slide 2) Hannes indicated that work on the draft has been somewhat slow due to implementation trouble. He asked if the draft should cover maintaining image confidentiality once it's on the device. For example, if the image is swapped out to external flash, this can lead to compromise and make encrypted firmware moot. This should at least be covered in the security considerations.
David Brown suggested he had to deal with complexity in swap command (i.e., encrypted in upgrade slot, encryption when swapping back). There's some complexity that should be worked through, perhaps offline.
Hannes indicated that there is some operational guidance from mcuboot that makes users aware of potential pitfalls. On some more advanced hardware, it may be possible to decrypt before execute. He suggested that this could be described in the security considerations.
(Slide 3) For AES keywrap, reusing COSE and profiling it. For HPKE, this is not done. CFGRG has a very generic specification. Should this be described separately? Can be usable for others?
Brendan suggested that there's something in COSE that is similar to HPKE, that's ephemeral static with AES keywrap, which gets you most of the way.
Hannes indicated that this is what he did initially. The problem here, and in similar situations, is from a high-level, things look similar, but they're not the same. Half way there is still not there. HPKE is incompatible with what is in COSE spec.
Brendan asked what we gain for SUIT between HPKE and ECDH ephemeral static. Hannes responded that the benefit of HPKE (and why we picked it) was that HPKE seems to be the one people want to go forward with. It has formal analysis, test vectors, and code available. HPKE has become a popular building block in implementations. Thus, it makes sense to focus on HPKE.
ACTION: Hannes will post to the list about this issue to drive further discussion.
(Slide 4) Hannes identified a new challenge when going from signature to encryption: the Author may not know what all devices will be -- that's what the distribution system is for. The Author may not know the public keys of all devices. In the general case, this can't be expected. The recipient list must be mutable (because the author still protects manifest), so this needs to be addressed in the envelope. This decision has side effects.
(Slide 5) Brenden continued the discussion of a potential solution by identifying two threats.
Device Suppression: Unable to distinguish between a device being unauthorized by device distributor or an attack.
Energy and flash exhaustion threat
(Slides 6 thru 8) Brendan explained the solution of putting a digest of the CEK into the signed manifest. This allows the recipient to verify whether the correct CEK has been delivered.
Russ was not convinced by the argument. Brendan responded by describing the scenario of someone who has access the ephemeral PK plus an encrypted CEK. They could then use this information to encrypt random data with the CEK. The recipient would not detect this swap.
Russ suggested use of a certified public key of the recipient. Brendan responded that would work, but that forward secrecy would be given up.
Russ observed that using both a certified public key of the recipient and an ephemeral key for the recipient would preserve forward secrecy. Brendan responded that would work, but the cost would be twice the number of elliptic curve operations.
Michael Richardson asked if those that care about encryption of firmware have any concerns that a PQ event would allow all historical firmware contents to be revealed?
Agreement that further investigation is needed.
Dave Thaler led a discussion of charter text from the chair slides starting with slide 7. The goal of the discussion was to have new charter text ready to be sent to Roman.
(Slide 9) Brendan clarified that the security threats, use cases, and security requirements are provided in the information model.
ACTION: Russ agreed to update the text.
(Slide 11) There was discussion about whether capability discovery (reporting) and SUIT reports are protocols or formats. A manifest author needs to know what commands and parameters are supported by a given device.
ACTION: Russ agreed to update the text to include text about a manifest creator knowing what capabilities are supported by a given device. There is a need to support a format to support capability reporting. It's ok to delete "and protocols".
(Slide 12) Dave Thaler discussed the first paragraph, which talks about the claims discussed in the RATS meeting. Depending on the outcome of the discussion about where to work on the claims (RATS or SUIT), there may (or may not be) a document to work on in SUIT, just review needed.
Roman was not concerned about where the work will be done. The important aspect is to get the scope right to allow the work where appropriate.
A milestone for this can be added in the future if needed.
ACTION: Change "will specify" to "will work with the RATS WG to specify".
(Slide 13) deliverables
Brendan provided an initial list as follows:
The previous list may be affected by the base document splitting that was discuss earlier.
For the "Compression/Differential Update" we don't have enough information on how it needs to work yet.
Russ suggested we could say "Extension documents, such as ...". Dave voiced a concern that this may be a bit open-ended. Roman responded that we don't know yet how the split will work out and so we can refine it later. The important thing is to have the markers for this work in the charter. We can make figuring out the specifics a first-order milestone. Russ pointed out we discussing extensions to the SUIT manifest and not some random work.
Finally, Dave suggested clarifying the the set of claims will be worked on with RATS.
The remainder of topics were postponed due to time constraints.
---- postponed ---