On Wed, Mar 06, 2024 at 11:50:04AM +0530, tirumal reddy wrote: > On Tue, 5 Mar 2024 at 20:48, Neil Madden <[email protected]> wrote: > > > > Regarding this specific draft under discussion, I'm confused why everyone > > keeps wanting to cram things into the "enc" header? JWE is quite clear that > > this header "MUST be an AEAD algorithm"[2]. KEMs are not AEADs. If we are > > going to add ML-KEM as an encryption algorithm then we should have > > something like "alg":"ML-KEM-768","enc":"A256GCM" or > > "alg":"ML-KEM-768+A256KW" etc. (or "alg":"XWingXYZ+A256KW" or whatever we > > choose). > > > > The use of a fully-specified algorithm aims to permit a limited set of > 'known good' PQ-KEM ciphersuites rather than allowing arbitrary > combinations of PQC algorithms, HKDF, and AEAD algorithms. For instance, > ML-KEM-768, with a PQ security level of 3, must not be used with A128GCM.
It is should not be used, not must not be used. Strength-matching is about performance: It does not make sense to pay significant extra cost to make another component more secure than another component which limits security (without other good reasons). However, strength- matching is no excuse to weaken algorithms without performance benefit (unfortunately I have heard of that happening). And draft-ietf-jose-fully-specified-algorithms-02 is very clear that ML-KEM MUST be added like in the above quoted post, not like the draft does it. Moreover, the JWE requirement that enc is an AEAD is critical for security. COSE forgot to add explicit requirement for all encryption algorithms to be authenticated. Then someone added algorithm that is not, which created an attack. -Ilari _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
