This is very well written, Ilari, and full of practical analysis. Thanks! You
hit the nail on the head when you said that "enc": "int" is there to trigger
the use of a different code path.
I'll note that, for JWE implementations that have not yet been upgraded to
include an integrated encryption code path, they will already do the right
things when encountering "int". They'll reject the input using their existing
code. No code updates are needed until you want to support integrated
encryption.
Finally, I wouldn't say that JOSE HPKE will violate RFC 7516. It will update
the RFC to enable use of the additional syntax to represent integrated
encryption.
Thanks,
-- Mike
-----Original Message-----
From: ilariliusva...@welho.com <ilariliusva...@welho.com>
Sent: Friday, June 20, 2025 1:13 PM
To: JOSE WG <jose@ietf.org>
Subject: [jose] Re: WGLC for draft-ietf-jose-hpke-encrypt-08
On Tue, Jun 17, 2025 at 06:56:52AM -0700, Brian Campbell wrote:
> 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 does not allow for anything like Integrated Encryption mode, so the
mode has to violate the RFC.
> RFC 7516 §4.4.2
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fhtml%2Frfc7516%23section-4.1.2&data=05%7C02%7C%7C0023a3b56fcf47a17c3908ddb036ec94%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638860472129613138%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Tzduc%2BYq28m%2BYng4e3M3UUqSK%2B0tsdw18MtJXWmbNZA%3D&reserved=0>
> 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-jose-hpke-encrypt-09%23sect
> ion-9.2.8&data=05%7C02%7C%7C0023a3b56fcf47a17c3908ddb036ec94%7C84df9e7
> fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638860472129631569%7CUnknown%7CTWF
> pbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsI
> kFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=JiSzLN7nHlogoKmMmq9
> zDv1HYU7gye3P4XmN5v6fWUI%3D&reserved=0>,
> 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.
I do not think "int" is effectively null encryption algorithm. The way it works
is very different. The code I have written handles it as utterly special case.
So it is not at all similar to alg:none in functionality.
Now, an bulk cipher that is not an AEAD, but works even remotely like one would
be very irresponsible.
And I do not think the rationalization is similar either, whereas alg:none is
rationalized as that the message is already authenticated, enc:int is not
rationalized as that the message is already protected, as it explicitly
performs bulk encryption.
> Furthermore, RFC 7516 §4.4.1
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fhtml%2Frfc7516%23section-4.1.1&data=05%7C02%7C%7C0023a3b56fcf47a17c3908ddb036ec94%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638860472129643882%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=e3INja46oN3ccS06RHezQZ2HcyiWjEba6%2F6DyTwqnfw%3D&reserved=0>
> 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-jose-hpke-encrypt-09%23sect
> ion-5&data=05%7C02%7C%7C0023a3b56fcf47a17c3908ddb036ec94%7C84df9e7fe9f
> 640afb435aaaaaaaaaaaa%7C1%7C0%7C638860472129656116%7CUnknown%7CTWFpbGZ
> sb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOI
> joiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=h1OmIn2MQUmmkvlYSiAW%2F
> nwnZEpPkiEBZvLlOR1OHJg%3D&reserved=0>
> 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.
This is fundamential to the whole mode.
> 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.
In practice, Integrated Encryption is so different from the rest that it needs
whole parallel message handling codepath. And having single enc value to check
is helpful for dispatching to that codepath.
In code I have written, it is not a polymorphic return type, it is another set
of methods, that given alg might or might not implement.
> 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.
I think it is highly unlikely that it is possible to significantly improve
Integrated Encyption mode. Thus, major flaws would either be handled by
scrapping it entirely or porting it to something that fundamentally is not JWE.
-Ilari
_______________________________________________
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
