Hi Joe,
My understanding is that we can't get rid of HRR unless we require clients to send a key_share for every key exchange group in the supported_groups extension. This would be a quite large overhead if the client wants to support lots of groups. Also HRR allows servers to request clients to echo Cookies. See section 4.2.2 Cookie. Best, Xiaoyin From: Joseph Birr-Pixton<mailto:jpix...@gmail.com> Sent: Tuesday, December 27, 2016 4:44 PM To: tls@ietf.org<mailto:tls@ietf.org> Subject: [TLS] MTI kx groups, HelloRetryRequest and "Incorrect DHE Share" 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 TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
