Hi Ilari, -----Original Message----- From: [email protected] <[email protected]> Sent: Monday, June 17, 2024 7:49 PM To: cose <[email protected]> Subject: [COSE] Re: Context Information Structure and COSE-HPKE
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. [Hannes] HPKE allows the inclusion of context-specific information via the info parameter, and therefore application layer identities, such as party U and party V. By default, HPKE does not know about these identifiers since it is a building block. In COSE HPKE we also need to make it possible to pass this information into the building block. With the current design we make it impossible to incorporate this information. > 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. [Hannes] I disagree with you. > 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. [Hannes] I understand that there is a desire to make things faster but I fear we are degrading security. Ciao Hannes -Ilari _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected] _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
