Re: [TLS] Solving HRR woes in ECH

This is more complicated than I would have liked, but I also don't see how
to simplify it. As of now, I think it's the best we can do.

-Ekr

On Thu, Mar 25, 2021 at 5:05 PM Christopher Patton <cpatton=
40cloudflare.com@dmarc.ietf.org> wrote:

> 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.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>