It might make sense to expand on this to: > ECH ensures that TLS does not disclose the SNI, but the same information is also present in the DNS queries used to resolve the server's hostname. This specification does not conceal the server name from the DNS resolver. If DNS messages are sent between the client and resolver without authenticated encryption, an attacker on this path can also learn the destination server name. A similar exposure applies when the DNS resolver is closely correlated with the requesting client, as an on path attacker may be able to infer the destination server name or information about it by observing traffic to DNS authorities [rfc9076].
On Fri, Oct 4, 2024 at 3:06 PM Erik Nygren <erik+i...@nygren.org> wrote: > The suggested text seems inoffensive to me as well, but we may also want > to expand it to cover the recursive-to-authoritative path for resolvers > associated with the client. (ie, just using DoH to your home router isn't > going to help when it uses Do53 to the authorities.). > > On the topic of DNSSEC, it's worth noting that rfc9460 (for SVCB) has some > text there as well which provides some recommendations. > Some of those were general and were intended to provide some degree of > coverage for the ECH use-case (before this was > split out to its own draft). > > > I do share the concerns that Enterprise environments are going to need to > be able to disable ECH. > That seems out of the scope of this draft, and it seems like they could do > this in a few ways: > * Stripping SVCB/HTTPS RRs entirely > * Removing (or replacing) ech entries from the SVCB/HTTPS RRs, especially > if used along with devices that do terminating TLS MitM. > * Managed device client-side policy configured as part of the OS/client > environment. > None of these are in the remit of the IETF or things we want to be > standardizing, so seem out of scope here, > and also none of them truly defend against hostile/compromised clients > that ignore the enterprise policies > and are trying to establish covert channels. It seems like leaving things > on this front out of the draft is preferable. > > Erik > > > > On Fri, Oct 4, 2024 at 11:37 AM Stephen Farrell <stephen.farr...@cs.tcd.ie> > wrote: > >> >> >> On 10/4/24 16:09, Salz, Rich wrote: >> > https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/16 "Discuss >> > the impact of resolver selection on security" >> >> That suggested text seems inoffensive to me fwiw. >> >> S. >> _______________________________________________ >> TLS mailing list -- tls@ietf.org >> To unsubscribe send an email to tls-le...@ietf.org >> >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
