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

[Antoine Germanos <[e-mail]>]

A N T O I N E   G E R M A N O S


On Oct 30, 2017, at 3:12 PM, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>> wrote:

Send dns-privacy mailing list submissions to
   [e-mail]<mailto:[e-mail]>

To subscribe or unsubscribe via the World Wide Web, visit
   https://www.ietf.org/mailman/listinfo/dns-privacy
or, via email, send a message with subject or body 'help' to
   [e-mail]<mailto:[e-mail]>

You can reach the person managing the list at
   [e-mail]<mailto:[e-mail]>

When replying, please edit your Subject line so it is more specific
than "Re: Contents of dns-privacy digest..."


Today's Topics:

  1. Re: review of draft-ietf-dprive-dtls-and-tls-profiles-11: we
     should revert DNSSEC validation requirement (Paul Wouters)
  2. Re: review of draft-ietf-dprive-dtls-and-tls-profiles-11: we
     should revert DNSSEC validation requirement (Paul Wouters)
  3. Re: review of draft-ietf-dprive-dtls-and-tls-profiles-11: we
     should revert DNSSEC validation requirement (Daniel Kahn Gillmor)
  4. Re: review of draft-ietf-dprive-dtls-and-tls-profiles-11: we
     should revert DNSSEC validation requirement (Stephen Farrell)
  5. Re: review of draft-ietf-dprive-dtls-and-tls-profiles-11: we
     should revert DNSSEC validation requirement (Sara Dickinson)


----------------------------------------------------------------------

Message: 1
Date: Mon, 30 Oct 2017 07:17:19 -0400 (EDT)
From: Paul Wouters <[e-mail]<mailto:[e-mail]>>
To: "Konda, Tirumaleswar Reddy" <[e-mail]<mailto:[e-mail]>>
Cc: Ben Schwartz <[e-mail]<mailto:[e-mail]>[e-mail]<mailto:[e-mail]>m<mailto:[e-mail]>>,  Daniel Kahn Gillmor
   <[e-mail]<mailto:[e-mail]>>,  "[e-mail]<mailto:[e-mail]>"
   <[e-mail]<mailto:[e-mail]>>
Subject: Re: [dns-privacy] review of
   draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC
   validation requirement
Message-ID: <[e-mail]<mailto:[e-mail]>>
Content-Type: text/plain; charset=US-ASCII; format=flowed

On Mon, 30 Oct 2017, Konda, Tirumaleswar Reddy wrote:

An active attacker can drop DNS messages with DNSSEC records

The same attacker can block TLS to 8.8.8.8

set the CD bit in the DNS query, AD bit in the DNS response

That will do nothing to validating DNS servers, as they don't use those
bits for anything.

clear the DNSSEC OK bit in the DNS query

That will return a BOGUS answer and will be detected as DoS attack.

or strip the DNSSEC data from the DNS response to disable DNSSEC (Section https://tools.ietf.org/html/rfc3225).

That will return a BOGUS or INDETERMINATE answer and will be detected as
DoS attack.


You have not shown any actual active attack against DNSSEC. You have
only shown denial of service attaks by packet mangling/dropping. All
of that applies equally to TLS.

Paul



------------------------------

Message: 2
Date: Mon, 30 Oct 2017 07:19:36 -0400 (EDT)
From: Paul Wouters <[e-mail]<mailto:[e-mail]>>
To: "Konda, Tirumaleswar Reddy" <[e-mail]<mailto:[e-mail]>>
Cc: Ben Schwartz <[e-mail]<mailto:[e-mail]>>,  "[e-mail]<mailto:[e-mail]>"
   <[e-mail]<mailto:[e-mail]>>,  Daniel Kahn Gillmor <[e-mail]<mailto:[e-mail]>>
Subject: Re: [dns-privacy] review of
   draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC
   validation requirement
Message-ID: <[e-mail]<mailto:[e-mail]>>
Content-Type: text/plain; charset=US-ASCII; format=flowed

On Mon, 30 Oct 2017, Konda, Tirumaleswar Reddy wrote:

   draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC
   validation requirement

Just to be clear. DNSSEC provides authentication of data. TLS provides
privacy of data. Both are needed so I am against this proposed change
to remove DNSSEC validation as a requirement. DNSSEC is part of the
core DNS. It's not a cherry.

Paul



------------------------------

Message: 3
Date: Mon, 30 Oct 2017 13:31:04 +0100
From: Daniel Kahn Gillmor <[e-mail]<mailto:[e-mail]>>
To: Paul Wouters <[e-mail]<mailto:[e-mail]>>, "Konda\, Tirumaleswar Reddy"
   <[e-mail]<mailto:[e-mail]>>
Cc: Ben Schwartz <[e-mail]<mailto:[e-mail]>>, "dns-privacy\@ietf.org"
   <[e-mail]<mailto:[e-mail]>>
Subject: Re: [dns-privacy] review of
   draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC
   validation requirement
Message-ID: <[e-mail]<mailto:[e-mail]>>
Content-Type: text/plain; charset="us-ascii"

On Mon 2017-10-30 07:19:36 -0400, Paul Wouters wrote:
Just to be clear. DNSSEC provides authentication of data. TLS provides
privacy of data. Both are needed so I am against this proposed change
to remove DNSSEC validation as a requirement. DNSSEC is part of the
core DNS. It's not a cherry.

I'm not claiming that no clients should implement DNSSEC validation.  I
would be happy if every client did so.  Please don't mistake this as a
generic judgement on DNSSEC.  It's about one particular situation where
hard-fail is a bad idea.

In particular, the situation under discussion is what clients should do
in the event of a DNSSEC validation failure of an opportunistic
"meta-query".  As a reminder, the "opportunistic meta-query" is the
best-effort lookup of the IP address(es) of the preferred DNS privacy
resolver, under either Strict or Opportunistic profiles.

In either profile, the meta-query itself is opportunistic -- it's an
attempt to find some channel to the preferred resolver.  But let's look
at the two profiles separately:

a) under the opportunistic profile, dropping the response to an
   opportunistic meta-query in the event of a DNSSEC validation failure
   transforms a loss of privacy into a DoS.  This does not meet the
   stated goal of the opportunistic profile, "maximum chance of DNS
   service".

