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

[Ben Schwartz <[e-mail]>]

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]
> 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]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
>