Re: [dns-privacy] New draft on encrypting the stub-to-resolver link: draft-hoffman-dns-tls-stub-00.txt

[Paul Hoffman <[e-mail]>]

[[ Combined PaulW's and Jacob's responses ]]

On Aug 19, 2014, at 2:01 PM, Paul Wouters <[e-mail]> wrote:

> On Tue, 19 Aug 2014, Paul Hoffman wrote:
> 
>>> I wonder this 'MUST' may be too strong (or I don't fully understand
>>> the sense of this MUST).  Since the upstream recursive resolver may or
>>> may not support the TLS extension, the DNS forwarder may end up giving
>>> up the resolution altogether.  But depending on the stub clients'
>>> policy it may be still better to provide encryption between the stub
>>> and the forwarder.
>> 
>> Good catch. Proposed replacement to handle the case where the recursive resolver doesn't do TLS:
>> 
>> A stub resolver cannot tell whether it is sending queries to a
>> recursive resolver or to a DNS forwarder.  Therefore, a DNS forwarder
>> that acts as a TLS server for DNS requests MUST also attempt to act as a TLS
>> client for queries to its upstream recursive resolvers, but MAY
>> use the normal DNS protocol on port 53 if an upstream recursive
>> resolver does set up a TLS session.
> 
> A resolver at a coffee shop is mostly concerned about protecting the DNS
> in the public wifi, and might not worry at all about its DSL uplink,
> especially when it has no real reason to trust its own uplink. So I
> would just make it very generic:
> 
>  a DNS forwarder that acts as a TLS server for DNS requests SHOULD
>  attempt to use TLS with its upstream resolver(s) to maximize the
>  anonymity of its stub clients.

I'm fine with that as a replacement for my suggestion above.

> 
>> Sure, let's be explicit. Proposed addition to the policy section:
>> 
>> If a recursive resolver does not respond on port 443 or set up a TLS session, the stub resolver MAY use the normal DNS protocol on port 53.
> 
> MAY sounds a little odd here. If there is no preconfiguration for
> authenticating this resolver, I don't think we should advise
> stubs to refuse to do DNS completely, which is what the MAY is
> suggesting as a valid option. (this is breaking the "opportunistic
> security design pattern recommendation advise" :)
> 
> How about:
> 
> 	If a recursive resolver for which an authentication method is
> 	available does not respond on port 443 or fails to set up a TLS
> 	session, the stub resolver SHOULD NOT use that resolver over
> 	unencrypted DNS using port 53. If no authentication method is
> 	available for the recusive resolver, the stub resolver SHOULD
> 	fallback to using cleartext DNS on port 53.

That seems mixed up. I think the policies we want to list are:

a) Must have authenticated TLS, otherwise don't get any DNS responses

b) Try to do authenticated TLS, but use unauthenticated TLS if possible, otherwise don't get any DNS responses

c) Try to do authenticated TLS, but use unauthenticated TLS if possible, but allow cleartext on port 53 if TLS cannot be established

Does this seem like the whole list?


On Aug 19, 2014, at 1:02 PM, Jacob Appelbaum <[e-mail]> wrote:

>>> I'm not a fan of making it possible for an attacker to downgrade with
>>> a single (non-cryptographically protected) TCP RST packet. If I
>>> configure a resolver and declare it to be secure (and use it as such),
>>> why not fail closed?
>> 
>> Because then hosts that use stub resolvers will not be able to use the DNS
>> at all.
> 
> That is correct and that is exactly what I expect when my network is
> attacking me. Rather than leaking that I'm being visited an ad name
> that implies I've visited a gay dating site, I want it to fail closed.
> If I declare it as secure, I want it to remain secure - where the
> security here is all about *confidentiality* and DNSSEC does the rest
> with regard to integrity, etc.

I think that would policy (a) listed above. Does that work for you?

>>> Why not detect that as an attack or as outright
>>> network censorship?
>> 
>> We could add such detection, but only if the value outweighs the complexity
>> and possible failure modes.
> 
> If the TLS connection fails to complete (authenicated or not), it
> should be as simple as returning something like E_CENSORSHIP_DETECTED.

It is reasonable for the policy to suggest that a later API might be able to detect which level of protection, if any, the user has gotten. 

> An error like "Unable to connect securely to resolver, please contact
> your ISP" would be fine.

And you might want to only use applications that use that later API.

> Most OSes don't do anything remotely helpful when DNS fails. It might
> be nice if that failure mode was privacy preserving...

It might be, yes.

>>> This seems to fail if there is an active attacker that blocks TLS
>>> traffic - is there a way for the resolver to somehow learn in-band on
>>> port 53 that this attack is happening?
>> 
>> Probably, but you still haven't said what value there is in knowing that. A
>> stub resolver has no log and no way of alerting anyone that it discovered
>> something important.
> 
> If my resolver allows upgrading to a secure method of communication,
> I'd like to know. Furthermore, I'd like to automatically upgrade to
> that secure communications path if it was available. An OS could probe
> for a specific record type - similar to say, version.txt.
> 
> e.g.: nslookup -q=txt -class=CHAOS query.privacy.bind.
> 
> It could even learn the likely fingerprint of the server ala DANE, for example.

Once we have privacy for all types of stub resolvers, it could certainly be useful for a few people who have security-aware validating stub resolvers to have that information. It is an easy follow-on for those who care about it.

--Paul Hoffman