So that we get an initial answer to this (so we can put it into the draft - of course, we can debate what's in the draft...)
Illari suggested: X25519+Kyber768 P384+Kyber768 Well, I would suggest adding in X25519+Kyber512 For those situations where we need to limit the message size (perhaps DTLS and QUIC). Is the working group happy with that? > -----Original Message----- > From: TLS <tls-boun...@ietf.org> On Behalf Of Ilari Liusvaara > Sent: Saturday, August 13, 2022 11:12 AM > To: TLS@ietf.org > Subject: Re: [TLS] WGLC for draft-ietf-tls-hybrid-design > > On Fri, Aug 12, 2022 at 06:13:38PM +0000, Scott Fluhrer (sfluhrer) wrote: > > Again, this is late, however Stephen did ask this to be discussed in the > working group, so here we go: > > > > > -----Original Message----- > > > From: TLS <tls-boun...@ietf.org> On Behalf Of Stephen Farrell > > > Sent: Saturday, April 30, 2022 11:49 AM > > > To: Ilari Liusvaara <ilariliusva...@welho.com>; TLS@ietf.org > > > Subject: Re: [TLS] WGLC for draft-ietf-tls-hybrid-design > > > > > > > > > Hiya, > > > > > > On 30/04/2022 10:05, Ilari Liusvaara wrote: > > > > On Sat, Apr 30, 2022 at 01:24:58AM +0100, Stephen Farrell wrote: > > > >> - section 5: IMO all combined values here need to have > > > >> recommended == "N" in IANA registries for a while and that needs > > > >> to be in this draft before it even gets parked. Regardless of > > > >> whether or not the WG agree with me on that, I think the current > > > >> text is missing stuff in this section and don't recall the WG > > > >> discussing that > > > > > > > > I think that having recommended = Y for any combined algorithm > > > > requires NIST final spec PQ part and recommended = Y for the > > > > classical part (which allows things like x25519 to be the classical > > > > part). > > > > > > > > That is, using latest spec for NISTPQC winner is not enough. This > > > > impiles recommended = Y for combined algorithm is some years out > > > > at the very least. > > > > > > I agree, and something like the above points ought be stated in the > > > draft after discussion in the WG. > > > > Section 5 is 'IANA considerations', and would be where we would list > > the various supported hybrids, which we don’t at the moment. > > > > Well, if we were to discuss some suggested hybrids (and we now know > > the NIST selection), I would suggest these possibilities: > > > > - X25519 + Kyber512 > > - P256 + Kyber512 > > - X448 + Kyber768 > > - P384 + Kyber768 > > I would take: > > X25519+Kyber768 > P384+Kyber768 > > The reason for taking Kyber768 is because the CRYSTALS team recommends > it. The reason for taking P384 is because it is CNSA-approved, so folks that > need CNSA can use that. > > Of course, that is likely to bust packet size limits. I do not think that is > an > issue in TLS, but DTLS and QUIC might be another matter entierely (in theory > DTLS and QUIC can handle it just fine, practice might be another matter > entierely. And if such problems are there, it is good to know about those... > This stuff is experimental). > > > > Of course, it's possible that NIST will tweak the definition of Kyber; > > that's just a possibility we'll need to live with (and wouldn't change > > what hybrid combinations we would initially define) > > I would think such changes would just mean the interim post-quantum kex is > not compatible with the final one. Not that big of deal, there are tens of > thoursands of free codepoints. If an implementation needs both, it can > probably share vast majority of the code. > > > > -Ilari > > _______________________________________________ > 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
