Hi Ilari, Please see inline
On Tue, 18 Feb 2025 at 13:02, Ilari Liusvaara <[email protected]> wrote: > 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. > Good catch, added text: This protected header is formatted as BASE64URL(UTF8(JWE Protected Header)). > > 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. > Existing libraries can be adapted to support this mechanism, which leverages the protected header as HPKE AAD. The change introduces an additional step in the decryption process, but it is compatible with current JWE implementations. > > 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. > The modes can be easily distinguished (with 'enc' set to 'dir' for integrated encryption and 'enc' set to an AEAD algorithm for key encryption), ensuring that the modes don’t interfere with each other and keeping the decryption process clear. > > - 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. > In this case, 'enc' is integrity-protected which protects against an attacker who manipulates the encryption algorithm in the 'enc' parameter. > > > 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. > Thanks, Fixed. > > > 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. > I don't see any such restriction imposed in the JWE spec, for instance see https://datatracker.ietf.org/doc/html/rfc7516#section-7.2.1 > > > 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. > I can rephrase the text as follows: The JWE Protected Header MUST include an "enc" value registered in both the IANA HPKE AEAD Identifiers Registry and the IANA JSON Web Signature and Encryption Algorithms Registry to ensure consistency across recipients (see Section 7.2.1 of [RFC7516]). > > > > The "iv", "tag" JWE members MUST be present. > I can rephrase the text as follows: If the selected AEAD algorithm requires an IV and authentication tag, the "iv" and "tag" parameters MUST be present, as specified in {{RFC7516}}. > > > > The "aad" JWE member MAY be present. > What is the problem with the above line ? > > > > The "ciphertext" MUST be the base64url encoded ciphertext as described > > in Step 19 in Section 5.1 of [RFC7516]. > Fixed, it is Step 16 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. > It is allowed but not recommended, see https://www.ietf.org/archive/id/draft-ietf-jose-hpke-encrypt-05.html#section-8.1 . > > > 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. > --------------------- > Updated text. > > > 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. > Combining ek (encapsulated key) and ct (ciphertext) into the JWE Encrypted Key would change the intended semantics of JWE Encrypted Key. I re-collect it as discussed previously and there is no consensus in the WG to concatenate the ek and ct. -Tiru > > > -Ilari > > _______________________________________________ > jose mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
