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 protected]> wrote: > > On Mon, 30 Oct 2017, Daniel Kahn Gillmor wrote: > >> Date: Mon, 30 Oct 2017 11:08:35 >> From: Daniel Kahn Gillmor <[email protected]> >> Cc: [email protected] >> To: Sara Dickinson <[email protected]> >> Subject: Re: [dns-privacy] review of >> draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC >> validation requirement >> 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 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. > >>> 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. > > 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. > >> 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: > > 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? > >> or, converts success to failure in the case of DNSSEC misconfiguration >> (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. > >>> 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. > > 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. > >>> 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. >> >> 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. > > 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 > > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
