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= [email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
