On Mon, Jun 17, 2024 at 12:08:32PM -0500, Orie Steele wrote: > Hey Hannes, > > 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.
I consider the JOSE identities stuff to be totally broken. The only saving grace being JOSE not actually needing it (due to not having ECDH-SS and similar stuff). The one in COSE is at least useful for rare case that needs it (ECDH-SS). > 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. The only known ways such context could improve upon the existing AEAD context without causing implementation problems is: - Full layer info, instead of collapsing layers 2 and below (not that I know any good reason to use layer 3 for anything, or even to stick anything using encrypion context at layer 2). - One layer up alg info. In JOSE, this information would be highly degenerate because there are only ever two layers, there are no lower protected headers, and JOSE requirements prevent the oracle attack. So the only thing that would be needed is telling the layers apart. (There is an existing place where JOSE gets that wrong: Protected headers are not required, and if there are none, and JWE AAD is not used, then aad is empty, which can get confused with AES-GCM Key Wrapping algorithms. JOSE-HPKE should be designed to be immune to such confusion problems.) > 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. The KDF context does not work the same way in JOSE and COSE! This is caused by philosophical differences in JOSE and COSE design. Specifically, in JOSE, it is always possible to construct the kdf info from message (which I think is totally broken), but there is no guarantee that is possible in COSE. -Ilari _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
