Define JOSE-HPKE for other specs #14

ilaril · 2024-12-16T08:28:07Z

This attempts to define JOSE-HPKE as a generic mechanism other specifications defining cipher suites can refer to.

This avoids having other specifications adding cipher suites essentially re-define JOSE-HPKE (or leave a lot implicit). Not only is that tedious, it is also error-prone.

This rewrites a large part of section 4. There are quite a bit of technical changes. Most of those changes are to align how Key Encryption works with the requirements in JWE. AAD construction for Key Encryption is also changed, the new construction should pose less implementation difficulties and addresses both cross-mode and oracle attacks, even if JOSE implementation omits mandatory checks. Finally, this also defines how keys (including AKP) work.

Needs a lot of wordsmithing (and I copied text from original that I think needs editorial improvement).

OR13 · 2024-12-16T14:29:16Z

draft-ietf-jose-hpke-encrypt.md


-## Auxiliary Authenticated Application Information
+`len32(enc)||enc||len32(apu)||apu||len32(apv)||apv`


I don't have an objection to this, but ideally we have something similar in the COSE draft, and cross references between the two to make this easier to understand.

OR13 · 2024-12-16T14:33:53Z

I recommend merging this in 1 week, unless there are objections.

draft-ietf-jose-hpke-encrypt.md

tireddy2 · 2024-12-25T12:27:29Z

draft-ietf-jose-hpke-encrypt.md


-Single recipient HPKE JWE Key Encryption with no "aad" can be expressed in Compact JWE Serialization, so long as the recipient and sender use the same HPKE Setup process as described in { Section 5 of RFC9180 }.
+The Recipient Context is defined as follows:


How is the Recipient Context defined in Section 4.2 used by HPKE ?

As aad input in the Key Encryption case.

If apu and apv in JOSE are pretty much completely broken. why use it in the Recipient context ?
What about the "JWE Additional Authenticated Data encryption parameter" defined in Step 14 of Section 5.1 of RFC7516 ?
It needs to be used for both modes.

Apu and apv were included before, I guess to maintain parity with Key Agreement.

And both modes do include JWE AAD. It is part of "Additional Authenticated Data encryption parameter", which then gets fed as aad to bulk encryption (either HPKE or JWE native bulk encryption).

The problem is JWE AAD is not included in the Key Encryption mode, it is only included in the Integrated Encryption mode. It needs to be fixed; it was included in both modes in the latest published version of the draft.

One possible solution for both modes would be use HPKE Setup info to carry the Recipient Context. In both modes, JWE AAD should be conveyed in HPKE aad.

No, it does not need to be conveyed in the HPKE aad. JWE handles JWE AAD itself for all its algorithms.

Yes, but why did you delete most of the existing text in Section 6 (Key Encryption) ?

Most of that section was just repeating stuff from JWE, often not quite correctly.

I don’t see any issues with removing the redundant content from JWE. However, I will need to review all the changes to ensure that no relevant text is removed. I noticed the following:

Section 4.2 is removed.

In Key Encryption section, the latest version of the draft says encrypted_key is base64url encoded content
encryption key but in the PR it says encrypted_key carries the raw enc output.

Regarding 1., that section was redundant with specified HPKE I/O mappings.

Regarding 2., Note that the PR says "JWE Encrypted Key", not "encrypted_key". JWE specifies that the latter is base64url encoding of the former. So the field ends up base64url-encoded.

For the "ek" parameter, there is no automatic base64url-encoding, so the PR explicitly specifies base64url endec.

tireddy2 · 2024-12-25T12:28:05Z

draft-ietf-jose-hpke-encrypt.md


-Single recipient HPKE JWE Key Encryption with no "aad" can be expressed in Compact JWE Serialization, so long as the recipient and sender use the same HPKE Setup process as described in { Section 5 of RFC9180 }.
+The Recipient Context is defined as follows:


Why is the Recipient Context not used for JWE Integrated Encryption ?

Because it is not enough for that case: One needs to authenticate the protected header and JWE AAD.

I meant the HPKE Setup info can be used to be carry the Recipient context in case of JWE Integrated Encryption.

That would require multiplexing that field, since HPKE Setup info is also used for non-broken context binding from application.

Yes, if apu and apv are empty then info carries the context binding from the application.

I don't see existing JWE spec allows application context to be used as aad. what is the need in JWE HPKE to carry the application specific context ?
If application specific context is required, recipient context can be concatenated to application specific context.

