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

[Benjamin Kaduk <[e-mail]>]

On Tue, Jul 30, 2019 at 07:44:13PM +0000, Scott Fluhrer (sfluhrer) wrote:
> I believe that one important property (of either of the options I listed) is a nice fallback if an enhanced client talks to an older server.  In both cases, the server will see a series of named groups that it doesn’t know (which it will ignore), and possibility an extension it doesn’t know (which it will ignore); the server will accept either a named group that it does understand (if the client did propose a traditional group as a fall back), or it will come to the correct conclusion that the two sides have no mutually acceptable security policy.
> 
> It is not clear if the proposal you outlined share this property; do you duplicate a payload that an unenhanced server would assume only occurs once?

It's clear that anything we do needs to preserve compat with all four
possibilities in the interop matrix for (old, enhanced) (client,
server).  Your closing note about duplicating payloads is something of a
different creature, though, and perhaps should be considered more
explicitly.

Trying to uplevel a bit, option 1 is essentially introducing another
layer of indirection, with the need to carry the additional lookup table
on the side.  This has the disadvantages of both needing the extra layer
of indirection and also can have unfortunate impact from needing the
extra table on the side in more places than is immediately obvious
(i.e., the ESNI case that David mentioned).  The perceived benefit is
that we allocate fewer codepoints, avoid duplicating some KeyShare
information, and maybe get increased flexibility about how we combine
schemes.  In contrast, option 2 is more smoothly integrated into the
existing negotiation mechanism, but has the potential costs of allocating
more codepoints and duplicating some KeyShare information.

But, what are the KeyShare bits that will get duplicated?  If we're just
doing "X25519 plus one post-quantum", only the X25519 share gets
duplicated, even if we want to do several different post-quantum options
in "X25519 plus one post-quantum" form.  And X25519 shares are pretty
small, all things considered!  I'd find the concern about duplicated
KeyShares more compelling if we think we're going to end up needing to
negotiate between (X25519 plus PQ1 plus PQ2) and (X25519 plus PQ2 plus
PQ3) and (X25519 plus PQ1 plus PQ2 plus PQ3), where the PS shares add up
fast.  It's not clear that the ecosystem will end up in a place where we
need to do the latter.

-Ben