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

[John Mattsson <[e-mail]>]

Scott Fluhrer wrote:
>We had that argument several IETF’s ago (IETF 105?), and the clear consensus of the working group was that explicit named hybrid combinations (e.g. one for ML-KEM-512 + X25519) was the way to go.

I think it is bit problematic that the discussion was so long ago before any KEM standards were even close to ready and interest in deploying quantum-resistant KEMs was limited. The cluster Deirdre mention are all non-recommended parameters that I personally don’t care about and don’t want to use. I want standards track RFCs. We will likely have FIPS standards for ML-KEM and ML-DSA before IETF 119 and it worries me that TLS WG has not even started any work (which is equally much my fault). I would like to make ML-KEM and ML-DSA mandatory to support in all 3GPP systems that use TLS, DTLS, and QUIC, which are many and growing. Current 3GPP policy is to only use “recommended” parameters.

The discussion at IETF 105 was 10 min discussion about a specific proposal that included complex client preferences and gave the impression that it significantly changes the key schedule. I don’t think any client preferences would be needed except the group order. The server can determine the most preferred PQC KEM and the most preferred ECC group and make a choice based on its own policy. The client should not advertise groups that it does not want to use. The presentation from IETF 105 gives the impression that the key schedule changes. I don’t think a split key PRF changes the key schedule, you just exchange one PRF (HKDF-Extract) with another PRF, in fact I think it was wrong to hard-code HKDF in TLS 1.3, HMAC and HKDF are constructions to mitigate the weaknesses in SHA-2.

https://datatracker.ietf.org/meeting/105/materials/slides-105-tls-sessa-hybrid-key-exchange-in-tls-13-00
https://datatracker.ietf.org/meeting/105/materials/minutes-105-tls-00

>Do we want to reopen that argument?
I guess I already did, but unless people support the idea in this thread, we don’t need to discuss it in a meeting. Registering hybrids as code points clearly work and it’s anybody’s guess how many hybrids will be registered and for how long they will be used. I think the time required for discussing which hybrids to register (or not to register) might be the biggest problem.

Cheers,
John Preuß Mattsson

From: Deirdre Connolly <[e-mail]>
Date: Thursday, 9 November 2023 at 12:28
To: Scott Fluhrer (sfluhrer) <[e-mail]>
Cc: John Mattsson <[e-mail]>, Sophie Schmieg <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?
There are several documents in a cluster that define new hybrid `NamedGroup`s and how those operate / are combined, abstracted away from the rest of the TLS handshake. Treating hybrid schemes (key establishment, signatures) as /separate and distinct from their component algorithms/ is a good idea.

https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-09.html
https://www.ietf.org/archive/id/draft-tls-westerbaan-xyber768d00-03.html
https://www.ietf.org/archive/id/draft-kwiatkowski-tls-ecdhe-kyber-01.html

I am aware of multiple implementations<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-3e8580b6be3fe97e&q=1&e=68363486-341d-4e6c-a177-7f30845c9f18&u=https%3A%2F%2Fgithub.com%2Faws%2Fs2n-tls%2Fissues%2F4132> and at least one deployment<https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html> of the proposed `NamedGroup` `X25519Kyber768Draft00`, so


On Thu, Nov 9, 2023 at 12:01 PM Scott Fluhrer (sfluhrer) <sfluhrer=[e-mail]<mailto:[e-mail]>> wrote:
We had that argument several IETF’s ago (IETF 105?), and the clear consensus of the working group was that explicit named hybrid combinations (e.g. one for ML-KEM-512 + X25519) was the way to go.

Do we want to reopen that argument?  Now, I was on the other side (and I still think it would be a better engineering decision, given the right negotiation mechanism), but if it delays actual deployment, I would prefer if we didn’t.

From: TLS <[e-mail]<mailto:[e-mail]>> On Behalf Of John Mattsson
Sent: Thursday, November 9, 2023 3:48 AM
To: Sophie Schmieg <sschmieg=[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?

Hi,

Everybody seem to agree that hybrids should be specified. Looking in my crystal ball, I predict that registering hybrids as code points will be a big mess with way too many opinions and registrations similar to the TLS 1.2 cipher suites. The more I think about it, the more I think TLS 1.3 should standardize a generic solution for combining two or more key shares.

My understanding of what would be needed:

- New "split_key_PRF" extension indicating that client supports split-key PRF.

- When "split_key_PRF" is negotiated the server may chose more than one group/key share.

      struct {
          NamedGroup selected_groups<0..2^16-1>;
      } KeyShareHelloRetryRequest;

     struct {
          KeyShareEntry server_shares<0..2^16-1>;
      } KeyShareServerHello;

- When "split_key_PRF" is negotiated HKDF-Expand(Secret, HkdfLabel, Length) is replaced by a split-key PRF(Secret1, Secret2, ... , HkdfLabel, Length)

I think the current structure that the TLS server makes the decisions on “groups” and “key shares” should be kept.

There was a short discussion earlier on the list
https://mailarchive.ietf.org/arch/msg/tls/Z-s8A0gZsRudZ9hW4VoCsNI9YUU/


Sophie Schmieg [e-mail]<mailto:[e-mail]> wrote:
”Our stated intention is to move to Kyber once NIST releases the standard”
“I do not think it makes a lot of sense to have multiple schemes based on structured lattices in TLS, and Kyber is in my opinion the superior algorithm.”

I agree with that.

Cheers,
John Preuß Mattsson



From: TLS <[e-mail]<mailto:[e-mail]>> on behalf of Sophie Schmieg <sschmieg=[e-mail]<mailto:sschmieg=[e-mail]>>
Date: Thursday, 9 November 2023 at 08:40
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?
> > On 8 Nov 2023, at 8:34, Loganaden Velvindron <[e-mail]<mailto:[e-mail]>> wrote:
> >
> > I support moving forward with hybrids as a proactively safe deployment
> > option. I think that supporting
> > only Kyber for KEX  is not enough. It would make sense to have more options.
> >
> > Google uses NTRU HRSS internally:
> > https://cloud.google.com/blog/products/identity-security/why-google-now-uses-post-quantum-cryptography-for-internal-comms<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-906db70ac616716e&q=1&e=19fc7c2a-a02d-472c-b2ec-cc51f454c161&u=https%3A%2F%2Fcloud.google.com%2Fblog%2Fproducts%2Fidentity-security%2Fwhy-google-now-uses-post-quantum-cryptography-for-internal-comms>
> >
> > If Google decides to use this externally, how easy would it be to get
> > a codepoint for TLS ?
> As easy as writing it up in a stable document (may or may not be an Internet-draft) and asking IANA for a code point assignment.
>
> It can be done in days, if needed.
>
>  Yoav

Just to clarify a few things about our internal usage of NTRU-HRSS: This is for historic reasons.

Our stated intention is to move to Kyber once NIST releases the standard, see e.g. my talk at PQCrypto [1], where I go into some detail on this topic.
Long story short, we had to choose a candidate well before even NIST's round 3 announcement, and haven't changed since changing a ciphersuite, while relatively straightforward is not free, so we would like to avoid doing it twice in a year.
The only security consideration that went into the decision for NTRU was that we wanted to use a structured lattice scheme, with NTRU being chosen for non-security related criteria that have since materially changed.
I do not think it makes a lot of sense to have multiple schemes based on structured lattices in TLS, and Kyber is in my opinion the superior algorithm.

[1] https://www.youtube.com/watch?v=8PYYM3G7_GY


--
_______________________________________________
TLS mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/tls