Thanks, Richard. As you may have just seen, the editors made a number of
changes in response to Neil’s useful comments, which can be viewed in the
editor’s draft at
https://ietf-wg-jose.github.io/draft-ietf-jose-hpke-encrypt/draft-ietf-jose-hpke-encrypt.html.
My thoughts on your specific comments are inline below, prefixed by “Mike>”.
From: Richard Barnes <r...@ipv.sx>
Sent: Monday, June 16, 2025 6:28 PM
To: Neil Madden <neil.e.mad...@runbox.eu>
Cc: Karen ODonoghue <kodo...@pobox.com>; JOSE WG <jose@ietf.org>
Subject: [jose] Re: WGLC for draft-ietf-jose-hpke-encrypt-08
I have reviewed this draft, and I broadly agree with Neil's comments [1]. The
document has one fatal flaw, and one that may be straightforward to fix: "int"
should be "alg", not "enc".
The fact that "enc": "int" is bad has been argued in several places. I won't
reprise them here.
On the other hand, "alg": "int" makes sense, with "enc" set to an HPKE
algorithm. It's a direct parallel to "dir", just with an asymmetric key pair
instead of a symmetric key. If you don't like "enc" encompassing authenticated
public-key encryption, use something else, say "ies"; "enc" is not required.
Mike> The working group has gone back and on whether to have the HPKE
integrated encryption algorithm be expressed in the “alg” or “enc” header
parameter. The comparison to “alg”: “dir” does have some resonance with me.
What do others in the working group think of using “alg”: “int” in this case
rather than “enc”: “int”?
It's worth noting, though, that this is a non-trivial semantic change to JWE.
It introduces a new "Key Management Mode" to JWE, in addition to the ones
defined in RFC 7516 (Key Encryption, Key Wrapping, Direct Key Agreement, Key
Agreement with Key Wrapping, and Direct Encryption). Call it "Direct Public
Key Encryption", say. This document needs to define that whole mode, with HPKE
as the first instance.
Mike> I understand this suggestion and it’s clean architecturally. I’ve
personally wondered whether there might be a more general approach that HPKE is
a special case of. This goes a long way in that direction.
That's the "make JWE look like HPKE" approach. You could also take the "make
HPKE look like JWE" approach. Recall that the definition of "alg" is "the
cryptographic algorithm used to encrypt or determine the value of the CEK".
You could use HPKE to determine a CEK by just doing the Setup operation and
exporting a key suitable for the "enc" AEAD algorithm. This just makes HPKE
work like ECDH does today. Even if you use it with DHKEM, you still get some
improved binding properties over raw JWE ECDH.
Mike> Hmmm. That seems like breaking HPKE into parts in ways that were never
envisioned, rather than having it operate as a whole. On initial reaction, I’m
not in favor of this either.
Personally, I prefer the "make JWE look like HPKE" approach, because it reuses
more of HPKE. But I could understand if you didn't like the extra text to
define a new Key Management Mode.
Mike> I agree with you.
In any case: Although HPKE and JWE have slightly different shapes, it's
possible to align them in a couple of sensible ways. Unfortunately, the
current draft does neither, so it needs to be revised to do one or the other.
Mike> Thanks for the useful and actionable feedback.
Other than that, it seems like there's just a bunch of pretty boring clean up.
--Richard
[1] One factual correction. This is not true: "there is an IANA registry of
the specific combinations it works with". HPKE is secure when it is built with
any combination of secure primitives, in the sense described in its security
considerations. But basically: IND-CCA KEM, RO KDF, IND-CCA2 AEAD.
Mike> Thanks for calling this out. I’ll create a PR correcting it.
Thanks again,
-- Mike
On Fri, Jun 13, 2025 at 6:42 AM Neil Madden
<neil.e.mad...@runbox.eu<mailto: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<mailto: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<mailto: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<mailto:c...@ietf.org> mailing list.
Thanks,
Karen, John, and John (jose wg chairs)
_______________________________________________
jose mailing list -- jose@ietf.org<mailto:jose@ietf.org>
To unsubscribe send an email to jose-le...@ietf.org<mailto:jose-le...@ietf.org>
_______________________________________________
jose mailing list -- jose@ietf.org<mailto:jose@ietf.org>
To unsubscribe send an email to jose-le...@ietf.org<mailto:jose-le...@ietf.org>
_______________________________________________
jose mailing list -- jose@ietf.org
To unsubscribe send an email to jose-le...@ietf.org
