Just a clarifying question inline On Sun, Dec 16, 2018 at 3:30 PM Eric Rescorla <e...@rtfm.com> wrote:
> > > On Sun, Dec 16, 2018 at 11:45 AM Paul Wouters <p...@nohats.ca> wrote: > >> On Fri, 14 Dec 2018, Eric Rescorla wrote: >> >> > However, in a large number of cases (e.g., an attacker on your local >> network, >> > there are non-DNSSEC ways of obtaining this property, such as using DoH. >> >> Data origin authenticity is not the same as transport security. >> > > Yes, I'm quite aware of this fact. > > > DoH offers no guarantee that the non-dnssec protected information you >> received is not modified. >> > > As with all things security, it depends on your threat model. If the > attacker you > are concerned with is between you and the DNS server, then in fact it does > provide protection. > > > Unfortunately, I keep needing to say this on various IETF lists. The >> move towards "blindly trusting DNS over HTTPS/TLS" servers is misguided >> and just moving the goal post. >> > > I don't think this is a very accurate characterization of the situation. > At present, > the vast majority of DNS information is not DNSSEC protected [0], and yet > we > have to rely on it. If there's a "blindly trusting" in this discussion, > it's that. DNS > over HTTPS is designed to improve the situation, though of course it's not > a panacea. > > However in *this* case, it actually covers a pretty large fraction of the > threat > model, because (1) many attackers are close to the user and (2) if the > attacker > controls your DNS server, then they learn which site you are going to in > any case even before you send SNI. > This is written as a pretty broad statement. Did you intend to say that the attackers for this threat vector are close to the user or many attackers? Asking as this could sway opinions and the current solution is well suited to CDNs, not necessarily others. Even if all the attacker can do is *modify* > records rather than observe queries, this is often enough. For censorship > applications, > they just serve a blackholed IP address, and for surveillance > applications, an > attacker with significant network capabilities can serve a dedicated IP > for each > server name and then forward the traffic. > > Note that DNSSEC does not help very much in this case. If the attacker is > the server, they don't need to modify records, and if they are not the > server, > then DNSSEC protection relies upon the client hard-failing on DNSSEC > failures, > which generic clients do not do because it would cause unacceptable > failure rates. > > -Ekr > > [0] https://www.cs.umd.edu/~dml/papers/dnssec_imc17.pdf provides an > overview > This is probably a bit better as a reference as it appears to be kept current: https://www.internetsociety.org/deploy360/dnssec/statistics/ and includes links to others providing statistics for reference as well. The validation statistics look a bit better in the following study: https://stats.labs.apnic.net/dnssec/XA?c=XA&x=1&g=1&r=1&w=7&g=0 where worldwide, they say 16% DNSSEC validates. -Kathleen > of the extremely depressing state of play; only 1% of .com is properly > signed > and about 30% of domains which have DNSSEC don't publish all the records > needed to verify the domain. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Best regards, Kathleen
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