Someone requested ability to use the HPKE setup info for implicit context binding. The easiest way to implement that is to default the HPKE setup info to empty (using aad for recipient context) unless application specifies a value.

Which is what this PR does.

I don’t see any issues raised on GitHub or discussions in the WG regarding the need for application-specific context. Why is this requirement specific to JWE HPKE and not ECDH-ES ?

It was one mailing list post. However, I think this mechanism does not work correctly, and should be ripped out.

Expanding a bit on the issue: While one could do things like extract the key thumbprint from envelope signature and then use that as implicit context (to bind the message to its origin), that only being supported for HPKE and not other algorithms is a footgun.

If application wants to bind message to its origin, it should stick whatever context data it is using to either JWE AAD or to protected headers and then check that on decryption.

(Applicability to COSE: everything meant to be usable at layer0 should support external aad, e.g. by using Enc_structure; HPKE in COSE / COSE-HPKE does that.)

Agreed. I will post a message on the JOSE WG mailing list after the holidays to close the issue.

tireddy2 · 2024-12-25T12:32:26Z

draft-ietf-jose-hpke-encrypt.md

+
+The "ek" header parameter MUST NOT be present.
+
+When decrypting, the inputs to HPKE Open operation are set as follows:


Why is the HPKE Setup info not used to convey the JOSE context-specific data (enc, apu and apv) ?
For example TLS ECH uses both aad and info, and the size of HPKE setup info is much larger than 64 bytes. TLS ECH is already supported by browsers.

That is to leave the HPKE setup info free for application to use for actual context binding. Apu and apv in JOSE are pretty much completely broken.

Also, it is unsound to allow any aad,info pair to be valid for both Integrated Encryption and Key Encryption.

If apu and apv is broken, why use it for key encryption mode ?

I included because it was there before, I can only speculate why it was there.

I prefer including them in both modes to maintain consistency with Section 4.6.2 of RFC 7518, or alternatively, not including them with an explanation that it is broken.

I don't see any specification stating that apu and apv are useless in JWE. Until there is consensus in the WG, we will need to include apu and apv in both modes. As an alternative, we could consider explicitly documenting the decision to exclude apu and apv and explain that they are not necessary for HPKE in JWE. This would provide clarity to implementers and trigger further discussion within the WG

No current Key Encryption algorithm supports apu nor apv. That would be one reason to exclude those.

As per Section 4.6.2 of RFC 7518, both apu and apv are used to derive the key which is used to encrypt the CEK.

And there is an attack that exploits precisely that behavior (and there is an analog of that against HPKE that can not be fixed). Basically, apu and apv in JWE are broken beyond repair.

The apu and apv stuff should just be ripped out.

Expanding a bit on the issue: There is no authentication on the apu and apv values, so an attacker that has the public key of the victim can just set those fields to arbitrary values Then if using Key Agreement with Key Wrapping (or HPKE), the attacker can also set CEK to arbitrary value.

Party U Info and Party V Info are only usable with ECDH-SS (or some authenticated ECDH construction), where attacker can not just specify arbitrary values. And it is really only useful for ECDH-SS, which otherwise would have directional symmetry, that could allow attacks (that symmetry is quoted as the reason for Party U Info and Party V Info).

(Applicability to COSE: COSE does support ECDH-SS, where PartyUInfo and PartyVInfo are actually useful, and PartyUInfo.nonce is crucial for security. However, for everything else, those fields are useless.)

I will raise an issue on GitHub and start a thread on the JOSE WG mailing list after the holidays.

tireddy2 · 2024-12-25T12:36:47Z

draft-ietf-jose-hpke-encrypt.md

-Reusing a single KEM key across multiple algorithm combinations MUST be avoided to maintain cryptographic security. Each key and its associated algorithm suite, comprising the KEM, KDF, and AEAD, should be managed independently. This separation prevents unintended interactions or vulnerabilities between suites, ensuring the integrity and security guarantees of each algorithm suite are preserved.
-Additionally, the same key MUST NOT be used for both key wrapping and content 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.
+A single key SHOULD NOT be used as both authentication key and recipient key, as this has not been proven to be safe.


I prefer to use "MUST NOT" instead of "SHOULD NOT". I don't think "authentication key" is defined anywhere in this doc and HPKE draft. It needs to be defined.

Looking at HPKE RFC, I think it should be "sender key" instead of "authentication key".

I can't find the term "sender key" in HPKE RFC.

I got that from reading section 5.1.3...

The notation section implies that the terms are "sender role" and "recipient role". So presumably the statement should be:

