On Tue, Dec 27, 2016 at 2:27 PM, Xiaoyin Liu <xiaoyi...@outlook.com> wrote:
> 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. > This is true, but an additional concern is that it makes it basically impossible to switch MTI groups. I.e., people will have to support P-256 forever. > > Also HRR allows servers to request clients to echo Cookies. See section > 4.2.2 Cookie. > This too. -Ekr > > > Best, > > Xiaoyin > > > > *From: *Joseph Birr-Pixton <jpix...@gmail.com> > *Sent: *Tuesday, December 27, 2016 4:44 PM > *To: *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 > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
