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

On Wed, 6 Mar 2024 at 14:13, Ilari Liusvaara <ilariliusvaara@welho.com>
wrote:

> On Wed, Mar 06, 2024 at 11:50:04AM +0530, tirumal reddy wrote:
> > On Tue, 5 Mar 2024 at 20:48, Neil Madden <neil.e.madden@gmail.com>
> 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).
>

The PQ security levels are defined to necessitate computational resources
comparable to or greater than those required for an attack on AES (128,
192, and 256) and SHA-2/SHA-3 algorithms. This includes exhaustive key
recovery for AES and optimal collision search for SHA-2/SHA-3. I don't see
a reason why a draft should allow ML-KEM-768 (PQ Security Level 3) with
A128GCM (PQ Security Level 1) as an exception, and allowing such arbitrary
combinations would significantly increase the number of configurations.

-Tiru

>
> 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
>
> _______________________________________________
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose
>