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

Hi Bas,

Thanks for adding some structure.

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.

I would definitely want standard track RFCs for ML-KEM and ML-DSA. I think other standards using TLS (IETF and other SDOs like 3GPP) might be hesitant to commit to quantum-resistant TLS based on just code point. I don’t care much for early code points, for me the code points could actually wait until we have standard track RFCs. I

I think the use of major algorithms like ML-KEM and ML-DSA should be specified in standard track RFCs. There are also quite a lot of technical considerations here, TLS has never had any KEMs (a new thing is for example that the server cannot reuse its key share, which I think is a great privacy feature), TLS has never had hybrid algorithms, and the large sizes might need consideration as well. That said, I think the non-hybrid case is relatively simple.

I personally don’t see a strong need for SLH-DSA in TLS. I think the use case for that would mostly be root keys.

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.

I would like non-hybrid code points for all ML-KEM and ML-DSA algorithms NIST standardized. Very likely that will be ML-KEM-512, ML-KEM-768, ML-KEM-1024, ML-DSA-44, ML-DSA-65, and ML-DSA-87. I think that is a likely end state.

Any algorithms specified in the future would either be backup algorithms for cryptographic agility (BIKE, HQC), more conservative algorithms (FrodoKEM, Classic McEliece), or algorithms with smaller sizes (MAYO, SQISign). The trust in any algorithm with smaller sizes would likely be less than in ML-KEM and ML-DSA. I think ML-KEM and ML-DSA are here to stay.

I would strongly want ML-KEM-512 and ML-KEM-1024 in TLS. NIST’s current assesment is that the cost of breaking ML-KEM-512 is higher than the cost to break AES-128 (I agree with that) and UK government just stated that ML-KEM-512 is approved for UK government use. If I want performance, I would use ML-KEM-512. ML-KEM-1024 is absolutely needed for CNSA 2.0 compliance.

If hybrids are specified as single code points, I agree that we should keep the list relatively short. I agree with Bas that the P-curves are not needed. I would go for X25519 and X448 only.

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

yet, but others might.

I agree with Uri, absolutely yes. . I think ML-KEM and ML-DSA is a likely end state.

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

I don’t see the need for hybrid signatures in the TLS handshake. I can see the need in other use cases.

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

Yes. AuthKEM is definitly a different discussion (which I think is interesting to have). AuthKEM is a BIG change. It is not really “TLS 1.3” anymore… If such a mode is added I think that should probably be as part of TLS 1.4. And given that KEM keys require changes to certificate issuance, I think a SIGMA-I mode with signatures would still be needed.

Cheers,
John

From: Bas Westerbaan <bas=40cloudflare.com@dmarc.ietf.org>
Date: Monday, 6 November 2023 at 12:37
To: John Mattsson <john.mattsson@ericsson.com>
Cc: TLS@ietf.org <tls@ietf.org>
Subject: 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<mailto: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<mailto:tls-bounces@ietf.org>> on behalf of internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>>
Date: Friday, 8 September 2023 at 02:48
To: i-d-announce@ietf.org<mailto:i-d-announce@ietf.org> <i-d-announce@ietf.org<mailto:i-d-announce@ietf.org>>
Cc: tls@ietf.org<mailto:tls@ietf.org> <tls@ietf.org<mailto: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<mailto: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<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls