On Oct 30, 2017, at 13:09, Konda, Tirumaleswar Reddy <tirumaleswarreddy_ko...@mcafee.com> wrote: > > +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 > > -Tiru > > From: dns-privacy [mailto:dns-privacy-boun...@ietf.org] On Behalf Of Ben > Schwartz > Sent: Saturday, October 28, 2017 9:34 PM > To: Daniel Kahn Gillmor <d...@fifthhorseman.net> > Cc: dns-privacy@ietf.org > Subject: Re: [dns-privacy] review of > draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC > validation requirement > > 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 > <d...@fifthhorseman.net> 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 > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy > > > _______________________________________________ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy
_______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
