On Tue, Dec 18, 2018 at 10:54 AM Kathleen Moriarty < kathleen.moriarty.i...@gmail.com> wrote:
> 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? > I'm not sure I understand the question you are asking. A lot of the threats Asking as this could sway opinions and the current solution is well suited > to CDNs, not necessarily others. > Yes, the current solution is generally designed to fit into CDN-like scenarios. However, ESNI is generally not that useful unless you have a lot of origins on the same domain (otherwise the IP address itself reveals your destination), and there are a limited number of scenarios of this type (CDNs, hosting providers, application servers, etc.) >> [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/ > Thanks. 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. > I believe this is measuring something different, which is the fraction of the Internet which is covered by validating resolvers. However, that doesn't reflect end-to-end validation, but (typically) recursive resolver validation, which is a rather different matter. To my knowledge, no generic browser client does DNSSEC validation, for the reason that when people have looked at it it created unaceptable failure rates. -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
