Here’s a response that takes a different tack. HPKE (not COSE-HPKE) is OK without a context info structure, right? It doesn’t reference SP800 and we’re not worried about it, right?
I think the security of HPKE was better thought through than COSE -29. I believe there were some security proofs made about it. When I asked Steve Farrell why HPKE had all the complexity it had, one of the reasons he gave was to facilitate the security proofs. I think this establishes that you can do a DH-KEM securely without an SP800 info structure. I think cryptographer Paul would probably be OK with HPKE. Now bring HPKE back to COSE and HPKE’s lack of multiple recipient support. We have to add a bit more around HPKE to get support for multiple recipients. We have to worry about the lamps attack. Does that justify bringing in the info structure? I don’t think so. We just need to securely bind in the next layer algorithm. That is neatly accomplished with next_layer_alg in proposed recipient_structure.<https://github.com/cose-wg/HPKE/pull/58/files> I’ve argued for the info structure in the past. A couple of reasons I’ve changed a bit on this: - We’ve had a lot more back and forth discussion and turned up nothing - The proposed recipient_structure can bring all the stuff in the info structure via COSE headers if we discover the need for some of it in the future, or a use case needs it. I hope to do a bit more thinking and writing on this, possibly defining some COSE headers for some of the items in the info structure. Take into account what illari has said and such… Also a first draft of the COSE -29 replacement (it will have a different algorithm ID). LL On Jun 17, 2024, at 7:27 AM, Tschofenig, Hannes <[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, see Van 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]
