Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator

[Matthew Pounsett <[e-mail]>]

On Tue, 19 Mar 2019 at 13:45, Ted Hardie <[e-mail]> wrote:

>
>> I have a relationship with my users and I can control the configuration
>> of their *known* applications.  I do not have a relationship with the
>> malware author that is trying to steal their data, and cannot control the
>> configuration of that (unknown) application.  By running DoT on my borders
>> and blocking all other DNS and DoT traffic, I can provide privacy for my
>> users while still preventing malware from doing its thing.
>>
>
> As I said to Paul, I don't think you can if your only defense is blocking
> DNS access.  Coding a system to use a non-standard resolution protocol over
> TLS is relatively easy; all the malware needs is a specific target to start
> at.  That target can be hard coded, derived from the output of a web
> search, or produced by the output of an algorithm resident in the malware
> and some system-available data (commonly the time).  My apologies if I have
> misunderstood your point here, but unless you also block all traffic for
> which you have seen no resolution event, I believe that it is entirely
> possible to circumvent the defense you describe.
>

I think you need to understand a bit of the history of malware development
and the arms race to block it.

Malware C&C started out at hard-coded IP addresses.  They quickly realized
this didn't work because going to a single address for your C&C is easily
spotted, easily filtered, and easily taken down.  So they moved to using
domain names and DNS; they could change the IP addresses that their C&C
domains resolved to very quickly, and move C&C around, avoiding takedown.
After a while, the domain sales business got better at domain takedowns,
and so malware developers moved from single domains to DGAs.  Which is
where we are today.

Using a hard-coded endpoint for domain resolution, even if it's TLS
encrypted, is as easily spotted and dealt with as using a single hard-coded
endpoint for C&C.. it can be filtered as soon as the anomaly is detected.
Using DGAs to bootstrap such hidden resolution systems has the same
limitations as DGAs above.  It's just adding an extra layer of abstraction,
using identical systems, over the C&C in the first place.  The fact that
they are NOT doing this today, even in the face of domain reputation
systems and RPZ feeds should tell you something.  I'd bet any malware
author who's though of doing what you suggest got at most a few dozen lines
into writing the code, realized they were just reimplementing their
existing C&C, and stopped.


>
>
>> With DoH available at endpoints that my users want to reach using some
>> other application,
>>
>
> And this is the critique that is not of DoH as a protocol, but of a
> specific deployment possibility.  You've seen the Quad9 folks point and the
> Chrome statement of their current deployment plans.  The first said they
> will not deploy DNS resources and other web resources on commingled hosts.
> The second said that they will only use DoH after a probe reveals that it
> is available *at the already configured DNS service*.  This is entirely in
> line with Section 3 of RFC 8484:
>

Quad9 and Chrome's current policies are no guarantee of their future
policies, nor the policies of other major browser developers or web
properties.  I cannot assume a statement made by either organization is
binding on the entire Internet.

When have you ever seen the Internet writ large choose NOT to do a thing
that was enabled by the technology?  The protocol enables (and even
encourages) the deployment possibility, so why shouldn't I expect it?  As
soon as DoH the protocol is in GA codebase of major web browsers there will
immediately be enough uptake on DoH server operation to enable the thing
operators are concerned about.  And remember, the protocol is DESIGNED to
inhibit interference by hiding resolution streams along side other, less
easily blocked traffic.  You seem to be making the argument here, "don't
worry, you'll still be able to interfere with DoH resolution by clients you
don't control."  If so, that is disingenuous at best.

>    A DoH client MUST NOT use a different URI simply because it was
>    discovered outside of the client's configuration (such as through
>    HTTP/2 server push) or because a server offers an unsolicited
>    response that appears to be a valid answer to a DNS query.  This
>    specification does not extend DNS resolution privileges to URIs that
>    are not recognized by the DoH client as configured URIs.
>
>
> Browsers do not have an incentive to permit random websites to poison
> their caches, so I strongly suspect that there will be no ability to pass a
> resolution done in JavaScript down into the browser cache; my experience
> during RTCWeb was that the browsers treated all downloaded JavaScript
> applications as potentially malign.
>

As I (and others) have stated several times, browsers aren't the ultimate
problem.  They will be configurable and thus controllable, when they're
cooperative.  It's the uncooperative clients that are the problem, but
they're going to be enabled by adoption by the browsers.


> it is orders of magnitude more complex for me to block the malware while
>> still allowing my users to reach those endpoints.  Phrased another way, a
>> DoH endpoint at the same IP address as a popular website gives malware the
>> ability to resolve names I was previously able to prevent.
>>
>
> In the RFC 8484 terms, this is a DoH server.  For this threat to be real,
> there is an additional requirement:   the DoH server at the popular website
> must also be trusted by the application as a source of DNS data.  For the
> ones you configure, this remains in your control.  For JavaScript
> applications within browsers, see above.  So this is probably the case only
> for pure malware, which already has other circumventions available.
>

I wish you'd name those other circumventions.  A large part of edge
security these days is predicated on the ability to control malware's
ability to resolve C&C names.


>
>> The only recourse I know of, if DoH is adopted, is to proxy all traffic
>> toward that example site (including requiring me to engage in a MitM
>> decryption attack on my users' web traffic) in order to continue to prevent
>> that malware from circumventing network security.  And because I can't
>> predict which web sites will launch their own DoH endpoints, that means I
>> need to proxy (and decrypt) all web traffic in order to maintain the same
>> level of security I can today.
>>
>> Note that popular Web servers commingling DoH services should answer a
> DNS query probe, so you will be able to tell readily if any of them choose
> to do it.  And, of course, you could respond by blocking the service rather
> than with MitM; I suspect some would.
>

I can't afford to probe every IP address on the planet on a regular basis,
and dynamically modify my blocking based on that.  It's far, far less
expensive to just automatically MitM all web traffic on my network, even
though that is far more expensive than what I have to do today.