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

[Ted Hardie <[e-mail]>]

Hi Matt,

Comments in-line.

On Mon, Mar 18, 2019 at 5:50 PM Matthew Pounsett <[e-mail]> wrote:

>
>
> On Fri, 15 Mar 2019 at 14:37, Ted Hardie <[e-mail]> wrote:
>
>>
>>> The past five years have not been the IETF seeking to become a king or
>> king-maker.  They have been spent responding to an attack while still
>> building out the facilities of the network.  I am glad to find you a ready
>> participant now, as there is still work to be done.  But I do not believe
>> we have said that you may not have these facilities; the new methods simply
>> mean you must have a relationship with the users and devices on your
>> network sufficient to effect configuration to use them.  An on-path
>> adversary does not, but you do.  Yes, that adds a step and some complexity,
>> but dealing with a new class of attack was never likely to be free.
>>
>
> This, again, conflates users with attackers.
>
> I'm going to take a stab at restating the positions of several people in
> this thread, Paul included, because it really seems like the argument is
> not understood.
>
> 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.


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

   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.



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


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

regards,

Ted


> Somewhere up-thread it was suggested that there are other reasonable steps
> that a network/security operator can take to maintain the controls over
> resolution that we have today, but so far I haven't seen them enumerated
> anywhere.
>
>
>