On Tue, Feb 11, 2025 at 12:05:30PM +0530, tirumal reddy wrote: > Hi all, > > The revised draft > https://datatracker.ietf.org/doc/draft-ietf-jose-hpke-encrypt/ addresses > all WG comments and appears ready for WGLC.
There appear to be several technical issues with the way Key Encryption is done: 1) How is HPKE AAD input set? The first paragraph hints that protected header is passed in. However, nothing seems to say exactly how the input is formatted. Furthermore, passing protected header as AAD causes issues: - This is likely to cause severe implementation difficulties with existing JWE implementations, as no current algorithm works like this. These difficulties can become unsurmountable if adding protected header conflicts with assumptions made in external JWE library API. - It does not give cryptographic separation between modes. Preventing the possible attacks from confusing modes is left to checks that are not even specified. The prohibition on mixing modes is impossible to implement, as endpoints lack the needed information. - It does not cryptographically prevent LAMPS-style attacks, as "enc" might be unbound. Checking "enc" as required by JWE prevents these attacks, but at least one member thinks these attacks should be cryptoghraphically prevented. 2) What is the HPKE plaintext? It seems obvious that the HPKE plaintext should be the raw CEK. However, this does not seem to be actually specified anywhere. 3) Message-level requirements that conflict with JWE requirements: Section 6 contains number of requirements on the whole message. Such requirements are not allowed by JWE. > The protected header MUST contain an "enc" that is registered in both > the IANA HPKE AEAD Identifiers Registry, and the IANA JSON Web > Signature and Encryption Algorithms Registry. > > The "iv", "tag" JWE members MUST be present. > > The "aad" JWE member MAY be present. > > The "ciphertext" MUST be the base64url encoded ciphertext as described > in Step 19 in Section 5.1 of [RFC7516]. All thsese should be removed. 4) Unsafe stuff in requirements The requirements allow header parameter "auth_kid", which is unsafe. > The recipient unprotected header parameters "psk_id" and "auth_kid" > MAY be present. This needs to be MUST NOT. See next item. 5) Requirements using unavailable headers: The recipient processing in JWE uses JOSE Header, not protected or recipient unprotected headers. > The protected header MUST NOT contain an "alg". > > The recipient unprotected header parameters "psk_id" and "auth_kid" > MAY be present. > > The recipient unprotected header parameter "ek" MUST be present. > > The recipient unprotected header MUST contain a registered HPKE > "alg" value. Maybe something like: --------------------- * The JOSE Header MAY contain header parameter "psk_id". * The JOSE Header MUST NOT contain header parameter "auth_kid". * The JOSE Header MUST contain header parameter "ek", containing base64url-encoded HPKE Encapsulated Key. * The JOSE Header MUST contain header parameter "alg", containing a JOSE-HPKE algorithm. --------------------- 6) What "encrypted_key"? It is not clear what is referenced here: > The "encrypted_key" MUST be the base64url encoded content encryption > key as described in Step 15 in Section 5.1 of [RFC7516]. > > The recipient "encrypted_key" is as described in Section 7.2.1 of > [RFC7516]. Maybe something like: --------------------- * Recipient JWE Encrypted Key MUST be the ciphertext from HPKE. --------------------- Then there is a subtle issue that might cause implementation difficulties with existing libraries: All current Key Encryption algorithms have complete JWE Encrypted Keys, which can be decrypted without reference to any headers. However, JOSE-HPKE does not work that way: The key is split between JWE Encypted Key and a header parameter. The simplest way to make JWE Encrypted Key compete would be just mash the ek and ct outputs from HPKE into JWE Encrypted Key. The receiver can figure out how big ek is from alg (e.g., HPKE-0 always has 65 byte ek), and the remaining part must be ct. -Ilari _______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
