I like where this is heading, but just to be extra sure it doesn't come back.
https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-header-parameters https://www.iana.org/assignments/cose/cose.xhtml#header-algorithm-parameters Option 0: hpkeAAD = hpkeEncStructureAsAAD | hpkeJOSEAAD const plaintextOrPublicKeyBytes = suite .createRecipientContext({ recipientKey: ..., enc: encapsulatedKeyBytes }) .open(recipientCipherTextBytes, hpkeAAD) Option 1: hpkeContextInfo = from headers when present / MUST be understood. hpkeAAD = hpkeEncStructureAsAAD | hpkeJOSEAAD const plaintextOrPublicKeyBytes = suite .createRecipientContext({ info: hpkeContextInfo, recipientKey: ..., enc: encapsulatedKeyBytes }) .open(recipientCipherTextBytes, hpkeAAD) ... Both JOSE and COSE should use option 0. In JOSE, hpkeAAD needs to account for JWE AAD, and needs to leverage the protected header. Based on https://www.rfc-editor.org/rfc/rfc7520#section-5.10.4 In COSE, hpkeEncStructureAsAAD needs to account for external_aad, recipient protected header, and top level protected header. I have never needed to use "Enc_Recipient" / "Rec_Recipient" in COSE, I would appreciate comments on their possible relevance to HPKE. Based on https://datatracker.ietf.org/doc/html/rfc9052#section-5.3-4 For Tag 16 (single recipient) based HPKE: Enc_structure = [ context : "Encrypt0", protected : empty_or_serialized_map, // top layer protected header external_aad : bstr // like JWE AAD ] For Tag 96 (multiple recipient) based HPKE: At the encrypt content encryption key with HPKE step: Enc_structure = [ context : "Encrypt0", protected : empty_or_serialized_map, // recipient protected header external_aad : bstr // cbor([top level protected header, external aad]) ] ^ this would match how JOSE handles JWE AAD, and it protects both the protected header at layer 0, and the recipient protected header at layer 1 by using the AEAD AAD, instead of by using a KDF context. This would also address the issues with AES-CBC & AES-CTR - https://www.rfc-editor.org/rfc/rfc9459.html#section-8 If HPKE Seal and Open do not include the top level protected header, AND HPKE has no context for the top level algorithm mixed into the KDF via info, then the cross mode attack that has been discussed on these lists is possible. I do not think we should put fixing the cross mode attack in the general case, as a blocker for HPKE, we should fix the cross mode attack in a separate document, that is only focused on addressing COSE KDF Context... but we cannot design JOSE and COSE HPKE in such a way that they are already vulnerable to the attack. For HPKE, we can simplify things and protected against the attack by: 1. Not requiring COSE KDF Context or its JOSE Contact KDF cousin, in HPKE Info. 2. Ensuring that HPKE AAD contains all protected headers in a message. The first bullet is accomplished the same way in both JOSE and COSE HPKE (just don't compute info or set it). The second bullet is accomplished slightly differently in JOSE and COSE, because of recipient protected headers, which JOSE does not have. In JOSE: hpkeAAD = top level protected header + "." + base64url ( JWE AAD bytes ) // no recipient related stuff In COSE: At the encrypt content encryption key with HPKE step: hpkeEncStructureAsAAD = cbor ( [ "Encrypt0", recipientProtectedHeaderBytes, cbor([protectedHeaderBytes, external_aad])]) or Alternatively, with a new context string and an extra parameter: hpkeEncStructureAsAAD = cbor ( [ "Encrypt-Multiple-With-AEAD-KW", recipientProtectedHeaderBytes, protectedHeaderBytes, external_aad)]) ... In both solutions PartyU / PartyV if present in protected headers, are ignored. What do you think? OS On Wed, Feb 28, 2024 at 3:12 AM Ilari Liusvaara <[email protected]> wrote: > On Tue, Feb 27, 2024 at 02:02:16PM -0600, Orie Steele wrote: > > Hello OSE-Enthusiasts, > > > > As we align JOSE and COSE drafts for adding support for HPKE, we've > > encountered our old friends: > > > > PartyU and PartyV... > > Those two only really make sense for ECDH-SS. JOSE does not support > that at all, nor does HPKE (auth mode is not ECDH-SS). > > > > JOSE has this to say: > > https://datatracker.ietf.org/doc/html/rfc7518#section-4.6.1.2 > > > > """ > > The "apv" (agreement PartyVInfo) value for key agreement algorithms > > using it (such as "ECDH-ES"), represented as a base64url encoded > > string. When used, the PartyVInfo value contains information about > > the recipient. Use of this Header Parameter is OPTIONAL. This > > Header Parameter MUST be understood and processed by implementations > > when these algorithms are used. > > """ > > Note that is only for key agreement algorithms. HPKE is not a key > agreement algorithm. > > Now, native KEM support would be key agreement algorithm and would > process "apv" just like ECDH-ES does. > > > > COSE has this to say: > > > https://datatracker.ietf.org/doc/html/rfc9053#name-context-information-structu > > > > (TLDR... No MUST). > > Every field in that structure seems to be at least one of: > > - Redundant (e.g., AlgorithmID) > - Absurd (e.g., keyDataLength) > - Unsafe (e.g., PartyUInfo.identity) > - Non-interoperable (e.g., Party*Info.other) > > > The design philosophies of JOSE and COSE are rather different. JOSE is > designed to be interoperable and implementable without profiling. COSE > is designed to be heavily profiled down for application, and is not in > general meant to be interoperable nor implementable. > > This already shows in KDF context structures. The JOSE one is > interoperable, the COSE one is explicitly not interoperable. > > Then there is plenty of stuff in COSE that is in theory interoperable, > but no implementation implements it. E.g., ECDH-ES with AES-GCM key > wrapping (bonus points for also using iv-generation). > > > > We have an opportunity to maintain parity here, and essentially > > repeat the support for behavior we have in JOSE and COSE for > > "ECDH-ES+A128KW", when PartyU and PartyV are present. > > As stated above, PartyU and PartyV don't really make sense here. > > > > I've always found this part of encryption in JOSE troublesome, why is it > > necessary for HPKE to support this? > > I don't think there is any good reason to support it. Especially with > the HPKE limitations on parameters. > > > > Are we passing up an opportunity to simplify things and remove an > > unused/underutilized feature from being required in a new, and currently > > not used encryption scheme (HPKE). > > The simplest thing to do is to just ignore that stuff. > > > > Is it time for apu and apv to be ignored when present and not > > understood? > > As explained above, the MUST is inapplicable. Thus "apu" and "apv" > are ignored for HPKE. > > > > > -Ilari > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
