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= 40cisco....@dmarc.ietf.org> 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 <tls-boun...@ietf.org> *On Behalf Of *John Mattsson > *Sent:* Thursday, November 9, 2023 3:48 AM > *To:* Sophie Schmieg <sschmieg=40google....@dmarc.ietf.org>; tls@ietf.org > *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 sschm...@google.com 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 <tls-boun...@ietf.org> on behalf of Sophie Schmieg < > sschmieg=40google....@dmarc.ietf.org> > *Date: *Thursday, 9 November 2023 at 08:40 > *To: *tls@ietf.org <tls@ietf.org> > *Subject: *Re: [TLS] What is the TLS WG plan for quantum-resistant > algorithms? > > > > On 8 Nov 2023, at 8:34, Loganaden Velvindron <logana...@gmail.com> > 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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
