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

[Brian Dickson <[e-mail]>]

On Tue, Sep 3, 2019 at 8:42 AM Eric Rescorla <[e-mail]> wrote:

>
>
> On Tue, Sep 3, 2019 at 6:15 AM Neil Cook <[e-mail]>
> wrote:
>
>>
>>
>> It’s not entirely  useless. The problem it does solve is giving the user
>> a better experience when a site is blocked for resolvers that support this
>> extended Error Code. Currently for HTTPS the user will end up with a TLS
>> connection error of some kind (or a blank page in some browsers). If a
>> resolver returns a “blocked/censored/prohibited” response, then the browser
>> can tell the user that the web page was blocked with an informative
>> message. Assuming this becomes the default behaviour for non-malicious
>> resolvers then I think it will a good signal for distinguishing  "this is
>> malware blocking" from "this resolver is malicious”.
>>
>
> I'm not following. Suppose that we add an error code that says "this site
> has malware". Now, I operate a resolver which is malicious in the sense
> that it wishes to block a certain form of content (say, access to the IETF)
> but don't want the people whose content I am blocking is being blocked for
> that reason. So, instead I return "this site has malware".
>
> My point here is that a code of this type only tells you what the resolver
> *asserts* the reason it blocked it is, it doesn't necessarily tell you what
> the actual reason that the content was blocked.
>

The high-level issue is that at very least some of the blocking services or
resolvers doing blocking, are set up based on some specific trust
relationship, and that trust is essential in order to have a reason to use
the service or resolver.
Those are typically either internal (enterprise) scenarios where that trust
is basically "same company" and mandated, or a service offered with some
specific terms of service, whether it is a fee-based service or free.

Trying to overlay a different model of third-party resolver where the
client doesn't have a pre-defined trust relationship with that third party,
is where things start to go sideways.

While it might be possible to re-engineer both sides of that equation so
they are not incompatible, the basic issue is that you can't easily tell
whether a resolver currently being used is strictly giving unmodified
results or not. There is no clear signal or flag.

Going beyond assertion might be possible with re-engineering, such as
providing some fourth-party attestation (e.g. the source of the feed that
gets used by the DNS resolver also provides its own signature on individual
entries that would permit human inspection).

>From a mathematical perspective, the problem is one of classical logic
versus modern logic: saying "Every X is a Y" also require an assertion of
existence "There is one member of X", in order to guarantee that Y is not
vacuously true.
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.
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.

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.

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.

Brian