[prev in list] [next in list] [prev in thread] [next in thread]
List: ietf-tls
Subject: Re: [TLS] Solving HRR woes in ECH
From: Eric Rescorla <ekr () rtfm ! com>
Date: 2021-03-26 21:24:33
Message-ID: CABcZeBNp3EJ6F_+yCUSU9PbW+WzoVVz=FNx9O=EOuWzJ66pLDQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Fri, Mar 26, 2021 at 9:30 AM Christopher Patton <cpatton=
40cloudflare.com@dmarc.ietf.org> 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 <stephen.farrell@cs.tcd.ie>
> 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=
>> > 40cloudflare.com@dmarc.ietf.org> 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=
>> >> 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
>> >>>
>> >> _______________________________________________
>> >> TLS mailing list
>> >> TLS@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/tls
>> >>
>> >
>> >
>> > _______________________________________________
>> > TLS mailing list
>> > TLS@ietf.org
>> > https://www.ietf.org/mailman/listinfo/tls
>> >
>>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
[Attachment #5 (text/html)]
<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Fri, Mar 26, 2021 at 9:30 AM Christopher Patton <cpatton=<a \
href="mailto:40cloudflare.com@dmarc.ietf.org">40cloudflare.com@dmarc.ietf.org</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.</div></div></blockquote><div><br></div><div>Note that this might also be of \
value without ECH.</div><div><br></div><div>-Ekr</div><div><br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>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.<br></div><div><br></div><div>Chris \
P.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On \
Fri, Mar 26, 2021 at 8:10 AM Stephen Farrell <<a \
href="mailto:stephen.farrell@cs.tcd.ie" \
target="_blank">stephen.farrell@cs.tcd.ie</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><br> Hiya,<br>
<br>
On 26/03/2021 13:44, Ben Schwartz wrote:<br>
> This seems like a reasonable suggestion to me, so long as the value is<br>
> purely a "hint", as you seem to be proposing. I would suggest \
structuring<br> > it as an ECHConfig extension. This would avoid the need for \
multiple<br> > points of integration between TLS and DNS, support the use of HRR \
hints in<br> > other ECH use cases that don't involve DNS, and help to \
exercise the<br> > ECHConfig extension mechanism.<br>
<br>
(I'm not stating an opinion on the PR yet but...) If there<br>
is to be some new data included in SVCB/HTTPS RR values then<br>
that ought be structured bearing in mind who produces which<br>
bits of data. An ECHConfig is a binary blob mostly produced<br>
by the client-facing server, whereas TLS parameters for the<br>
backend server are not produced at the same place. Including<br>
the latter as an ECHConfig.extension is not therefore a good<br>
design IMO. Justifying those (IMO:-) unnecessary ECHConfig<br>
extensions is also not a goal.<br>
<br>
Information about the backend's TLS preferences, if published<br>
in the DNS, ought be outside the ech value in HTTPS RRs. If<br>
we wanted to publish information about the client-facing<br>
server's TLS preferences in the backend's zone file, then<br>
that could be put into the ECHConfig all right. (It's a pity<br>
that we didn't split out the ECHConfigs from different<br>
client-facing servers in SVCB/HTTPS to make all that easier<br>
isn't it?)<br>
<br>
Cheers,<br>
S.<br>
<br>
> <br>
> On Thu, Mar 25, 2021 at 9:28 PM Nick Sullivan <nick=<br>
> <a href="mailto:40cloudflare.com@dmarc.ietf.org" \
target="_blank">40cloudflare.com@dmarc.ietf.org</a>> wrote:<br> > <br>
>> Hi Chris,<br>
>><br>
>> HRR in ECH does seem challenging. This may be tangential to the PR you<br>
>> linked, but there may be a way to reduce the likelihood of HRR by moving<br>
>> even more of the handshake negotiation into DNS. The HTTPS RR is already<br>
>> used for some types of negotiation (ALPN and ECH key), so why can't it \
be<br> >> extended further to advertise to the client what the server is \
willing to<br> >> support for cryptographic negotiations?<br>
>><br>
>> For example, the HTTPS record could additionally contain the \
server's<br> >> supported supported_groups and cipher_suites. With this \
information, a<br> >> client could know which key_share extensions a server is \
likely to accept<br> >> and adjust its clienthello accordingly. A client who \
typically sends two<br> >> key_shares (P256 and x25519) for maximal \
compatibility could then reduce<br> >> the size of its client hello (no need to \
send redundant key_shares) or even<br> >> prevent an HRR flow altogether in the \
case that the default key_shares or<br> >> cipher_suites are not supported by \
the server.<br> >><br>
>> This tweak wouldn't remove the need for HRR completely -- it could \
be<br> >> necessary when changing server configuration, for example -- but it \
could<br> >> remove the need for HRR in the common case.<br>
>><br>
>> Nick<br>
>><br>
>> On Thu, Mar 25, 2021 at 8:05 PM Christopher Patton <cpatton=<br>
>> <a href="mailto:40cloudflare.com@dmarc.ietf.org" \
target="_blank">40cloudflare.com@dmarc.ietf.org</a>> wrote:<br> >><br>
>>> Hi all,<br>
>>><br>
>>> One of the open issues for ECH is how it interacts with \
HelloRetryRequest<br> >>> (HRR). The central difficulty is that a client may \
advertise different<br> >>> preferences for HRR-sensitive parameters in the \
ClientHelloInner and<br> >>> ClientHelloOuter. And because the HRR path has \
no explicit signal of which<br> >>> ClientHello was used, the client may not \
be able to know how to respond.<br> >>> The following PR solves this problem \
by adding to HRR an explicit signal of<br> >>> which ClientHello was \
used:<br> >>> <a \
href="https://github.com/tlswg/draft-ietf-tls-esni/pull/407" rel="noreferrer" \
target="_blank">https://github.com/tlswg/draft-ietf-tls-esni/pull/407</a><br> \
>>><br> >>> The design was originally proposed by David Benjamin in \
the issue<br> >>> referenced by the PR. Along the way, It also solves a \
handful of other HRR<br> >>> issues that have been identified.<br>
>>><br>
>>> One consequence of this particular solution is that real ECH usage<br>
>>> "sticks out" if the server responds with an HRR. In \
particular, signaling<br> >>> which ClientHello was used also signals \
whether ECH was accepted. However,<br> >>> the solution is designed to \
mitigate "don't stick out" attacks that attempt<br> >>> to \
trigger the HRR codepath by fiddling with bits on the wire. The<br> >>> \
distinguisher only arises when HRR happens organically.<br> >>><br>
>>> Feedback is appreciated!<br>
>>><br>
>>> Best,<br>
>>> Chris P.<br>
>>> _______________________________________________<br>
>>> TLS mailing list<br>
>>> <a href="mailto:TLS@ietf.org" target="_blank">TLS@ietf.org</a><br>
>>> <a href="https://www.ietf.org/mailman/listinfo/tls" rel="noreferrer" \
target="_blank">https://www.ietf.org/mailman/listinfo/tls</a><br> >>><br>
>> _______________________________________________<br>
>> TLS mailing list<br>
>> <a href="mailto:TLS@ietf.org" target="_blank">TLS@ietf.org</a><br>
>> <a href="https://www.ietf.org/mailman/listinfo/tls" rel="noreferrer" \
target="_blank">https://www.ietf.org/mailman/listinfo/tls</a><br> >><br>
> <br>
> <br>
> _______________________________________________<br>
> TLS mailing list<br>
> <a href="mailto:TLS@ietf.org" target="_blank">TLS@ietf.org</a><br>
> <a href="https://www.ietf.org/mailman/listinfo/tls" rel="noreferrer" \
target="_blank">https://www.ietf.org/mailman/listinfo/tls</a><br> > <br>
</blockquote></div>
_______________________________________________<br>
TLS mailing list<br>
<a href="mailto:TLS@ietf.org" target="_blank">TLS@ietf.org</a><br>
<a href="https://www.ietf.org/mailman/listinfo/tls" rel="noreferrer" \
target="_blank">https://www.ietf.org/mailman/listinfo/tls</a><br> \
</blockquote></div></div>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic