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

[Vittorio Bertola <[e-mail]>]

Il 3 settembre 2019 19:39 Brian Dickson <[e-mail]> ha scritto:

In this case, the underlying truth problem is asking a user to pick one of N different resolvers to trust, without the user having any way to know independently if any of those resolvers are trustworthy.

If none of the resolvers is trustworthy, then the only solution is to not trust the resolvers. This can be done by forcing DNSSEC validation to be done and to discard any failures.

This would require clients to do DNSSEC validation on the device, rather than trust the assertion of DNSSEC validation that comes from the resolver. This would be easier to implement in the "traditional" model of a stub resolver, but with DoH, each application making DNS queries would need to take care of DNSSEC validation on its own - and I don't see that happening reliably and uniformly.

Moreover, this model would break the cases in which the user does not trust the resolver, but the resolver still has to apply filters because they are legally mandated, or applies filters that are beneficial anyway (e.g. against malware), which however cannot be validated via DNSSEC.

In the end, I think we are at a point where we need to give some thought at the general architecture of DNS resolution over the Internet, and think: where and how should it be done? For example, would it be better if full resolution happened on each individual device? I think that this would have more drawbacks than advantages. So the only alternative is to facilitate the establishment of trust in at least one resolver.

If and only if the user is able to legitimately trust their selected resolver, can that assertion be relied upon, and at that point the assertion has value.

Agreed.

There are at least two things that I see as being problems that need to be worked on to achieve this possibility: discovery of trustworthiness and/or trust relationship with the existing configured resolver; and the "who watches the watchmen" problem of persistent monitoring of allegedly trustworthy resolver operators to determine whether a given response from a particular resolver (including any assertion about blocking and reason) can be trusted.

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.

Still, if Mozilla wants to try to make that model work, they should add into it as much value as possible for users and operators - and being able to exchange trusted communications would be good value for both.

IMHO, deploying any TRR without this devolves to the "can't trust the resolver", which means no blocking, which is a terrible result (given that we live in a malware-infested world as well as other subjectively- and objectively-bad stuff like child pornography).

I would prefer to actually work on these problems.

I also think it would be better for all parties if implementers not deploy things like TRRs until the bare minimum of mechanisms is available, which may require work not only on the applications (doing dns) but also on the resolvers themselves.

I also agree on all these points!

--

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