A single key SHOULD NOT be used in both sender and recipient roles, as this has not been proven to be safe.

Why would an application use the same key for sender and recipient roles ?
I don't see this attack discussed in HPKE.

I guess application could use the same key for sender and recipient roles because it is easier. It is not good cryptographic practice.

Last paragraph of section 9.2.3. The paragraph talks about using key in multiple "modes", but the only possible issue is with using the same key in both sender and recipient roles. Most likely that is not an issue, but there is no proof of that.

Agreed, I propose to update the text as follows::
A single key MUST NOT be used in both sender and recipient roles. Avoiding the use of the same key for both sender and recipient roles ensures clear cryptographic boundaries and minimizes unintended interactions.

tireddy2 · 2024-12-25T12:50:58Z

draft-ietf-jose-hpke-encrypt.md

+A single key SHOULD NOT be used with both JOSE-HPKE and other algorithms as this might enable cross-protocol attacks.
+
+The context binding performed by JOSE-HPKE and HPKE ensures that it is safe to use a single key with multiple JOSE-HPKE algorithms and for both
+Integrated Encryption and Key Encryption.


If the key is compromised in one of the modes, it will impact the other mode, what is the use case to allow the same key for both Integrated Encryption and Key Encryption ?

Restricting key to one mode does not help against key compromise, as any such compromise must involve mechanisms outside JOSE-HPKE.

Integrated Encryption is more straightforward for one recipient, but can not handle multiple recipients.

Why a key needs to be used for both Integrated Encryption and Key Encryption modes ?

It would also introduce additional complexity of multiple key_ops (derivebits and wrapKey).
I don't see any such rule defined in in JWE which allows a key to be re-used for direct key agreement and key encryption modes.

It is operationally easier to allow both. And AFAIK there is no good reasons to disallow it (where "it might not be safe", e.g., mixing sender and recipient roles, would count as a good reason).

I think key_ops are just totally busted. And it would not need multiple key_ops: Both invoke HPKE, which I think is derivebits (not sure given the mess that is key_ops).

I prefer to keep it simple, managing keys for multiple purposes within the same system increases the complexity of key management and raises the risk of implementation errors.

I prefer to prioritize simplicity: each key should have a well-defined, single purpose. This approach minimizes risk and aligns with the principle of least privilege in cryptographic systems. If there is a strong operational need to allow key reuse, it should be clearly documented along with the associated trade-offs, potential risks and use of multiple key_ops.

AFACIT, there are no trade-offs and no risks beyond those inherit in having an implementation for both.

And what key_ops does HPKE use anyway? I know some implementation used DeriveBits because that was required to enable the needed interfaces.

I disagree. Combining multiple key_ops (e.g., encryption and derivation) can lead to unintended consequences in certain scenarios, such as algorithm confusion or key misuse across contexts. I suggest raising this issue on the WG mailing list for further discussion.

Neither algorithm confusion nor key misuse across contexts is possible with JOSE-HPKE recipient role keys. To get either, one would have to use the same key with sender role, or with something else, and both are NOT RECOMMENDED.

Is it a common practice to reuse the key in different modes, ?
what is the use case to use the same key for JWE Integrated Encryption and Key Encryption ?

tireddy2 · 2024-12-25T12:53:52Z

draft-ietf-jose-hpke-encrypt.md

@@ -345,11 +429,18 @@ HPKE also offers modes that offer authentication.
 HPKE relies on a source of randomness to be available on the device.
 In Key Agreement with Key Wrapping mode, CEK has to be randomly generated and it MUST be ensured that the guidelines in {{RFC8937}} for random number generations are followed.

+## HPKE authentication
+
+Authenticated HPKE modes MUST NOT be used with Key Encryption, as this is trivially insecure.


please elaborate on the insecurity issue.

Anyone that has access to CEK can alter the message by just encrypting a new one and replacing the protected headers / ciphertext.

It is not clear to me why the Authenticated HPKE mode cannot be used
with Key Encryption ?

Put another way, using Authenticated HPKE with Key Encryption would authenticate the CEK. Which does not even indirectly authenticate the actual message.

Whereas Authenticated HPKE with Integrated Encryption does authenticate protected headers, JWE AAD and the message plaintext.

Authenticated HPKE already authenticates the CEK, ensuring it originates from the sender. The plaintext is then encrypted using AEAD, which provides both confidentiality and authentication for the message.

Why does the receiver need stronger assurances that the plaintext itself is cryptographically bound to the sender's identity? The CEK is authenticated, and the AEAD encryption protects the plaintext's integrity and confidentiality.

