On Mon, Jun 17, 2024 at 02:27:25PM +0000, Tschofenig, Hannes wrote: > > > 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).
>From NIST SP 800-56A Appendix B: "The inclusion of sufficiently-specific identifiers for party U and party V provides assurance that the keying material derived by those parties will be different from the keying material that is derived by other parties (or by the same parties acting in opposite roles)." This is guaranteed by HPKE. Then the text proceeds to imply that this gives resilience to UKS attacks. The text also discusses including additional context-specific information. Most of the examples are already included by HPKE. One of the exceptions is protocol used. Would be easy to fix, if not for the info/aad restrictions. > 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 any application protocol, either: 1) Guarantees of HPKE are sufficient. 2) The application itself must take action for safety. There is nothing COSE-HPKE can do about that. > 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]>. The problems with this have been brought up before: - The definition of SuppPubInfo.keyDataLength is self-contradictory if used with HPKE. - Using identities safely requires explicit application support. - HPKE restrictions on using info (length and combining info and aad). - HPKE info is much slower than HPKE aad to process. -Ilari _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
