My current draft does not include ML-KEM-512, mostly because there seems to be alignment around ML-KEM-768 being ~equivalent to say X25519 or P-256 ECDH in terms of security level. I'm not married strongly to excluding it but that was kind of the thinking.
On Wed, Mar 6, 2024 at 11:25 AM John Mattsson <john.matts...@ericsson.com> wrote: > I think TLS should register all algorithm variants standardized by NIST. > That means ML-KEM-512, ML-KEM-768, and ML-KEM-1024. And in the future a > subset of HQC/BIKE/Classic McEliece. > > I think the TLS discussions are way too focused on a single ephemeral key > exchange. A growing use of TLS is for mutually authenticated interfaces. > When IPsec is used, rekeying is typically done with ephemeral key exchange > every 1 hour or 100 GB following ANSSI requirements. The telecom industry > would like to keep that practice when TLS/DTLS/QUIC is used instead. In TLS > 1.3 that means resumption with psk_dhe_ke. I don’t think you need to use > the same algorithm in the initial handshake and the resumption. You can > e.g., use ML-KEM-1024 + x25519 in the initial handshake and then ML-KEM-512 > in resumption. You could also use McEliece initially and then ML-KEM. I > think you could even use ML-KEM + x25519 in the initial handshake and then > x25519 during resumption. I think these choices should be left to the > application. > > Cheers, > John Preuß Mattson > > Sent from Outlook for iOS <https://aka.ms/o0ukef> > ------------------------------ > *From:* TLS <tls-boun...@ietf.org> on behalf of John Mattsson > <john.mattsson=40ericsson....@dmarc.ietf.org> > *Sent:* Wednesday, March 6, 2024 4:57:10 PM > *To:* Deirdre Connolly <durumcrustu...@gmail.com> > *Cc:* TLS@ietf.org <tls@ietf.org> > *Subject:* 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-boun...@ietf.org> on behalf of Eric Rescorla < > e...@rtfm.com> > *Date: *Wednesday, 6 March 2024 at 16:12 > *To: *Deirdre Connolly <durumcrustu...@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 <durumcrustu...@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 > https://www.ietf.org/mailman/listinfo/tls > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
