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

[Eric Rescorla <[e-mail]>]

On Thu, Apr 18, 2019 at 1:03 AM Petr Špaček <[e-mail]> wrote:

>
>
> On 01. 04. 19 22:45, Eric Rescorla wrote:
> >
> >
> > On Mon, Apr 1, 2019 at 1:32 PM Brian Dickson
> > <[e-mail] <mailto:[e-mail]>>
> > wrote:
> >
> >
> >
> >     On Wed, Mar 27, 2019 at 2:18 AM Eric Rescorla <[e-mail]
> >     <mailto:[e-mail]>> 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.
> >
> >
> > 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.
>
> 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.




> 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.
>

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.


> 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.
>

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




> 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.
>

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

>
> [1] https://stats.labs.apnic.net/dnssec
>
> --
> Petr Špaček  @  CZ.NIC
>
> _______________________________________________
> Doh mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/doh
>