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