Could you clarify the specific threat model where this additional assurance becomes critical?

I don’t see the threat.

If there are multiple recipients in the original message, the message authentication breaks down since any other recipient might have forged the message.

Checking for one recipient does not work: The number of recipients is not authenticated, so attacker might have stripped all recipients except the target, so the message appears to have just a single recipient.

Yes, if any recipient acts as a MiTM to modify the message or strip the recipient list, such an attack cannot be detected in JWE, even when Authenticated HPKE is not used.

Such message does not even pretend to be authenticated (unless done by external means like signatures).

I propose to modify the text as follows:
Authenticated HPKE modes MUST NOT be used for Key Encryption, as the message is not authenticated. Any recipient could act as a man-in-the-middle (MitM) and modify the message.

tireddy2 · 2024-12-25T12:59:43Z

draft-ietf-jose-hpke-encrypt.md

+The resulting JWE is filled as follows:
+
+- JWE Protected Header:
+  * SHALL contain "enc" with value "dir"


Replace "SHALL" with "MUST"

tireddy2 · 2024-12-25T12:59:58Z

draft-ietf-jose-hpke-encrypt.md

+
+- JWE Protected Header:
+  * SHALL contain "enc" with value "dir"
+  * SHALL contain "alg" that is the used JOSE-HPKE algorithm.


Replace "SHALL" with "MUST"

tireddy2 · 2024-12-25T13:01:39Z

draft-ietf-jose-hpke-encrypt.md

+- JWE Protected Header:
+  * SHALL contain "enc" with value "dir"
+  * SHALL contain "alg" that is the used JOSE-HPKE algorithm.
+  * MUST contain the "apu", "apv" and "zip" header parameters, if present.


Replace all occurrences of "SHALL" with "MUST" (lines 183 to 192).

Thinking about it, switching between keywords with no defined or obvious pattern (but in this case there is a pattern) looks odd.

Yes, while "SHALL" and "MUST" both indicate mandatory requirements, I prefer sticking to one term in the document which would improve consistency and clarity.

tireddy2 · 2025-01-02T08:25:59Z

I will merge the PR and raise another PR for further updates to the draft.

Updates based on the discussion #14

Define JOSE-HPKE, so other specs can refer to it

e3129f7

OR13 reviewed Dec 16, 2024

View reviewed changes

OR13 approved these changes Dec 16, 2024

View reviewed changes

tireddy2 reviewed Dec 25, 2024

View reviewed changes

tireddy2 merged commit 832915b into ietf-wg-jose:main Jan 2, 2025

tireddy2 added a commit that referenced this pull request Jan 2, 2025

Update to draft

bc818be

Updates based on the discussion #14

tireddy2 mentioned this pull request Jan 2, 2025

Update to draft #17

Open


		## Auxiliary Authenticated Application Information
		`len32(enc)\|\|enc\|\|len32(apu)\|\|apu\|\|len32(apv)\|\|apv`


		Single recipient HPKE JWE Key Encryption with no "aad" can be expressed in Compact JWE Serialization, so long as the recipient and sender use the same HPKE Setup process as described in { Section 5 of RFC9180 }.
		The Recipient Context is defined as follows:


		The "ek" header parameter MUST NOT be present.

		When decrypting, the inputs to HPKE Open operation are set as follows:

Define JOSE-HPKE for other specs #14

Define JOSE-HPKE for other specs #14

Conversation

ilaril commented Dec 16, 2024

Choose a reason for hiding this comment

OR13 commented Dec 16, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tireddy2 Dec 26, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ilaril Dec 27, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ilaril Dec 27, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ilaril Dec 25, 2024 • edited Loading

Choose a reason for hiding this comment

tireddy2 Dec 26, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ilaril Dec 27, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tireddy2 Dec 26, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tireddy2 Dec 28, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tireddy2 Dec 25, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tireddy2 commented Jan 2, 2025

tireddy2 Dec 26, 2024 •

edited

Loading

ilaril Dec 27, 2024 •

edited

Loading

ilaril Dec 27, 2024 •

edited

Loading

ilaril Dec 25, 2024 •

edited

Loading

tireddy2 Dec 26, 2024 •

edited

Loading

ilaril Dec 27, 2024 •

edited

Loading

tireddy2 Dec 26, 2024 •

edited

Loading

tireddy2 Dec 28, 2024 •

edited

Loading

tireddy2 Dec 25, 2024 •

edited

Loading