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 don't see the point of including finite field groups. I would hope to hold off on national curves, such as Brainpool and the GOST curves (although they're likely to be forced on us anyways). I personally see Kyber1024 as overkill (of course, if you disagree, please say so). 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) _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
