Subject: [TLS] Solving HRR woes in ECH

From: Christopher Patton <[email-masked]>
Date: Thu, 25 Mar 2021 17:05:01 -0700

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.

---

From: Nick Sullivan <[email-masked]>
Date: Thu, 25 Mar 2021 21:28:09 -0400

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=
[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Carrick Bartle <[email-masked]>
Date: Thu, 25 Mar 2021 18:38:06 -0700

That sounds cool.

> On Mar 25, 2021, at 6:28 PM, Nick Sullivan <nick=[email-masked]> wrote:
> 
> 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=[email-masked] <mailto:[email-masked]>> 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 <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.
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 26 Mar 2021 09:44:28 -0400

This seems like a reasonable suggestion to me, so long as the value is
purely a "hint", as you seem to be proposing.  I would suggest structuring
it as an ECHConfig extension.  This would avoid the need for multiple
points of integration between TLS and DNS, support the use of HRR hints in
other ECH use cases that don't involve DNS, and help to exercise the
ECHConfig extension mechanism.

On Thu, Mar 25, 2021 at 9:28 PM Nick Sullivan <nick=
[email-masked]> wrote:

>> 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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 26 Mar 2021 15:10:11 +0000

Hiya,

> ECHConfig extension mechanism.

(I'm not stating an opinion on the PR yet but...) If there
is to be some new data included in SVCB/HTTPS RR values then
that ought be structured bearing in mind who produces which
bits of data. An ECHConfig is a binary blob mostly produced
by the client-facing server, whereas TLS parameters for the
backend server are not produced at the same place. Including
the latter as an ECHConfig.extension is not therefore a good
design IMO. Justifying those (IMO:-) unnecessary ECHConfig
extensions is also not a goal.

Information about the backend's TLS preferences, if published
in the DNS, ought be outside the ech value in HTTPS RRs. If
we wanted to publish information about the client-facing
server's TLS preferences in the backend's zone file, then
that could be put into the ECHConfig all right. (It's a pity
that we didn't split out the ECHConfigs from different
client-facing servers in SVCB/HTTPS to make all that easier
isn't it?)

Cheers,
S.

---

From: Christopher Patton <[email-masked]>
Date: Fri, 26 Mar 2021 09:29:44 -0700

I really like this idea, but I don't see it as a solution to ECH's HRR
woes. NIck's idea boils down to providing a recipe for how to construct the
CHOuter, but AFAICT, there's nothing in the TLS or HTTPS-RR specs that
requires the client to follow this recipe. We would still need a way of
reconciling differences in preferences between CHInner and CHOuter.

I think we should pursue using HTTPS-RR this way independently of ECH. It's
not just useful for ECH, after all. All connections would benefit from
knowing the server's preferences in advance of the ClientHello.

Chris P.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 26 Mar 2021 14:24:16 -0700

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

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 26 Mar 2021 14:24:33 -0700

> reconciling differences in preferences between CHInner and CHOuter.

Note that this might also be of value without ECH.

-Ekr

> I think we should pursue using HTTPS-RR this way independently of ECH.
> It's not just useful for ECH, after all. All connections would benefit from

---

From: David Benjamin <[email-masked]>
Date: Fri, 26 Mar 2021 17:28:32 -0400

(Switching the subject line because the key share hints idea seems
orthogonal to the ECH HRR issue.)

I agree with Stephen that, if we do the key share hint idea, it should be
separate from the ECHConfigList. In addition to a mismatch in describing
client-facing vs. backend servers, there are also multiple ECHConfigs. This
is to manage different ECH versions, key types, sets of critical
extensions, etc. Adding things that aren't correlated with ECH information
would interact awkwardly.

There's also a downgrade nuisance to work through, depending on how the
server interprets key_share vs. supported_groups. Information from DNS is
not authenticated. If your server selects the group based exclusively on
supported_groups, and then only looks at key_share *after* the group
selection is set, unauthenticated key_share hints are fine. Attacker
influence on key_share won't translate to a downgrade attack.

If, however, the server incorporates key_shares into group selection, this
is not okay. An attacker could inject a hint for weaker key shares, and the
server may select that instead. I remember this coming up for TLS 1.3, and
I think we ended up allowing either flow, which is why HelloRetryRequest
retains the handshake transcript. Moreover, the client doesn't know how the
server will interpret the key_share list, but it's the client that decides
whether to honor the hint.

And, yeah, it wouldn't solve ECH's HRR problems because of synchronization
issues and cookies. Also, I don't think this is right:

> NIck's idea boils down to providing a recipe for how to construct the
CHOuter, [...]

It would most likely be a hint towards CHInner, since that's the "actual"
ClientHello, and the aim of such a feature would be to reduce HRRs. This
really seems just orthogonal to ECH.

David