On Wed, Jul 31, 2019, at 06:21, Benjamin Kaduk wrote: > 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.
Adam directly addressed that concern at the meeting; and others agreed. 25519 shares are small enough that worrying about duplication isn't necessary. The delta is tiny when considering the need to additionally signal combinatorics in the scheme imagined by Option 1. So I'd like to add my voice to those in support of buttoning down a single scheme (i.e., Option 2). The cost of the added indirection is significant. I'll take the addition of a few bytes to the ClientHello over that any time. The other arguments all assume that we'll fail to narrow the parameter set or number of options. My view is that deciding on a single parameter set is not just desirable, but necessary. My experience suggests that clients won't want to expend the resources necessary to create and send two PQ shares. No PQ scheme that I've seen are close enough in terms of efficiency - bytes or CPU - to allow for multiple shares to be offered. Option 2 also allows us to defer the combination method. While I imagine that concatenation will be injective for most schemes, which might be sufficient, we might want to change the combination method as we learn more. Option 2 allows us to include a definition for how secrets produced by each scheme are merged into the key schedule for each combination. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
