Re: [TLS] Options for negotiating hybrid key exchanges for postquantum

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

> -----Original Message-----
> From: Stephen Farrell <[e-mail]>
> Sent: Tuesday, July 30, 2019 3:53 PM
> To: Scott Fluhrer (sfluhrer) <[e-mail]>; Watson Ladd
> <[e-mail]>
> Cc: TLS List <[e-mail]>
> Subject: Re: [TLS] Options for negotiating hybrid key exchanges for
> postquantum
> 
> 
> I'm neutral as to how we represent this stuff for the moment as I think it's
> too early to tell until we get closer to the end of the algorithms competition.

I'm of the opposite opinion; I think it is important to get this settled before (or at the time) the algorithm competition ends.  I really wouldn't want to see us wait for NIST to settle on (say) SIKE and NewHope, and then have us spend another year or two debating on how to integrate them into our protocols.  Instead, I would rather spend the year or two now (when we're not on the critical path).

Now, there are certainly things we don't know yet about the results of the competition (how many algorithms, what types of parameter sets, what sizes of key shares do they have); however (based on the current round 2 submissions) we can certainly have some informed suspicions...

> 
> That said, I do want to second this...
> 
> On 30/07/2019 19:41, Scott Fluhrer (sfluhrer) wrote:
> > Here is one opinion (mine, but I'm pretty sure it is shared by
> > others): the various NIST candidates are based on hard problems that
> > were only recently studied (e.g. supersingular isogenies, Quasicyclic
> > codes), or have cryptanalytic methods that are quite difficult to
> > fully assess (e.g. Lattices).  Even after NIST and CFRG have blessed
> > one or more of them, it would seem reasonable to me that we wouldn't
> > want to place all our security eggs in that one basket.  We currently
> > place all our trust in DH or ECDH; however those have been studied for
> > 30+ years - we are not there yet for most of the postquantum
> > algorithms.
> >
> > Hence, it seems reasonable to me that we give users the option of
> > being able to rely on multiple methods.
> The only person with whom I've spoken who said he'd plan to deploy some
> of this soon is a VPN operator who explicitly wanted to start early and use >1
> PQ scheme (3-4 is what he
> said) plus a current scheme. His expectation was that that'd settle down to
> one PQ scheme, or one PQ and a current one, in time, but that time may be a
> decade after he'd like to start.
> 
> So, to the extent it matters, count me as a +1 for supporting that.
> 
> Cheers,
> S.