Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?

Thanks for bringing this up. There are a bunch of (implicit) questions in
your e-mail.

1. Do we want rfc describing the final NIST standards? And for which? I'm
ok with that — in this order of priority: ml-kem, ml-dsa, slh-dsa.

2. For which algorithms do we want to assign codepoints once the NIST
standards are out? Codepoints are cheap and use cases/rules are different,
but especially with the hybrids, I'd encourage us to try to be disciplined
and keep the list as short as we can for now, so that early adopters for
which it doesn't matter, all choose the same thing. The DNS mechanism
of draft-davidben-tls-key-share-prediction helps on the performance side,
but it doesn't solve the duplicate engineering/validation if there are a
dozen essentially equivalent KEMs.

3. Do we want to standardise non-hybrid KEMs for TLS? I don't care for them
yet, but others might.

4. Do we need hybrid signatures for the TLS handshake? I don't see the use,
but could be convinced otherwise.

5. What is the future of AuthKEM? That's definitely a different e-mail
thread.

Concretely, after ML-KEM is finished, I was planning to update
draft-schwabe-cfrg-kyber to match it, and proposing to register a codepoint
for a single ML-KEM-768 hybrid in draft-ietf-tls-hybrid-design.

Best,

 Bas

On Mon, Nov 6, 2023 at 10:10 AM John Mattsson <john.mattsson=
40ericsson.com@dmarc.ietf.org> wrote:

> Hi,
>
>
> NIST has released draft standards for ML-KEM, ML-DSA, and ML-SLH. Final
> standards are expected in Q1 2024.
>
>
> https://csrc.nist.gov/news/2023/three-draft-fips-for-post-quantum-cryptography
>
>
>
> I would like to have standard track TLS (and DTLS, QUIC) RFCs for ML-KEM
> and ML-DSA (all security levels standardized by NIST) as soon as possible
> after the final NIST standards are ready. 3GPP is relying almost
> exclusively on IETF RFCs for uses of public key cryptography (the exception
> is ECIES for IMSI encryption but that will likely use HPKE with ML-KEM in
> the future).
>
>
>
> Looking at the TLS document list, it seems severely lacking when it comes
> to ML-KEM, ML-DSA…
>
>
>
> The adopted draft-ietf-tls-hybrid-design is an informal draft dealing with
> the pre-standard Kyber.
>
> https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
>
> AuthKEM is a quite big change to TLS
>
> https://datatracker.ietf.org/doc/draft-wiggers-tls-authkem-psk/
>
>
>
> This is not adopted, informal, and dealing with the pre-standard Kyber.
>
> https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-kyber/
>
>
>
> What is the TLS WG plan for quantum-resistant algorithms? My current view
> is that I would like ML-KEM-512, ML-KEM-768, ML-KEM-1024, ML-DSA-44,
> ML-DSA-65, and ML-DSA-87 registered asap. For hybrid key exchange I think
> X25519 and X448 are the only options that make sense. For hybrid signing,
> ECDSA, EdDSA, and RSA could all make sense.
>
>
>
> Cheers,
> John
>
>
>
> *From: *TLS <tls-bounces@ietf.org> on behalf of internet-drafts@ietf.org <
> internet-drafts@ietf.org>
> *Date: *Friday, 8 September 2023 at 02:48
> *To: *i-d-announce@ietf.org <i-d-announce@ietf.org>
> *Cc: *tls@ietf.org <tls@ietf.org>
> *Subject: *[TLS] I-D Action: draft-ietf-tls-hybrid-design-09.txt
>
> Internet-Draft draft-ietf-tls-hybrid-design-09.txt is now available. It is
> a
> work item of the Transport Layer Security (TLS) WG of the IETF.
>
>    Title:   Hybrid key exchange in TLS 1.3
>    Authors: Douglas Stebila
>             Scott Fluhrer
>             Shay Gueron
>    Name:    draft-ietf-tls-hybrid-design-09.txt
>    Pages:   23
>    Dates:   2023-09-07
>
> Abstract:
>
>    Hybrid key exchange refers to using multiple key exchange algorithms
>    simultaneously and combining the result with the goal of providing
>    security even if all but one of the component algorithms is broken.
>    It is motivated by transition to post-quantum cryptography.  This
>    document provides a construction for hybrid key exchange in the
>    Transport Layer Security (TLS) protocol version 1.3.
>
>    Discussion of this work is encouraged to happen on the TLS IETF
>    mailing list tls@ietf.org or on the GitHub repository which contains
>    the draft:
> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-c404f4af2592f2f4&q=1&e=367fabf2-370b-4cec-b657-05a8499decf6&u=https%3A%2F%2Fgithub.com%2Fdstebila%2Fdraft-ietf-tls-hybrid-design
> .
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-09.html
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-hybrid-design-09
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> _______________________________________________
> 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
>