Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement

["Konda, Tirumaleswar Reddy" <[e-mail]>]

+1, DNSSEC itself is susceptible to active attacks and needs a secure channel to protect from an active attacker.

-Tiru

From: dns-privacy [mailto:[e-mail]] On Behalf Of Ben Schwartz
Sent: Saturday, October 28, 2017 9:34 PM
To: Daniel Kahn Gillmor <[e-mail]>
Cc: [e-mail]
Subject: Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement

I agree with DKG's analysis.

Also, as an implementor, I think this requirement would be onerous.  In the software I am modifying, implementing DNS-over-TLS is dramatically easier than adding a validating stub resolver.  I wouldn't be implementing DNS-over-TLS if DNSSEC were mandatory (in either mode).

On Fri, Oct 27, 2017 at 11:40 PM, Daniel Kahn Gillmor <[e-mail]<mailto:[e-mail]>> wrote:
Hey DPRIVE folks--

Apologies for the delay, and that this message is so long.  I've tried
to reconstruct this discussion around
draft-ietf-dprive-dtls-and-tls-profiles-11 as best i can, and my
analysis follows.  If i've misundertood or misanalyzed something,
please let me know.

Summary
-------

I do not believe that DNSSEC validation is warranted as a mitigation
against an active attacker in the context of an opportunistic metaquery,
regardless of whether the client ultimately intends to follow either the
Strict or Opportunistic profile.

Furthermore, i believe that the proposal in draft-11 of making DNSSEC
validation of metaqueries a MUST for the opportunistic profile is
*actively harmful* to the stated goal of the opportunistic profile
(i.e., "maximum chance of DNS service").

I like the reorganization and re-wording of the "Usage Profiles"
section in draft-11, and think we should keep it.  But i think the
other changes between draft-10 and draft-11 are unwarranted and should
be reverted.


Analysis
--------

AIUI, the scenario under discussion is:

 * A DNS client (following either the strict or the opportunistic
   profile)
 * using opportunistic meta-queries to find the desired DNS resolver
 * in the face of an active attacker

We already know that an attacker capable of filtering the client's
*outbound* traffic can cause a denial of service (for clients following
the strict profile) or loss of privacy (for clients following the
opportunistic profile, because they fall back to cleartext) simply by
dropping outbound connections to *anywhere* TCP port 853.

Likewise, We also know that an attacker capable of filtering the
client's *inbound* traffic can cause a denial of service (strict
clients) or loss of privacy (opportunistic clients) simply by dropping
inbound connections from any TCP port 853.

But the introduction of an opportunistically-secured meta-query
introduces a DoS attack (strict clients) or loss of privacy
(opportunistic clients) that can be achieved by a weaker attacker.
Since we're talking about an attacker that is *not* in control of the
network, the following analysis assumes that the the network provides
"legitimate" DHCP service, which is supposed to point the client to a
"legitimate" standard DNS resolver (which may or may not be
privacy-enabled, but is sufficient for answering an opportunistic
metaquery correctly).

In particular, the attacker needs only one of the following two
capabilities:

  (a) Controlling the "legitimate" DHCP server, or detecting the
      client's DHCP request and racing the "legitimate" DHCP server to
      return a DHCP response (this allows the attacker to set the
      resolver used by the client for its opportunistic metaquery), or

  (b) Controlling the "legitimate" DNS resolver, or detecting the
      client's opportunistic metaquery and racing the "legitimate" DNS
      resolver to provide a malicious DNS response.

In either case, the result is that the attacker has poisoned the
client's meta-cache -- its best guess at the location of the desired
privacy-enabled DNS resolver.  A poisoned meta-cache results in a DoS
for clients in "Strict" mode because the attacker's answering DNS
resolver at the learned address cannot authenticate.  A poisoned
meta-cache results in a loss of privacy for clients in "Opportunistic"
mode because they will connect without authentication to the attacker's
answering DNS resolver.

Have i got that right?

DNSSEC validation does not mitigate this attack.

Regardless of the profile, the client has four options when it
discovers that the response to the metadata query was forged (or at
any rate is not validatable).  It can:

  (0) ignore the response, resulting in a DoS regardless of profile,
      or

  (1) ignore the validation failure, and try connecting to the
      proposed address anyway (resulting in a DoS for strict clients
      because the server does not validate, or a loss of privacy for
      opportunistic clients), or

  (2) retry the metaquery (in the hopes that their attacker is in class
      "b" and not in full control of the "legitimate" DNS resolver) and
      maybe the legitimate DNS response will come in, or

  (3) abort the network connection and retry DHCP (in the hopes that the
      attacker is in class "a" and not in full control of the
      "legitimate" DHCP server) and maybe the legitimate DHCP response
      will come in.

Choice 0 is the same outcome as the non-DNSSEC-validating scenario for
strict clients (no mitigation), and *strictly worse* for opportunistic
clients, because it converts a loss of privacy to a DoS, which is in
direct opposition to the stated goal of the opportunistic profile.

Choice 1 is exactly the same outcome as the non-DNSSEC-validating
scenario for all clients. (no mitigation)

Choices 2 and 3 are interesting thought experiments, but are not
directly contemplated in the draft (and i think they would be a
distraction from the goal of the draft -- this draft is not "how to do
staged opportunistic fallback in the face of an arbitrarily corrupt
network"), so i won't go into them here.

At best, DNSSEC validation of the metaquery could be used to provide
additional reporting information to any client-internal
auditing/reporting or other defensive measures; but again, this draft
should not go into those in any detail.

Background
----------

To be clear about where this analysis is coming from, my rule of thumb
for these two profiles is:

 * Strict

   Do whatever you can to connect to the preferred privacy-enabled
   resolver, but don't actually send queries unless you're sure you
   have authenticated the server.

 * Opportunistic

   Do whatever you can to connect to the preferred privacy-enabled
   resolver, but go ahead and send your queries to it anyway, even if
   it cannot be authenticated.

Note that both modes can report (e.g., to a local system
auditor/monitor/policy-agent) any failures or errors they encounter.
But Strict mode will fail closed (DoS), and Opportunistic mode will
fail open (loss of privacy).

To be clear: the client is *locally configured* to be either in Strict
or Opportunistic mode.  Orthogonally, it is also locally configured with
some server authentication information.

If its locally-configured server authentication information is of the
form "ADN" only, then -- even when configured in Strict mode -- it
will do an Opportunistic DNS resolution of the address of the desired
resolver.  This is the "opportunistic meta-query".

Many moons ago, ekr wrote:

> I.e., if you determine whether to adopt a Strict policy based on
> Opportunistic queries, then you are back to the active attack
> setting.

But the client is *not* determining whether to adopt a Strict policy
based on the opportunistic meta-query.  It has already decided which
profile it is using, and the opportunistic meta-query merely to find
the IP address of its desired privacy-enabled DNS resolver.


So i guess i'm still DISCUSSing ekr's DISCUSS, which is an unfortunate
state for the draft to be in. :(


I welcome clarification if i've misunderstood the problem we're trying
to address here, or if i've somehow let myself lapse into some sort of
"privacy nihilism".

         --dkg

_______________________________________________
dns-privacy mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dns-privacy