Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

["Scott Fluhrer (sfluhrer)" <[e-mail]>]

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 <[e-mail]> On Behalf Of Ilari Liusvaara
> Sent: Saturday, August 13, 2022 11:12 AM
> To: [e-mail]
> 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 <[e-mail]> On Behalf Of Stephen Farrell
> > > Sent: Saturday, April 30, 2022 11:49 AM
> > > To: Ilari Liusvaara <[e-mail]>; [e-mail]
> > > 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls