On Tue, Jan 23, 2024 at 01:14:47PM -0600, Orie Steele wrote: > > Using protected headers in Key Encryption is sure to cause severe > problems with several implementations. > > > The problem is that since JWE does not predict that sort of behavior, > the implementations lack the required datapaths. And adding those might > be extremely difficult. > > Without any context binding, the aead used for key encryption and content > encryption could easily be different.
That is not really a problem. > This could lead to a cross mode attack on the content encryption layer. Actually, such attacks are currently possible. The problem is that protected headers can be empty (as "enc" can be in unprotected headers). This causes empty HPKE aad, which collides with aad used in Key Encryption. Passing the protected headers to Key Encryption aad would make this problem _worse_, as now the aad's always collide. Simplest way to solve this would be use some fixed aad for Key Encryption that can not be valid bulk aad (e.g., anything with a space in it). > As you can see in the diff: > https://github.com/OR13/draft-jose-hpke-test-vectors/pull/1/files > > There is nothing stopping the content encryption algorithm from being > changed in the current main branch, even if HPKE binds to the aead in the > seal operation for the content encryption key. > > In > https://datatracker.ietf.org/meeting/118/materials/slides-118-lamps-kdf-for-content-encryption-00.pdf > > Russ proposes solving this problem by changing the cek to hkdf(cek, alg). > > Does my proposal to use the `aad` solve this problem without using the hkdf > approach? No. However, instarejecting JWEs with illegal "enc" values takes care of that attack. ... Which points to another security problem with JOSE-HPKE as specified in current draft: "enc" can be ignored. For safety, "enc" must never be ignored, it must be absent if not needed. > So which is best: > > - adding hkdf between generateCek and encryptContent (binding to content > encryption alg at key gen time) > - sealing with the protected header (binding to the content algorithm at > encrypt content encryption key time) > - doing both. The first one. Albeit I think JOSE does not currently use HKDF, but instead some KDF from FIPS. -Ilari _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
