On Fri, Mar 26, 2021 at 9:30 AM Christopher Patton <cpatton= 40cloudflare....@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.farr...@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....@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....@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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
