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. 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
