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 _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
