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

[Sara Dickinson <[e-mail]>]

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