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 [email protected]<mailto:[email protected]> 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 <[email protected]> on behalf of Sophie Schmieg
<[email protected]>
Date: Thursday, 9 November 2023 at 08:40
To: [email protected] <[email protected]>
Subject: Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?
> > On 8 Nov 2023, at 8:34, Loganaden Velvindron
> > <[email protected]<mailto:[email protected]>> 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
[email protected]
https://www.ietf.org/mailman/listinfo/tls
