Encrypted dns transport works if you can trust the provider you are talking to. DNSSEC works even if you can’t. And if your provider is trustworthy, DNSSEC validation of results acquired through this tunnel should work. So it’s silly in this case to trust the tunnel—there’s no upside to doing so other than avoiding a few signature verifications.
Op za 30 mrt 2024 om 14:02 schreef Rob Sayre <say...@gmail.com> > On Sat, Mar 30, 2024 at 10:47 AM Erik Nygren <erik+i...@nygren.org> wrote: > >> >> An attacker who can prevent SVCB resolution can deny clients any >> associated security benefits. >> >> > Yes. > > >> A hostile recursive resolver can always deny service to SVCB queries, but >> network intermediaries can often prevent resolution as well, even when the >> client and recursive resolver validate DNSSEC and use a secure transport. >> These downgrade attacks can prevent a client from being aware that "ech" is >> configured which would result in the client sending the ClientHello in >> cleartext. >> >> > I think s/would/could/ here. > > I don't know if we want to write it, but doesn't using encrypted transport > DNS to an IP address avoid this problem? Like using 1.1.1.1 or 8.8.8.8 etc. > I know that raises centralization issues, but it does help with this issue. > > thanks, > Rob > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
