Re: [TLS] Solving HRR woes in ECH

[Christopher Patton <[e-mail]>]

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.

On Fri, Mar 26, 2021 at 8:10 AM Stephen Farrell <[e-mail]>
wrote:

>
> Hiya,
>
> On 26/03/2021 13:44, Ben Schwartz wrote:
> > 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.
>
> (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.
>
> >
> > On Thu, Mar 25, 2021 at 9:28 PM Nick Sullivan <nick=
> > [e-mail]> 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=
> >> [e-mail]> 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
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/tls
> >>>
> >> _______________________________________________
> >> TLS mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/tls
> >>
> >
> >
> > _______________________________________________
> > TLS mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tls
> >
>