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

[Deirdre Connolly <[e-mail]>]

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://github.com/aws/s2n-tls/issues/4132> 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]> 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]> *On Behalf Of *John Mattsson
> *Sent:* Thursday, November 9, 2023 3:48 AM
> *To:* Sophie Schmieg <sschmieg=[e-mail]>; [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] 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]> on behalf of Sophie Schmieg <
> sschmieg=[e-mail]>
> *Date: *Thursday, 9 November 2023 at 08:40
> *To: *[e-mail] <[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]>
> 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]
> https://www.ietf.org/mailman/listinfo/tls
>