This document does not make any changes to the DNS queries made. It merely adds a parameter to the existing HTTPS-RR/SVCB record, with pre-existing rules on who queries it and when, and describes how TLS can use it.
The interaction between HTTPS-RR and proxies is complex and all already covered by RFC 9460. It sounds like you may be assuming that the TLS client would start querying this in an otherwise unmodified proxy connection flow, but the reality is more complex than that, due to the need to support, e.g. multi-CDN flows. Rather, I would expect that many proxy deployments to lose the record and fail to apply this optimization altogether (with all the costs that entails during PQ KEM transitions) because no one has yet defined a way for client and proxy to coordinate on the split responsibilities. (Unless someone has started this already and I missed it?) If this is a space you're interested in, I think there is work to be done here. Regardless, it's orthogonal to this document, which merely allocates a parameter type. David On Mon, May 6, 2024, 08:31 Roelof duToit <r@nerd.ninja> wrote: > The concept does indeed solve an important problem, but also introduces a > new dependency in an environment that uses explicit proxies (mostly > enterprise networks). In that environment this proposal, alongside ECH, > introduces DNS queries at the TLS client endpoint where previously the DNS > control point was limited to the proxy. It would be good to mention that > in the document. > > —Roelof > > > On May 3, 2024, at 6:09 PM, David Benjamin <david...@chromium.org> wrote: > > Unsurprisingly, I support adoption. :-) > > On Fri, May 3, 2024 at 6:05 PM Joseph Salowey <j...@salowey.net> wrote: > >> This is a working group call for adoption >> for draft-davidben-tls-key-share-prediction. This document was presented >> at IET 118 and has undergone some revision based on feedback since then. >> The current draft is available here: >> https://datatracker.ietf.org/doc/draft-davidben-tls-key-share-prediction/. >> Please read the document and indicate if and why you support or do not >> support adoption as a TLS working group item. If you support adoption >> please, state if you will help review and contribute text to the document. >> Please respond to this call by May 20, 2024. >> >> Thanks, >> >> Joe, Deidre, and Sean >> _______________________________________________ >> 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 To unsubscribe send an email to tls-le...@ietf.org
