On Tue, Dec 27, 2016 at 7:06 PM, David Benjamin <[email protected]> wrote:
> On Tue, Dec 27, 2016 at 4:44 PM Joseph Birr-Pixton <[email protected]> > wrote: > > Hi folks, > > It appears to me that HRR is a pretty large and tricky source of > complexity in TLS1.3. Judging by the implementations page, 40% don't > support it right now. It's *precisely the kind of thing* that vendors > could easily ship broken/missing support for, and they'd get away with > it for years until it causes a interop problem. > > > This is indeed a problem. HRR costs an RTT, so enforcing server support is > tricky. Realistically, removing groups from the initial ClientHello will > probably be impossible, which makes the proposed P-256 mandate especially > unappealing. > > (We hope to try some ideas in Chrome here, but they'll be more complex > than GREASE. My current thought is to send the occasional empty key shares > ClientHello, either as a parallel probe or just with low probability. Then, > once we have any evidence that a server can't HRR, sticky this and refuse > to offer it initial key shares until it demonstrates HRR support.) > > > The only case where it is used is (4.1.1): > > If there is overlap in the "supported_groups" extension but the client > did not offer a compatible "key_share" extension, then the server will > respond with a HelloRetryRequest > > We could entirely remove HRR if we slightly strengthen the MTI > language covering kx groups: > > - Clients must not only "implement", but actually offer a key share > for NISTP-256 for every ClientHello. > > > Chrome/BoringSSL does not offer P-256 in the initial ClientHello, only > X25519. Early in development, we offered P-256 too but intentionally > trimmed it to X25519. I do not think this is a good reason to reverse that. > > On low-end devices, the CPU cost of ECDH starts showing up. X25519 admits > simpler and faster implementations than P-256. It wouldn't be okay to waste > cycles on a P-256 key share that hopefully tomorrow's TLS 1.3 servers will > just ignore anyway. (And today's servers, though predominantly P-256, will > also ignore it because they're TLS 1.2.) > > You are right that one can amortize the cost, but this adds a pile of > complexity (make sure to never offer the same key share twice in parallel, > cached key shares need lifetimes, limits on cache size, etc). It may end up > worthwhile for other reasons, but not just so servers can cut corners to > use an unfavored group. > It also creates a potential supercookie in the clear part of the handshake which is obviously problematic, and becomes more problematic the more biased the ecosystem is. E.g., if you always offer P256 + X25519 but practically everyone chooses X25519, then you could be offering the P256 share for a very long time before someone picks it up. And of course if you do the straightforward thing and amortize both shares then you have the pattern: ClientHello Server Picks P1 X1 X P1 X2 X P1 X3 P P2 X3 X P2 X4 X This makes it easy to bridge across share selections. -Ekr > > TLS 1.3 requires selecting favored group(s), with all the unfortunate > results that has. Let's at least get what good effects we can and encourage > the current best practice while we have no legacy baggage preventing it. > > David > > > Note: Obviously, this doesn't apply to PSK-only connections where > psk_key_exchange_modes was provided and did not contain psk_dhe_ke. > > This need not have any additional computational overhead, because the > client can amortise the key generation over all handshakes where the > server does not select P-256 (hopefully most of them!). In any case, > it's one fixed-base pointmul. It obviously costs 64 bytes-odd on the > wire, but only if the client wasn't going to send a NISTP-256 share > otherwise. > > Did I miss something? Are there any other uses of HRR in TLS1.3 which > means we can't get rid of it in this way? > > Cheers, > Joe > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls > > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls > >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
