Re: [TLS] Solving HRR woes in ECH

[Eric Rescorla <[e-mail]>]

On Fri, Mar 26, 2021 at 9:30 AM Christopher Patton <cpatton=
[e-mail]> wrote:

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

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