Re: [Add] data integrity and DNSSEC or DoH/DoT

[Vittorio Bertola <[e-mail]>]

> Il 6 settembre 2019 05:27 Paul Wouters <[e-mail]> ha scritto:
> 
> Trusting unsigned data from the internet from random parties is not done
> for any other protocol, why allow it for DNS?

I see your point, but one could reply: is the *content* of any web page you load signed or independently verified for integrity in any way? No, you just authenticate the source and secure the channel, and then trust any content you receive that way. So why should it be different when the content (via DoH) is a DNS response? I'm not saying that this argument is 100% right, but it's how lots of things work now.

[on-device recursor]
> > I think that this would have more drawbacks than advantages.
> 
> Can you elaborate on why you think that is?

Every time the idea comes up, the operations people complain that performance would be bad due to reduced caching, and the privacy people complain that it would become much easier to associate DNS queries to a specific individual/household. Moreover, having billions of active resolvers, rather than hundreds of thousands, would possibly make things like the root key rollover much harder, and exacerbate the problem of obsolete recursors.

However, these are not impossible problems, so it still makes sense to have the discussion.

> >  So the only alternative is to facilitate the establishment of trust
> > in at least one resolver.
> 
> No because transport security provided by a resolver is not data origin
> security offered by DNSSEC.

This is a problem only if you trust ICANN and the zone owner more than you trust your resolver. If it's the opposite, you might just conclude that the resolver must have altered the response for a good reason, and trust the resolver anyway.

> > In the end, I think that a general "resolver accreditation service" on a global scale - which Mozilla has the ambition to create with
> > their TRR list - will never work due to scaling problems, unless you centralize resolution into a handful of global platforms, which
> > IMHO would be a much bigger problem for the Internet. What could instead work is a way for the user to express and change an assertion
> > of trust in one or more resolvers, devolving the problem to the edges of the network and letting each user define implicitly their own
> > requirements for trust.
> 
> Sounds very similar to the browsers having a store of root CA's. It
> didn't really work from a trust point of view, and it was patched up
> with first CRLs, then OCSP and then CT. Why make the same mistake
> with DNs resolvers?

Mozilla's TRR model is similar to a chain of trust with them at the root. However, the user can bless a resolver (i.e., tell the device "I trust a.b.c.d as a resolver") locally, without having to involve any central authority. (And yes, the current CA system is awful.)

> Some believe TRR's are better than random ISP DNS resolvers they happen
> to be (forced to) using, such as hotel or coffee shops. For example,
> I've stayed at hotels whose wifi blocked Priceline and Booking.com
> using DNS. So I don't see why TRR's should not be deployed until
> some mysterious future time.

At the current state of the technology, browsers cannot start a blanket adoption of the TRR model without breaking substantial parts of the Internet, so they shouldn't. They could do it in specific cases where they have determined that this won't create technical, service, policy and legal issues, which AFAIK is what Mozilla is trying to do. The above could be one of those cases, as long as they don't bypass local laws together with the local resolver, and don't clash with the captive portal mechanism. Still, if you care about that problem, I'd advise you to get a proper VPN now, rather than wait for TRRs in the browser.

-- 
 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[e-mail] 
Office @ Via Treviso 12, 10144 Torino, Italy