Support for detached JWE AAD

[awoie]

For various reasons, it makes sense to introduce a mechanism to support "detached" JWE AAD where the Additional Authenticated Data (AAD) for a JWE is not transmitted in-band but is instead derived by the sender and receiver from contextual information out-of-band. This approach can enhance security, efficiency, and flexibility.

Use Case: Mitigating the "Lazy Verifier" Problem

One specific use case arises from OID4VC, where detached JWE AAD could help mitigate the so-called "lazy verifier" problem.

In this scenario:

• A verifier website sends a request to a wallet (typically a native mobile app).
• The wallet responds with an encrypted message, including contextual information (e.g., the request's origin) as part of the AAD in the JWE response.

This contextual information is authenticated via AEAD but may not be validated by a "lazy verifier," which skips verifying these fields against their expected values based on the established context. This lack of validation makes the system prone to phishing attacks. For example, the wallet might encode the origin where it received the verifier's request in the AAD, e.g., attacker.com. However, if the verifier does not verify this information, an attacker could exploit the oversight.

By requiring the verifier to derive the JWE AAD from contextual information rather than transmitting it in-band:

• The AAD becomes more tightly bound to the verifier's session and context.
• It eliminates the need for explicit validation of the AAD, as the verifier computes it directly from its established session context.
• This reduces the attack surface, making phishing attacks harder to execute.

Need for a Generalized Solution

Since "detached" JWE AAD is not currently defined in the JWE specification and applies to other encryption algorithms (e.g., ECDH-ES), a more general solution could be developed. This would be especially relevant for OID4VC, which uses JARM (JWT Secured Authorization Response Mode, using the JWE compact form) to send encrypted responses. Ensuring compatibility with the JWE compact form would be critical.

Proposed Solution

JWE JSON Serialization (already supports dedicated aad parameter)

For JWE JSON serialization, the existing aad parameter could indicate that the AAD is detached by setting its value to null.

JWE Compact Serialization (no dedicated aad parameter yet)

For JWE compact serialization, the format could be extended to optionally include the AAD as an additional segment:

• Extended Format: <Protected Header>.<Encrypted Key>.<Initialization Vector>.<Ciphertext>.<Authentication Tag>.<AAD>
• Behavior:
  • If the AAD segment is empty or omitted (e.g., <Protected Header>.<Encrypted Key>.<Initialization Vector>.<Ciphertext>.<Authentication Tag>.), it signals that the AAD is detached and must be computed or derived from contextual information by the sender and receiver.
  • The computation of AAD for the AEAD algorithm would follow the same logic as for the JWE JSON form.

Examples:

• JWE Compact Form without AAD (Standard): <Protected Header>.<Encrypted Key>.<Initialization Vector>.<Ciphertext>.<Authentication Tag>
• JWE Compact Form with AAD: <Protected Header>.<Encrypted Key>.<Initialization Vector>.<Ciphertext>.<Authentication Tag>.<AAD>
• JWE Compact Form with Detached AAD: <Protected Header>.<Encrypted Key>.<Initialization Vector>.<Ciphertext>.<Authentication Tag>.

Relevance to OID4VC

This approach could address challenges in OID4VC, particularly in ensuring robust validation of contextual information by the verifier without relying on error-prone implementations.

For example:

• Issue openid/oid4vc-haip#131
• Issue openid/OpenID4VP#347
• Issue openid/OpenID4VP#65

[ilaril]

This seems out of scope for draft-ietf-jose-hpke-encrypt, I think this would need an extension to JWE.

This extension would define how to include application-supplied implicit AAD into "Additional Authenticated Data encryption parameter". I think it is a bad idea to alter message formats for this, I think the application should be in full control of use or non-use of this feature.

Where this would tie to draft-ietf-jose-hpke-encrypt is that JOSE-HPKE Integrated Encryption should use the updated parameter construction rules if the application specifies implicit AAD to use.

[tireddy2]

I created the first cut of the draft, https://github.com/tireddy2/jwe-detached-aad. @awoie @ilaril - please review and feel free to update it.

[bc-pi]

I am of the ever humble opinion that, for a number of reasons, detached AAD and/or updates to JWE is not the right avenue to pursue for this. Rather, something that would allow for an out-of-band contribution to the KDF, maybe/likely just in the HPKE algs that are the scope of this repo, seems to me a much more tenable avenue.

[edit: that's under the presumption that the so called "Lazy Verifier" problem is one to be addressed at all or with JWE constructs, which I am not convinced of myself but know other valid opinions exist.]

[ilaril]

The request is seemingly for mechanism that allows authenticating the implicit context of message. That is message-level concept, not recipient-level concept, and thus should work with all recipient algorithms. Experience is that mechanisms that sometimes work cause major problems.

Implementing authentication of implicit message context in a way that works with all algorithms means altering the way Additional Authenticated Data encryption parameter is constructed. Which needs updating JWE.

I think the question is if this mechanism is worth it, not how it should be implemented (modulo precise technical details).

And modulo apu/apv handling being totally broken, the current HPKE in JOSE draft does allow out-of-band contributions to KDF (and #14 would have fixed the interaction with apu/apv). I think that the inherent operational limitations on that make it not really useful.

Contrasting to COSE and COSE-HPKE: Layer 0 external_aad is useful for performing implicit context authentication.

[awoie]

I am of the ever humble opinion that, for a number of reasons, detached AAD and/or updates to JWE is not the right avenue to pursue for this. Rather, something that would allow for an out-of-band contribution to the KDF, maybe/likely just in the HPKE algs that are the scope of this repo, seems to me a much more tenable avenue.

I believe this would be a good approach. It would be great if we could think about how this can be done without changing JWE.

Do you have a suggestion @bc-pi?

[OR13]

Why is the presence of PSK not sufficient for this use case?

With HPKE, you can use a psk or an extra hpke info parameter.

psk signals that there is extra data that is needed, and the info parameter does not signal this, but still requires it.

so there are already 2 viable solutions to this use case, and adding another one is a mistake.

Also, perhaps we can move discussion of this to the mailing lists, given that:

https://mailarchive.ietf.org/arch/msg/jose/YkPiJvsJf2oxZpCosFzkRQT5nfg/

and close the issue?

[ilaril]

PSK is meant for secret keys, not for binding data to message (that is what aad is for).

Furthermore, there is no apparent reason this is limited to HPKE, so the same thing should be possible with all algorithms.

So yes, I think this issue should be closed given that draft-reddy-jose-detached-aad exists, which I think outlines (meaning the idea is on the right track) a proper way to do what is requested.