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
signature.asc
Description: PGP signature
_______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy