That sounds cool. > On Mar 25, 2021, at 6: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 > <mailto: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 > <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 <mailto:TLS@ietf.org> > https://www.ietf.org/mailman/listinfo/tls > <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
