The draft-ietf-jose-hpke-encrypt draft is* absolutely not* suitable for publication in its current form. It suffers from numerous issues, some of which Neil highlights below, but in the interest of just getting some WGLC response out (I've had an unfinished draft of this partially written as the conversation continues), I will focus only on its fundamental architectural flaws and clear violations of RFC 7516 (JWE). Neil and later Richard did touch in these issues as well but they deserve to be reiterated.
RFC 7516 §4.4.2 <https://datatracker.ietf.org/doc/html/rfc7516#section-4.1.2> unambiguously defines the JWE "enc" header as follows: The "enc" (encryption algorithm) Header Parameter identifies the content encryption algorithm used to perform authenticated encryption on the plaintext to produce the ciphertext and the Authentication Tag. This algorithm MUST be an AEAD algorithm with a specified key length. The jose-hpke draft's so-called "int" content encryption algorithm <https://datatracker.ietf.org/doc/html/draft-ietf-jose-hpke-encrypt-09#section-9.2.8>, which in practice performs no encryption whatsoever, absolutely does not conform to the normative definition RFC 7516. Full stop. Attempting to define and register what is effectively a null content encryption algorithm for JWE is both dangerous and irresponsible. It evokes troubling parallels to the JWS's "alg": "none", in functionally and the way it's been rationalized, which has long been recognized as a serious security anti-pattern. Just writing the words "this is appropriate" in the document does not change the irresponsible nature of the approach. Furthermore, RFC 7516 §4.4.1 <https://datatracker.ietf.org/doc/html/rfc7516#section-4.1.1> defines the JWE "alg" header parameter as: [The ...] same [...] as the "alg" Header Parameter defined in [...] [JWS], except that the Header Parameter identifies the cryptographic algorithm used to encrypt or determine the value of the CEK. The draft's six "HPKE-[n]" algorithms for use in "alg", when dosing the so-called Integrated Encryption <https://datatracker.ietf.org/doc/html/draft-ietf-jose-hpke-encrypt-09#section-5> mode/variant, do not satisfy that definition from RFC 7516. They do the whole key agreement/encapsulation and content encryption process, which is definitely not encrypting or determining the value of the CEK. Additionally, it is very awkward and problematic for each of those "alg" values to have two completely different behaviors conditional on the value of the "enc" header - to further the misuse of the term - think of it like a polymorphic return type for these algorithms where sometimes they return encrypted content and sometimes return an encrypted CEK. This introduces new and unnecessary coupling between the "alg" and "enc" headers and undermines the many of the benefits of having more fully specified algorithms. Given HPKE’s current and growing importance across IETF work and beyond, a JOSE-style container for HPKE deserves thoughtful, responsible, and secure design. Unfortunately, the current draft does not meet that standard of rigor or seriousness. On Fri, Jun 13, 2025 at 4:42 AM Neil Madden <neil.e.mad...@runbox.eu> wrote: > I have reviewed the -09 version and have many comments: > > In the abstract: > > "HPKE works for any combination of an asymmetric key encapsulation > mechanism (KEM), key derivation function (KDF), and authenticated > encryption with additional data (AEAD) function." > > I don’t think this is true - there is an IANA registry of the specific > combinations it works with. Even if we take it as “in principle, it could” > I don’t think that is true either - there are specific requirements on the > components (eg IND-CCA2). I’m not sure what the purpose is of this > sentence, so I’m not sure what alternative text would look like. Maybe > “HPKE is a general framework that supports several algorithms”? > > The abstract should probably also mention that only unauthenticated HPKE > KEMs are supported. > > Section 4: > > "When "alg" is a JOSE-HPKE algorithm” - how do implementors determine if x > is a JOSE-HPKE algorithm? Do they need to keep a list of these? Will they > always start “HPKE-“? > > I find “enc”: “inc” to be problematic. It’s not an AEAD, so violates the > requirement in section 4.1.2 of RFC 7516: > > "This algorithm MUST be an AEAD algorithm with a specified key length.” > > Neither of these requirements are satisfied by “inc”. > > On a related note, what does {“alg”: “RSA-OAEP”, “enc”: “int”} mean? If it > is not allowed, then how is it prevented? Resolving these issues with the > current design will need at least an update of 7516, but it really takes > such a sledgehammer to the existing JWE specifications that I’m not sure an > update is enough. > > I’m more and more convinced that Brian’s suggestion to define a new JWHPKE > would be a better solution than trying to crowbar this into JWE. ( > https://mailarchive.ietf.org/arch/msg/jose/ssmlqF2lUGXwqnhD8SU7l2E1Aqg/) > > "If "enc" is an AEAD algorithm […]” - all “enc” values are supposed to be > AEADs. Maybe this should say “is not “inc””? > > There seems to be a broken reference to RFC 9180 in the last sentence of > this section. > > Section 4.1: > > "HPKE algorithms are not required to process "apu" and "apv" as described > in Section 4.6.1 of [RFC7518], despite appearing to be similar to key > agreement algorithms (such as "ECDH-ES”).” > > Does “are not required to” here actually mean “cannot”? I think this > sentence needs rewording to more clearly say what is meant here. Maybe > something like “Despite appearing similar to ECDH-ES, JOSE-HPKE does not > use the “apu” and “apv” headers.”? > > I find the discussion of “aad” in this section and the previous one > extremely confusing. Section 4 says that compact serialization cannot use > aad, but 4.1 says: > > "The "aad parameter" for Open() and Seal() MUST be used with both HPKE > JWE Integrated Encryption and HPKE JWE Key Encryption.” > > which is it? > > The next sentence about terminology should be moved to section 3 and then > used consistently throughout the document, as it isn’t currently. > > Section 5: > > "JWE Initialization Vector and JWE Authentication Tag MUST NOT be present” > > These are mandatory fields, so perhaps this means to say “MUST be an empty > octet sequence”? > > How do the encryption steps in section 5.1 of RFC 7516 relate to HPKE > encryption? I think quite a lot need to be skipped or changed? > > For decryption, the draft says "When decrypting, the checks in [RFC7516] > section 5.2, steps 1 through 5 MUST be performed.” - what about the steps > 6–18? All of these steps are mandatory in JWE, how can you say this is a > JOSE algorithm and then drive a coach and horses through most of the > processing rules? > > Section 5.1: > > This example is not a valid JWE Compact Serialization - it’s missing a “.” > somewhere. > > Section 5.2: > > This example appears to be of the Key Encryption mode not the Integrated > mode? > > It would be extremely helpful to link to Appendix A in these examples, and > to also consider a step-by-step description of how the examples were > generated, as I think a lot is being left to implementors to figure out on > their own. > > Section 6: > > There is no "RSA-OAEP-384” algorithm - presumably “RSA-OAEP-256” is > intended? > > "The encoding of the protected header encoding remains consistent with > existing JWE formatting rules.” - one too many “encoding”s in this > sentence, I think? > > "The HPKE AAD parameter MUST be set to the empty string.” - now I’m > completely confused about the AAD handling! > > Section 7: > > What is “AKP” key type - does it need a reference? > > Section 7.1: > > I find the use of “encrypt” for the “key_ops” to be interesting. I would > have expected maybe “wrapKey”? I don’t think HPKE public keys are ever used > to directly encrypt content? The draft should maybe clarify how key_ops > relate to JOSE-HPKE operations? > > Section 8: > > "In this case JOSE constructs like JWS and JSON Web Tokens (JWTs) can be > used to add authentication.” > > JWT is not a JOSE construct but rather an application of JOSE. I suggest > removing the “and JSON Web Tokens (JWTs)” part completely. > > It seems a bit strong that the approach of the Informational RFC 8937 is a > “MUST” here. Are we really saying that CEKs MUST be generated as a > pseudorandom function over a signature signed with the *recipient’s private > key*??? I don’t see how this is even possible, let alone a hard > requirement. Did you mean to link to eg RFC 4086 here instead (as JOSE > already does)? (If it’s really a MUST then it also needs to be a Normative > Reference). > > Section 8.1: > > "Additionally, the same key MUST NOT be used for both key encryption and > integrated encryption, as it may introduce security risks. It creates > algorithm confusion, increases the potential for key leakage, cross-suite > attacks, and improper handling of the key.” > > Are we sure all these risks are real? I’m not really sure how using the > same key for both key wrapping and integrated encryption leads to most of > these things? Also, I’m not really sure how you can prevent it - does this > place a requirement on recipients to somehow communicate to all senders > which mode to use? Should there be a new JWK field to communicate this? > > Sections 8.2-8.6 seem like they could be replaced with a general > recommendation to review RFC 8725. > > Section 9.2.8 - presumably the quotes are not needed around “int”? Can we > also mention “HPKE” somewhere in the description? > > For all of these registrations do we need a note to the RFC Editor to > replace “this specification” with the actual RFC when it’s published? > > Section 9.3.1 - I’m still not really clear why the existing JWE Encrypted > Key is not sufficient here, but nevermind. This registration should mention > that it is base64url-encoded. > > 9.3.2 - a HPKE psk_id is an arbitrary byte string, so presumably this > header is also base64url-encoded? > > Overall, I’d say this draft still needs a lot of work to be ready for > publication. > > — Neil > > > On 4 Jun 2025, at 21:25, Karen ODonoghue <kodo...@pobox.com> wrote: > > jose working group, > > > This starts a two-week Working Group Last Call (WGLC) for the Use of > Hybrid Public Key Encryption (HPKE) with JSON Object Signing and Encryption > (JOSE) specification > https://www.ietf.org/archive/id/draft-ietf-jose-hpke-encrypt-08.html. > The WGLC will run for two weeks, ending on Friday, June 20, 2025. > > > > Please review and send any comments or feedback to the JOSE working group > at jose@ietf.org. Even if your feedback is “this is ready for > publication”, please let us know so that we can accurately document > consensus. > > > > Note that this WGLC is intentionally running concurrently with a COSE WGLC > for https://www.ietf.org/archive/id/draft-ietf-cose-hpke-13.html because > the drafts are closely related and their functionality is intended to be > aligned. Please reply to the COSE WGLC on the c...@ietf.org mailing list. > > > > Thanks, > > Karen, John, and John (jose wg chairs) > > > _______________________________________________ > jose mailing list -- jose@ietf.org > To unsubscribe send an email to jose-le...@ietf.org > > > _______________________________________________ > jose mailing list -- jose@ietf.org > To unsubscribe send an email to jose-le...@ietf.org > -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
_______________________________________________ jose mailing list -- jose@ietf.org To unsubscribe send an email to jose-le...@ietf.org
