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

[Paul Wouters <[e-mail]>]

On Mon, 30 Oct 2017, Daniel Kahn Gillmor wrote:

> Date: Mon, 30 Oct 2017 11:08:35
> From: Daniel Kahn Gillmor <[e-mail]>
> Cc: [e-mail]
> To: Sara Dickinson <[e-mail]>
> 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