Subject: Re: [Doh] Mozilla's plans re: DoH

From: Brian Dickson <[email-masked]>
Date: Mon, 1 Apr 2019 13:26:10 -0700

On Fri, Mar 29, 2019 at 11:31 AM Livingood, Jason <
[email-masked]> wrote:

> > [2] Many networks redirect NXDOMAIN to a search/advertising page.
>
> [JL] This is a reply on this somewhat minor point because NXDOMAIN was
> also raised at the side meeting. I wonder if folks have more specific
> references to networks that are *currently* engaged in NXDOMAIN
> redirection. My sense is that this practice was largely fallen by the
> wayside as a result of being overtaken by the browser-based omnibox
> function that launched several years ago and the resulting change in user
> behavior to just type search terms into the address bar and then click on
> search results. In any case, curious to know if there's a list of ISPs
> currently doing this.
>
>
It is probably worth pointing out that, with a very few exceptions in the
CCtld space, that TLDs are DNSSEC signed, and DNSSEC validation can help
prevent NXDOMAIN redirection.
There is still a problematic issue with NSEC3 opt-out. With NSEC or NSEC3
with no opt-out, it is possible to distinguish unsigned delegations from
NXDOMAIN results. When opt-out NSEC3 is used, that is not possible.

This means that in NSEC3 opt-out TLDs, it is technically possible for
NXDOMAIN rewriting by re-purposing the DNSSEC "proof" of NXDOMAIN, into a
DNSSEC "proof" of unsigned delegation.

For TLDs that don't do opt-out, NXDOMAIN rewriting can be blocked by doing
DNSSEC validation.
(This would seem to suggest that having TLDs move away from opt-out would
be in everyone else's interest.)

Brian

---

From: Brian Dickson <[email-masked]>
Date: Mon, 1 Apr 2019 13:32:46 -0700

On Wed, Mar 27, 2019 at 2:18 AM Eric Rescorla <[email-masked]> wrote:

> I’ve heard a number of questions about Mozilla’s plans around
> DoH. We’ve made a number of public statements, but it might be useful
> to try to put this all in one place.
>
> In context, the problem we are attempting to solve here is attack on
> the user’s name resolution from an attacker with full or partial
> control of the network, as contemplated by Section 3 of BCP 72 as well
> as BCP 188. There’s ample evidence of monitoring/manipulation of user
> traffic via this vector [0][1][2].
>

> [1]
> https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-pearce.pdf
>

Looking specifically at the problem statement and evidence, I have a
question about this (or any other) investigative work:
Has there been any related/follow-up work, or other similarly scoped work,
to examine the use of DNSSEC in the domains tested, that you're aware of or
can point folks at?

I.e. Were any of the manipulated domains signed DNSSEC domains, where
validation might have prevented the manipulated responses from being
accepted from the resolver?

Clearly there would still be the issue of being able to find/reach a
resolver that does not manipulate results, but at least the manipulation
would be detected/blocked.

(Percentages overall, and percentages in the manipulated results groups,
would both be interesting and informative.)

Brian

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 1 Apr 2019 13:45:38 -0700

> would be detected/blocked.

I don't have much more information than is in the paper (you'll note I'm
not an author), but generally DNSSEC doesn't help that much here. You can't
safely do DNSSEC validation on user-facing clients because of a combination
of tampering by middleboxes (typically record stripping, etc,. not really
"attacks") and errors in the published DNSSEC records.
-Ekr

---

From: Petr Špaček <[email-masked]>
Date: Thu, 18 Apr 2019 10:03:57 +0200

On 01. 04. 19 22:45, Eric Rescorla wrote:
> 
> 
> On Mon, Apr 1, 2019 at 1:32 PM Brian Dickson
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
> 
> 
>     On Wed, Mar 27, 2019 at 2:18 AM Eric Rescorla <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>     Has there been any related/follow-up work, or other similarly scoped
>     work, to examine the use of DNSSEC in the domains tested, that
>     you're aware of or can point folks at?
> 
> 
>     I.e. Were any of the manipulated domains signed DNSSEC domains,
>     where validation might have prevented the manipulated responses from
>     being accepted from the resolver?
> 
>     resolver that does not manipulate results, but at least the
>     manipulation would be detected/blocked.
> 
> 
> not an author), but generally DNSSEC doesn't help that much here. You
> can't safely do DNSSEC validation on user-facing clients because of a
> combination of tampering by middleboxes (typically record stripping,
> etc,. not really "attacks") and errors in the published DNSSEC records.

Tampering by middleboxes is solved by DoH, isn't it?

Statement "can't safely do DNSSEC validation on user-facing clients
because of ... errors in the published DNSSEC records" requires some
evidence to show it is still valid in 2019.

According to APNIC's data [1] ~ 17 % of web population is behind DNSSEC
validating resolver today, so anyone who screws up DNSSEC will notice
and fix it quite quickly.

Second data point is that we (as CZ.NIC company) provide support to
telcos operating DNSSEC-validating resolvers, and do not see any
significant breakage caused by misconfigured DNSSEC. To give some weight
to this statenemt please note that CZ has ~ 65 % users behind validating
resolvers, CZ.NIC doing support also for local telcos, and we simply do
not see the rummored breakage caused by DNSSEC misconfiguration.

[1] https://stats.labs.apnic.net/dnssec

-- 
Petr Špaček  @  CZ.NIC

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 18 Apr 2019 11:12:42 -0700

> Tampering by middleboxes is solved by DoH, isn't it?

Yes, probably, but given that the context in which I introduced this point
was about the
need for DoH, I'm not sure that that is relevant.

> evidence to show it is still valid in 2019.

Well, I'm not sure why the situation would have changed, but I'd certainly
welcome any data you have to show that client-side DNSSEC validation
is safe.

> and fix it quite quickly.

No, unfortunately not. The question here is about validation in the client,
and
so validating ISP resolvers don't address the problem.

> not see the rummored breakage caused by DNSSEC misconfiguration.

I'm not primarily talking about misconfiguration (though I've seen data
reflecting
that as well [0]) but about damage due to middleboxes.

-Ekr

[0] https://www.cs.umd.edu/~dml/papers/dnssec_imc17.pdf

> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh
>