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

[Neil Madden <[e-mail]>]

On 6 Mar 2024, at 09:46, tirumal reddy <[e-mail]> wrote:
> 
> On Wed, 6 Mar 2024 at 14:13, Ilari Liusvaara <[e-mail] <mailto:[e-mail]>> wrote:
> 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] <mailto:[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).
> 
> 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.

This is already the case in JOSE - e.g. you can use ECDH-ES with P-521 and then specify A128GCM. You may not like that, but trying to change it retrospectively is a massive breaking change. 

-- Neil