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

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 27 Oct 2017 23:40:15 -0400

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

---

From: Ben Schwartz <[email-masked]>
Date: Sat, 28 Oct 2017 12:03:36 -0400

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 <[email-masked]
> wrote:

> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
>

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 30 Oct 2017 09:09:40 +0000

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

-Tiru

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

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 <[email-masked]<mailto:[email-masked]>> wrote:
Hey DPRIVE folks--

Summary
-------

Analysis
--------

Have i got that right?

Background
----------

 * Strict

 * Opportunistic

         --dkg

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

---

From: Paul Wouters <[email-masked]>
Date: Mon, 30 Oct 2017 13:21:27 +0400

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

What active attacks is DNSSEC vulnerable to?

And how does that not affect TLS?

Paul

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

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 30 Oct 2017 11:02:14 +0000

An active attacker can drop DNS messages with DNSSEC records, set the CD bit in the DNS query, AD bit in the DNS response (see https://tools.ietf.org/html/rfc4035#section-7), clear the DNSSEC OK bit in the DNS query or strip the DNSSEC data from the DNS response to disable DNSSEC (Section https://tools.ietf.org/html/rfc3225).

DNSSEC cannot be mandated for opportunistic profile.

-Tiru

From: Paul Wouters [mailto:[email-masked]]
Sent: Monday, October 30, 2017 2:51 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>
Cc: Ben Schwartz <[email-masked]>; Daniel Kahn Gillmor <[email-masked]>; [email-masked]
Subject: Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement

On Oct 30, 2017, at 13:09, Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>> wrote:

Paul

-Tiru

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

Summary
-------

Analysis
--------

Have i got that right?

Background
----------

 * Strict

 * Opportunistic

         --dkg

---

From: Paul Wouters <[email-masked]>
Date: Mon, 30 Oct 2017 07:17:19 -0400 (EDT)

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

---

From: Paul Wouters <[email-masked]>
Date: Mon, 30 Oct 2017 07:19:36 -0400 (EDT)

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

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 30 Oct 2017 13:31:04 +0100

> 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

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 30 Oct 2017 13:09:39 +0000

Hiya,

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

---

From: Sara Dickinson <[email-masked]>
Date: Mon, 30 Oct 2017 13:11:41 +0000

> On 28 Oct 2017, at 04:40, Daniel Kahn Gillmor <[email-masked]> wrote:
> 
> Hey DPRIVE folks--
> 
> (i.e., "maximum chance of DNS service”).
> 

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.

> strict clients (no mitigation),

Agreed - DNSSEC validation just provides earlier detection for Strict clients

> and *strictly worse* for opportunistic

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

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

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 30 Oct 2017 14:34:03 +0100

On Fri, Oct 27, 2017 at 11:40:15PM -0400,
 Daniel Kahn Gillmor <[email-masked]> wrote 

> against an active attacker in the context of an opportunistic

I see the point but it seems to me a small detail in a 29-pages
document. So, IMHO, it should not cause yet another long delay for a
draft that already lingered too much.

> But i think the other changes between draft-10 and draft-11 are
> unwarranted and should be reverted.

There are very few changes and, except the DNSSEC *requirment*, they
seem good to me. I agree with Sara "I really do think a description
there of the trade-offs of DNSSEC validation are warranted".

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 30 Oct 2017 07:46:43 -0700

On 30 Oct 2017, at 6:11, Sara Dickinson wrote:

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

There are many ways to get a BOGUS response that have nothing to do with 
the information being "not legitimate". Typically today, BOGUS comes 
from misconfigured servers such as expired keys, some nameservers out of 
sync, and so on.

You cannot infer from a BOGUS response about why it is bogus.

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

Spoofing in normal DHCP and spoofing without DNSSEC seem equivalent to 
me.

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

...unless the attacker can spoof the (typically) two servers that the 
client has addresses to.

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

It is only an "additional risk" for a very limited attacker who can only 
attack one of a set of addresses.

If the WG wants to go down the path of making Opportunistic encryption 
even more difficult in order to feel that we offered the best security, 
requiring DNSSEC on the client is a good way to do that. I would still 
prefer more ubiquitous encryption.

--Paul Hoffman

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 30 Oct 2017 16:08:35 +0100

On Mon 2017-10-30 13:11:41 +0000, Sara Dickinson wrote:
> I really do think a description there of the trade-offs of DNSSEC
> validation are warranted

I agree that a discussion of the tradeoffs involved in DNSSEC validation
of the opportunistic meta-query is warranted.  I just come to a
different conclusion than the requirements in draft-11.

> if it ends up just being a MAY (although I would like to see SHOULD as
> a minimum for opportunistic).

SHOULD validate, but with what failure mode?  are we really saying that
opportunistic SHOULD deliver a DoS instead of a loss of privacy?  I
discuss a few optional responses for failures in opportunistic mode
below.

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

The cheapest and simplest implementation in terms of user experience to
get to verifiable opportunistic profile (that is, a profile that can at
least report that DNS privacy has been achieved, even if it won't be
enforced) seems to be:

  * allow the local administrator to provide a name for the preferred
    DNS resolver

Since it's opportunistic, it can even be enabled by default.

But this is the "ADN only" use case.  Saying it's not usable with the
opportunistic profile without DNSSEC validation would be a shame.

> Agreed - DNSSEC validation just provides earlier detection for Strict clients

or, converts success to failure in the case of DNSSEC misconfiguration
(because the connection would otherwise have succeeded) :(

> also results in the clients' entire DNS service being controlled by

sure, but this is the case for non-private DNS as well, right?  So the
mitigation in this case is with respect to the features that "private
DNS" is supposed to offer.  Whatever those features are, they are absent
given an attacker-controlled DNS resolver.  So if the DNS-over-TLS
server is intended to also provide integrity protection, yes, that would
also be lost.  I think we're agreeing here, right?  I apologize if "loss
of privacy" is a misleading shorthand.

> risk of this kind of attack than ’normal’ ones.

ok, i think i understand.  The concern is that a non-network-controlling
attacker who can spoof DNS responses but can't spoof DHCP responses can
now take over full DNS resolution of opportunistic clients just by
racing (and winning) the legitimate metaquery response.

This is true, but the threat model we're worrying now include all of the
following characteristics:

 * attacker does not control the client's network (otherwise, they could
   redirect the port 853 queries anyway)
 
 * attacker cannot (or has failed to) race the client's DHCP connection
   (otherwise, they'd point to a different DNS server anyway)

 * attacker *can* race the legitimate response to the client's
   opportunistic metaquery.

 * client is in opportunistic mode.

So the question is, in this particular corner case, what is the right
mitigation to the scenario where "if DNSSEC validation of the
opportunistic metaquery fails…" ?

if the answer is "…proceed as though it had not failed (trying to
connect to the preferred server's proposed address), but continue
listening for another response to the metaquery; prefer subsequent
metaquery responses that do have DNSSEC validation over those responses
that are not DNSSEC validated." Then i'd be ok with it, but it's not
specified in the draft.

If the answer is "…hard-fail and deny DNS service", then i think that's
incorrect given the goals of opportunistic mode.

If the answer is "…stop trying to use opportunistic DNS privacy
entirely, but fall back to using the DHCP-provided resolver for all
queries" then i think that's a mistake -- we've already demonstrated
that we're in a scenario where the attacker can race the DHCP-provided
resolver and win.  So what do we gain by making this the failure mode?

> achieve DoS. If it only spoofs one then the client can still get

I think this equivalent to my responses-to-failed-validation #2 --
retrying the opportunistic metaquery.  (also, equivalent to "…but
continue listening…" in the paragraphs above.) I agree that's an
interesting case, but i think it's an additional complexity as yet
unspecified in the draft.  :(

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

it is "an extra chance only" in the scenario where points outlined above
hold.  An attacker who can also race and beat the DHCP server has the
exact same chance already, right?

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

Hm, sorry, i'll try to follow up on that in the other sub-thread.

Thanks for the discussion.

    --dkg

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 30 Oct 2017 08:42:18 -0700

On 30 Oct 2017, at 8:08, Daniel Kahn Gillmor wrote:

> SHOULD validate, but with what failure mode?

+1 to the question: we're talking about Opportunistic mode here.

> are we really saying that
> opportunistic SHOULD deliver a DoS instead of a loss of privacy?

Some of us are most emphatically not saying that.

. . .

> incorrect given the goals of opportunistic mode.

Agree. And fully agree that an attacker who can do the third bullet *but 
not the second* is a very obscure corner case.

Having this document say, in essence, "you don't get opportunistic 
encryption unless you add a DNSSEC validation stack" feels like a 
regression to the original goals of this WG.

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 30 Oct 2017 15:59:21 +0000

Hiya,

> regression to the original goals of this WG.

I'm not sure that having a stack is such a barrier in reality.
Requiring that some DNSSEC signatures validate in order to win
the opportunistic game is the problem I think.

I'd personally be fine with a "MUST try DNSSEC" statement, though
that could be argued to be OTT, given the probability of success,
but as DKG and you (and I) agree, it's the failure mode that needs
fixing in the draft.

S.

---

From: Sara Dickinson <[email-masked]>
Date: Mon, 30 Oct 2017 16:11:57 +0000

> On 30 Oct 2017, at 15:08, Daniel Kahn Gillmor <[email-masked]> wrote:
> 

Can we separate out Opportunistic Privacy from Opportunistic DNSSEC (which I don’t think is really a thing, apart from a logging mechanism)? They are orthogonal.

Because if not…. are you saying that a fully validating stub using Opportunistic privacy mode shouldn’t DNSSEC validation anything, ever? Or it can validate all answers except the one for it’s DNS resolver? :-)

> (because the connection would otherwise have succeeded) :(

Ok, but … If the DNSSEC is misconfigured for a privacy server then DANE authentication won’t work either…

> exact same chance already, right?

I don’t buy the ‘if DHCP is already vulnerable we shouldn’t worry about securing the meta-query’ argument. I'd like to think we are designing Opportunistic such that the meta-query is at least as secure as whatever mechanism is or might be used in future to obtain the default DNS server so that opportunistic is no weaker than ’no privacy’.

I hear the case that requiring DNSSEC validation could block deployment for the specific case of ADN only + Opportunistic. So ti sounds like it boils down to two alternatives in section 7.2:

“ Such records SHOULD be validated when using Opportunistic Privacy.”

“ Such records MAY be validated when using Opportunistic Privacy.”

I’d obviously favour SHOULD.

Sara

---

From: Paul Wouters <[email-masked]>
Date: Mon, 30 Oct 2017 16:04:51 -0400 (EDT)

On Mon, 30 Oct 2017, Daniel Kahn Gillmor wrote:

> Date: Mon, 30 Oct 2017 11:08:35
> From: Daniel Kahn Gillmor <[email-masked]>
> Cc: [email-masked]
> To: Sara Dickinson <[email-masked]>
> Subject: Re: [dns-privacy] review of

If a client allows multiple type of profiles, then DNSSEC might not be
needed to reach a pre-configured Strict profile with a trust anchor.
Then the decision to be made is, if that Strict profile is unavailable,
does that make the current network hostile enough to not use it? And if
no strict profile is configured, well then anyting is better then
nothing.

> discuss a few optional responses for failures in opportunistic mode

If talking about the meta query, see above. If talking about DNSESC
validation for the actual content queries, I think it should be
considered that anything not properly supporting DNSSEC is an active
attack against the user, and I would be okay with a hard fail.

> least report that DNS privacy has been achieved, even if it won't be

I thought "opportunistic" meant "do not report to the user" so as to
guarantee that the user is still thinking they are in the realm of "not
private" even if there is encryption happening, because without a trust
anchor, the user cannot know if this opportunistic party is privacy
preserving?

> (because the connection would otherwise have succeeded) :(

A dnssec failure is no different then a certificate failure, and
browsers are now doing something really close to hard fail on those now.

>> also results in the clients' entire DNS service being controlled by

I guess I see two different opportunistic cases. One where you find
a DNS server, get to an IP and/or public key, use DNSSEC to confirm the
key/name in the public real DNS (via that server) and protected with
DNSSEC. For instance, a coffeeshop chain could do so, and if it links to
say publicdns.starbucks.com then you have some confidence then the local
instance of the coffeeshop cannot see your traffic. And then there is
the opportunistic case where you simply will never find out the
identity, and where you just assume the provider could be the attaker.

I feel those two user cases are different. The first one, I could decide
not to use my local starbucks when it starts to fail using the chain's
configured DNS server. The second case I know I'm giving my privacy to
someone who could be malicious, but I still prefer that over not using
their DNS. (although in practise, my guess is as soon as google DNS
supports TLS, everyone will have at least one Strict profile with their
key and never use an opportunistic profile.

> racing (and winning) the legitimate metaquery response.

I think that's really rare now. Most "shared wifi" solutions constrain the
clients and prevent them from talking to each other. In the coffeeshop
the customers cannot see my laptop, but the coffeeshop owner can.

Paul

---

From: Sara Dickinson <[email-masked]>
Date: Tue, 31 Oct 2017 15:06:16 +0000

So here is an example of how Stubby works today. It has separate settings for Transports(UDP/TCP/TLS), Usage profile and DNSSEC. The relevant DNSSEC options are:

- dnssec_return_status  - blocks BOGUS answers, returns all others with status information (secure vs insecure vs indeterminate)
- dnssec_return_only_secure   - does what is says on the tin

where ‘dnssec_return_status’ is obviously what we recommend if you want DNSSEC. 

If I have stubby configured like that then connecting to a DNS server with a BOGUS A record just because I’m in opportunistic privacy mode seems questionable. 

So maybe “A DNSSEC validating client SHOULD apply the same validation policy to the A/AAAA meta-query lookup as it does to other queries.”?

Sara.

> On 30 Oct 2017, at 20:04, Paul Wouters <[email-masked]> wrote:
>

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 31 Oct 2017 08:12:45 -0700

On 31 Oct 2017, at 8:06, Sara Dickinson wrote:

> So maybe “A DNSSEC validating client SHOULD apply the same 
> validation policy to the A/AAAA meta-query lookup as it does to other 
> queries.”?

That could be misinterpreted to indicate that there has to be some 
positive validation policy. How about:
    A DNSSEC validating client SHOULD apply the same validation policy
    to the A/AAAA meta-query lookup as it does to other queries.
    A client that does not validate DNSSEC SHOULD apply any policy it
    has to the A/AAAA meta-query lookup.

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 31 Oct 2017 18:39:03 +0000

Hiya,

On 31/10/17 15:12, Paul Hoffman wrote:
>> So maybe “A DNSSEC validating client SHOULD apply the same validation
>> policy to the A/AAAA meta-query lookup as it does to other queries.”?
> 

So I think either of the above could be ok.

The main thing for me is that we do not insist that a server
has to get DNSSEC setup before they can do opportunistic DNS
security. I think the above is ok in that respect.

Just checking: I think that means that with the opportunistic
profile, only servers that have DNSSEC setup and where the
client validates and gets a badly signed response would be
affected, all other cases would still get DNS privacy of some
sort. If that's right, I can live with it.

Cheers,
S.