Re: [COSE] [jose] Fwd: New Version Notification for draft-reddy-cose-jose-pqc-kem-00.txt

[Ilari Liusvaara <[e-mail]>]

On Wed, Mar 06, 2024 at 11:50:04AM +0530, tirumal reddy wrote:
> On Tue, 5 Mar 2024 at 20:48, Neil Madden <[e-mail]> 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