On Sat, Mar 30, 2024 at 11:09 AM Ted Lemon <mel...@fugue.com> wrote:
> 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. > I don't object to people doing DNSSEC validation of ECH records (though AFAIK no major browser does so), but... 1. The resolver only gains a limited amount by forging the SVCB response because the resolver already knows the domain name you are going to. This does conceal (say) the ALPN, but that's usually less interesting than the SNI. 2. If the authoritative domain is misconfigured, which is not unheard of, then this can create resolution failures (this is true for A/AAAA, of course). Probably not much of an issue for the big public recursives, but can definitely be an issue if you are just talking to some locally-supplied resolver. -Ekr > 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
