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

[tirumal reddy <[e-mail]>]

On Wed, 6 Mar 2024 at 15:22, Neil Madden <[e-mail]> wrote:

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

-Tiru


>
> -- Neil
>
>