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 11:51, tirumal reddy <[e-mail]> wrote:
> 
> On Wed, 6 Mar 2024 at 15:22, Neil Madden <[e-mail] <mailto:[e-mail]>> wrote:
> On 6 Mar 2024, at 09:46, tirumal reddy <[e-mail] <mailto:[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. 
> 
> HPKE already specifies the combination of KEM, KDF, and AEAD.

I'm not sure why HPKE is relevant to this discussion, but in any case HPKE defines separate identifiers for KEMs and AEADs, the same as JOSE: https://www.iana.org/assignments/hpke/hpke.xhtml <https://www.iana.org/assignments/hpke/hpke.xhtml> 

> The need for specifying the AEAD is two-fold: to restrict the number of combinations and to address the threat to symmetric cryptography from quantum computers (see https://www.ietf.org/archive/id/draft-ietf-pquip-pqc-engineers-03.html#section-7.1 <https://www.ietf.org/archive/id/draft-ietf-pquip-pqc-engineers-03.html#section-7.1> for details). NIST suggests that both AES-192 and AES-256 will remain secure for a very long time but allows applications to continue using AES with a key size of 128 (see https://csrc.nist.gov/Projects/post-quantum-cryptography/faqs <https://csrc.nist.gov/Projects/post-quantum-cryptography/faqs>).

If anything, these references (including the one you co-wrote) just reinforce that A128GCM is fine. One of the few things that JOSE got right was defining "enc" as an AEAD. We don't need to change that now.

-- Neil