Re: [TLS] Solving HRR woes in ECH

[Stephen Farrell <[e-mail]>]

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
>