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

[Sara Dickinson <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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
> 
> _______________________________________________
> dns-privacy mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-privacy