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

[Ilari Liusvaara <[e-mail]>]

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