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] To unsubscribe send an email to [email protected]
