Re: [TLS] Solving HRR woes in ECH

Hi Chris,

HRR in ECH does seem challenging. This may be tangential to the PR you
linked, but there may be a way to reduce the likelihood of HRR by moving
even more of the handshake negotiation into DNS. The HTTPS RR is already
used for some types of negotiation (ALPN and ECH key), so why can't it be
extended further to advertise to the client what the server is willing to
support for cryptographic negotiations?

For example, the HTTPS record could additionally contain the server's
supported supported_groups and cipher_suites. With this information, a
client could know which key_share extensions a server is likely to accept
and adjust its clienthello accordingly. A client who typically sends two
key_shares (P256 and x25519) for maximal compatibility could then reduce
the size of its client hello (no need to send redundant key_shares) or even
prevent an HRR flow altogether in the case that the default key_shares or
cipher_suites are not supported by the server.

This tweak wouldn't remove the need for HRR completely -- it could be
necessary when changing server configuration, for example -- but it could
remove the need for HRR in the common case.

Nick

On Thu, Mar 25, 2021 at 8: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
>