Re: [TLS] ML-KEM key agreement for TLS 1.3

Thanks Deirdre,

I would like to use hybrid but I strongly believe that registering things as standalone NamedGroups and then let TLS negotiate which combinations to  use is the right one long-term. This is the approch chosen be IKEv2.

- As EKR pointed out the word "fully" would need explanation.

- We align with [hybrid] except that instead of joining ECDH options
  with a KEM, we just have the KEM as a NamedGroup.

  I don't understand. We align with hybrid by not being hybrid?

- encapsulated shared secret ciphertext

Maybe shared secret encapsulated in the ciphertext?

Cheers,
John

From: TLS <tls-bounces@ietf.org> on behalf of Eric Rescorla <ekr@rtfm.com>
Date: Wednesday, 6 March 2024 at 16:12
To: Deirdre Connolly <durumcrustulum@gmail.com>
Cc: TLS@ietf.org <tls@ietf.org>
Subject: Re: [TLS] ML-KEM key agreement for TLS 1.3
Deirdre, thanks for submitting this. Can you say what the motivation is for being "fully post-quantum" rather than hybrid?

Thanks,
-Ekr

On Tue, Mar 5, 2024 at 6:16 PM Deirdre Connolly <durumcrustulum@gmail.com<mailto:durumcrustulum@gmail.com>> wrote:
I have uploaded a preliminary version of ML-KEM for TLS 1.3<https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/>  and have a more fleshed out<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-864093ca9ffba626&q=1&e=c11b4b5f-f194-49c4-a720-c34e25cc52c2&u=https%3A%2F%2Fgithub.com%2Fdconnolly%2Fdraft-tls-mlkem-key-agreement> version to be uploaded when datatracker opens. It is a straightforward new `NamedGroup` to support key agreement via ML-KEM-768 or ML-KEM-1024, in a very similar style to -hybrid-design<https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/>.

It will be nice to have pure-PQ options (that are FIPS / CNSA 2.0 compatible) ready to go when users are ready to use them.

Cheers,
Deirdre
_______________________________________________
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls