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