b) under the strict profile, dropping the response to an opportunistic
   meta-query in the event of a DNSSEC validation failure will result
   in the same outcome (DoS) where the response to the meta-query comes
   from an attacker, because the attacker couldn't have provided a
   valid TLS endpoint in the first place.  But in the scenario where
   DNSSEC either isn't available, or is misconfigured, it converts a
   successful connection attempt into a DoS.  This is a net loss for
   the user.

Put more simply:

   Opportunistic meta-queries are opportunistic.

Encouraging or requiring hard-fail to DNSSEC validation of an
opportunistic meta-query just amounts to a reduction of service, and
provides no security or privacy improvements that i can see.

If the goal is to enforce corroborative authentication of the DNS
privacy server (e.g. via both DNSSEC and the X.509 cartel), i welcome a
writeup of a "Extra Strict" profile that adds a DNSSEC validation
requirement to the Strict profile.  But that's not this draft.

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://mailarchive.ietf.org/arch/browse/dns-privacy/attachments/20171030/5b0072ba/attachment.asc>

------------------------------

Message: 4
Date: Mon, 30 Oct 2017 13:09:39 +0000
From: Stephen Farrell <[e-mail]<mailto:[e-mail]>>
To: Daniel Kahn Gillmor <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]>
Subject: Re: [dns-privacy] review of
   draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC
   validation requirement
Message-ID: <[e-mail]<mailto:[e-mail]>>
Content-Type: text/plain; charset="utf-8"


Hiya,

On 28/10/17 04:40, Daniel Kahn Gillmor wrote:

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 just re-read the draft.

I agree that requiring DNSSEC validation of anything to
succeed when using the opportunistic profile is a bad
plan.

Requiring an attempt at DNSSEC validation is fine, but
given only a small percentage of the DNS is signed, and
DPRIVE won't IMO drive that to a much bigger figure, (or
at least not for a long time) it makes no sense to put
such a barrier in the way of use of opportunistic security.

Cheers,
S.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <https://mailarchive.ietf.org/arch/browse/dns-privacy/attachments/20171030/c43666ae/attachment.asc>

------------------------------

Message: 5
Date: Mon, 30 Oct 2017 13:11:41 +0000
From: Sara Dickinson <[e-mail]<mailto:[e-mail]>>
To: Daniel Kahn Gillmor <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [dns-privacy] review of
   draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC
   validation requirement
Message-ID: <[e-mail]<mailto:[e-mail]>>
Content-Type: text/plain; charset="utf-8"


On 28 Oct 2017, at 04:40, 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.

Hi dkg,

Thanks for the feedback, I agree with the bulk of your analysis with the exception of one part (see below). Therefore I?d argue not to revert the changes to section 7.2 completely since I really do think a description there of the trade-offs of DNSSEC validation are warranted regardless of the final decision on the requirement, even if it ends up just being a MAY (although I would like to see SHOULD as a minimum for opportunistic).

I can also recognise the implementation overhead, however this is required for only one of the 3 cases of how the client may be provisioned:

* IP address only (no meta-query required)

* IP address and ADN (no meta-query required)

* ADN only (meta-query required)

So it is for the case where a client was directly and securely configured with just the ADN of a server it expects to provide privacy. If a client doesn?t want to implement DNSSEC then it can always restrict the opportunistic profile to requiring one of the first 2 configurations.



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),

Agreed - DNSSEC validation just provides earlier detection for Strict clients

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.

I?d disagree that connecting to a server for which the meta-query response failed DNSSEC validation results in _just_ a loss of privacy for Opportunistic in this case. If the answer was BOGUS then it seems reasonable to assume the server is not legitimate and so connecting also results in the clients' entire DNS service being controlled by the attacker.

Take the case where the DNS server from DHCP really is legitimate. The fact that the meta-query answer _could_ be spoofed provides a vector for an opportunistic client to be directed to an attackers' DNS server. Note that this attack is not possible on a ?normal? client that directly uses the DHCP provided server, the attacker has to attack each individual query. My concern here is that without DNSSEC validation of the re-direct Opportunistic clients have an additional risk of this kind of attack than ?normal? ones.

Also this is only a guaranteed DoS for the case where there is only a single server configured. If there are multiple servers then the attacker must spoof the meta-query answers for _all_ the servers to achieve DoS. If it only spoofs one then the client can still get service.

So one way to look at the trade-off seems to be is it worse that an attacker can block your DNS service or gets an extra chance to control all your DNS answers? I think you are arguing that for opportunistic the latter is preferable because a principle of Opportunistic is that it shouldn?t fail? If the WG decided that to be the case then it needs to be clear in the document this choice comes with an additional risk (and yet still not guarantee of privacy).


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



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

Technically his DISCUSS was on a different topic (SPKI handling) as Stephane pointed out, this was an issue that came out of a separate comment he made.

Sara.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <https://mailarchive.ietf.org/arch/browse/dns-privacy/attachments/20171030/68d89dc6/attachment.asc>

------------------------------

Subject: Digest Footer

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


------------------------------

End of dns-privacy Digest, Vol 44, Issue 12
*******************************************