[TLS] Solving HRR woes in ECH

[Christopher Patton <[e-mail]>]

Hi all,

One of the open issues for ECH is how it interacts with HelloRetryRequest
(HRR). The central difficulty is that a client may advertise different
preferences for HRR-sensitive parameters in the ClientHelloInner and
ClientHelloOuter. And because the HRR path has no explicit signal of which
ClientHello was used, the client may not be able to know how to respond.
The following PR solves this problem by adding to HRR an explicit signal of
which ClientHello was used:
https://github.com/tlswg/draft-ietf-tls-esni/pull/407

The design was originally proposed by David Benjamin in the issue
referenced by the PR. Along the way, It also solves a handful of other HRR
issues that have been identified.

One consequence of this particular solution is that real ECH usage "sticks
out" if the server responds with an HRR. In particular, signaling which
ClientHello was used also signals whether ECH was accepted. However, the
solution is designed to mitigate "don't stick out" attacks that attempt to
trigger the HRR codepath by fiddling with bits on the wire. The
distinguisher only arises when HRR happens organically.

Feedback is appreciated!

Best,
Chris P.