Hi Laurence, I believe we are optimizing the wrong part of the spec. We should not optimize a security feature that is not that complex in the first place.
Protocol designers in the IETF require diverse expertise, including cryptographers. This is one of the examples. Luckily, we can reach out to those experts. We do the heavy lifting so that others, particularly application protocol designers, don’t have to do it. The attack shown in LAMPS demonstrate that we exactly have to involve cryptographers with things where everything looks pretty simple. Appendix B of NIST SP 800-56A points out what the problems are with the lack of context information. We have several examples where this is a problem. Bad random number generation is another problem, which is unrelated but also important. Ciao Hannes PS: I am not sure what you are referring to with COSE -29. From: lgl island-resort.com <[email protected]> Sent: Monday, June 17, 2024 8:05 PM To: Tschofenig, Hannes (T CST SEA-DE) <[email protected]> Cc: cose <[email protected]> Subject: Re: [COSE] Context Information Structure and COSE-HPKE Hi Hannes, 1) Data structure design I’d like to provide something that is much simpler than the info struct that can do everything it can if needed. I think the way to do this is by allowing COSE headers to get in the mix rather than the bunch of awkward fixed fields in the info struct that are NULL most of the time. 2) Security I think it’s terrible to require every protocol designer hire a cryptographer. That is onerous and not normal for an IETF protocol. You don’t need to hire a cryptographer to know if pure HPKE is safe, right? At least there’s nothing like this mentioned in the HPKE doc. It doesn’t need all the stuff from the info struct. We didn’t publish CMS or TLS this way either. Despite having info struct, COSE -29 and multi-recipient COSE-HPKE weren’t safe from the lamps attack. Info struct is no magic bullet, not even with every field filled in. I’d like to proceed with the better recipient structure and our best recommendation for security, more or less what we came up with in San Francisco. It will be much better than already-published CMS and COSE. Better because we’ve done more thinking and because we’ve made fixes. We will also provide all the facilities that info struct provides (in a different form) so we’ll not be going backwards. I’m not a cryptographer either, but I’m pretty confident by the circumstantial evidence, by my own thinking and by the discussions we’ve had. The circumstantial evidence is that we haven’t turned out any literature or on-line discussion discussing how to use info struct. It’s been published many years. JOSE has used it. The explanation for much of the text in NIST SP 800-56A Appendix B is re-use of keys and bad RNGs. Paul is of course going to say what he said by default. I think the question I’d ask him is this: “what’s the worst attack assuming a good RNG and no key re-use”. Did he know about the lamps attack? I also find it interesting that no one is excited about the fact that COSE -29 is a published IETF standard with a known vulnerability. There’s no effort to fix it. There’s no notification posted. It’s not in any vulnerability database. I want to fix COSE -29 with the same fix I’m proposing here for COSE-HPKE<https://github.com/cose-wg/HPKE/pull/58/files>. LL On Jun 17, 2024, at 7:27 AM, Tschofenig, Hannes <[email protected]<mailto:[email protected]>> wrote: Hi all, one of the big discussion points in the COSE-HPKE draft was the context information structure. Lot of opinions have been shared on the mailing list and I would like to provide my perspective about this topic. Although I have been working on security protocol design for many years I do not qualify as a cryptographer. For this reason, I have reached out to Paul van Oorschot, seeVan Oorschot: Carleton University<https://people.scs.carleton.ca/~paulv/>, to get his perspective on this topic. Paul worked with Diffie and Wiener on the analysis of key exchange protocols and on the attacks relevant to this discussion (reflection, and relay/splicing attacks). The guidance found in the academic papers has much later been incorporated into NIST SP 800-56A (see Appendix B) demanding key exchange protocols to include identifiers and other context-specific information in key derivation functions. These recommendations have been followed up by standardization work in, for example, COSE (see Section 5.2 of RFC 9053). In the work on COSE-HPKE we thought it would be "too complex" to follow these recommendations and discussed alternatives. In my chat with Paul, he recommended to follow the advice unless we can demonstrate that our design is not vulnerable to the attacks available in the literature. He acknowledges that those attacks (such as the unknown key share attack) are advanced, but they are not completely unrealistic either. Since we are developing a generic building block, it will be difficult to demonstrate that our designs will be free of problems when COSE-HPKE is used in some application protocol scenario. We would essentially be pushing the problem of figuring out whether a design is safe to use to application protocol designers. For this reason, I would like to re-use the RFC 9053 defined context information structure and populate the structures with the relevant values, which also includes the identities of the communication parties. Of course, we do not know the structure of the identities used at the application layer since COSE-HPKE is a building block that needs to be instantiated by a given application (such as firmware updates or a messaging protocol) but we can demand protocol designers to plug their identities into the respective fields. For test vectors, potentially be included in the appendix of the draft, we would use dummy values, such as [email protected]<mailto:[email protected]> and [email protected]<mailto:[email protected]>. I would like to know what you think about this suggestion for moving forward. Hence, I would like to walk away from our self-designed structures. If you agree, I am happy to create a PR. Ciao Hannes _______________________________________________ COSE mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
