Hey Hannes, Adding JOSE, since this topic needs to be addressed consistently by both working groups.
Thanks for coordinating on this. https://datatracker.ietf.org/doc/html/rfc9053#name-context-information-structu And in JOSE, in case it's helpful to consider: https://datatracker.ietf.org/doc/html/rfc7518#section-4.6.2 TLDR, there are header parameters that are registered for use in JOSE and COSE, that MUST be understood when present, and which are input into key establishment. In the context of HPKE, we can consider these parameters as input to: https://datatracker.ietf.org/doc/html/rfc9180#name-auxiliary-authenticated-app We've talked about a few ways to support them in COSE HPKE (and JOSE HPKE). Option 1: In info parameter to "LabeledExpand" - https://datatracker.ietf.org/doc/html/rfc9180#section-7.2.1 Option 2: In aad parameter to "Seal" and "Open" - https://datatracker.ietf.org/doc/html/rfc9180#section-5.2 We initially discarded Option1, because of the complexity of COSE_KDF_Context and the length restrictions, which limit the amount of information which can be mixed in at this layer. We've been trying to make progress on an "COSE_HPKE_Encrypt_Context" that pulls parameters from protected headers, and which MUST be used with option 2 (as aead aad, not kdf info). Ilari, Lawrence and others have all commented on this, but it seems worth repeating your views again here, I will share mine below: I prefer option 2. I don't believe Option 1 is needed, thanks to the construction of HPKE internals. I support creating a new COSE_HPKE_Encrypt_Context, and for it to be built from parameters pulled from protected headers, the protected headers themselves, or known to both sender and receiver. Because HPKE is "Hybrid Public Key Encryption" There is no concept of "just the key establishment part", like there is with ECDH-ES (which is just a key establishment algorithm). Therefore there is no concept of "just the key establishment part of HPKE", and there will always be aad. See: https://datatracker.ietf.org/doc/html/rfc9180#section-5 """ All the algorithms also take an info parameter that can be used to influence the generation of keys (e.g., to fold in identity information) and an aad parameter that provides additional authenticated data to the AEAD algorithm in use. """ It sounds to me like what Paul is saying applies to RFC9180, more than drafts that build on it. Specifically https://datatracker.ietf.org/doc/html/rfc9180#section-4-2.2.2.2 Sounds like he is saying info should be mandatory, and that COSE and JOSE should treat it as mandatory, even though RFC9180 says it is optional. I'm not a cryptographer. I am assuming HPKE is safe and suitable to be used as specified in RFC9180. If Paul / others disagree, I think that conversation might be more productive in CFRG, where RFC9180 originates. Regardless of my view, a decision will need to be made for either document to progress. If JOSE and COSE WGs both decide to treat "kdf info" as mandatory, both will need to define a single deterministic algorithm for producing a fixed length input, from variable length header parameters, and this transformation will need to be specified and marked as mandatory for each HPKE algorithm identifier. This would mirror the current behavior for JOSE, see https://datatracker.ietf.org/doc/html/rfc7518#section-4.6.2 I would expect to see similar "base64url decoding" for "apu" / "apv" and length encoding details for JOSE HPKE, if COSE HPKE decided that Option 1 was the path forward. JOSE WG could decide to reuse the existing context structures created for ConcatKDF with the KDFs specified in the HPKE algorithm. Hannes, reading between the lines, it sounds like you are proposing that COSE WG reuse COSE_KDF_Context (after addressing the length issues). Are you proposing that the JOSE WG do the same thing, and reuse the context info that is currently required when using ECDH-ES and ConcatKDF ? Regards, OS On Mon, Jun 17, 2024 at 9:27 AM Tschofenig, Hannes <hannes.tschofenig= [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] and [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] > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
