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.