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

[Paul Hoffman <[e-mail]>]

On Aug 20, 2014, at 6:30 AM, Jacob Appelbaum <[e-mail]> wrote:

> On 8/19/14, Paul Hoffman <[e-mail]> wrote:
>> [[ 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.
> 
> I'd switch this to say 'confidentiality' rather than anonymity.
> Anonymity is a much stronger claim which I adore but it seems out of
> place here.

Good catch, yes.

>>>> 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?
> 
> d) Don't do TLS at all, only try cleartext on port 53 (the sad default
> state of the internet today)

Hrm. That is not really a policy choice for *this draft*, but I see your point. I'll add it.

> e) All the other DNS privacy stuff - eg: OpenDNS's encrypted DNS
> stuff, djb's other work, etc.

I can't list a policy that I can't cleanly describe. The OpenDNS folks still haven't produced a stable description of their protocol that I can find; if they have one, I'm happy to list it. DNScurve doesn't work for stub-to-recursive, I don't believe; only recursive-to-authoritative.

>> 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?
> 
> Yes. It is perfectly fine. If it was the default policy when
> configuring a TLS aware resolver unless configured to be *less secure*
> explicitly, certainly so.

The document is not going to list what a default policy should be.

>>>>> 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.
> 
> I like the idea of a notice but I prefer the idea of explicitly
> ensuring that one has configured a privacy DNS resolver - thus - it
> seems the API needs to consider this from the start.

If you want to work on an API, that's great. APIs for security have a long history of bringing down protocols in the IETF, I don't want the API to hold up the protocol. If you get started on it before this document is finished, I'm happy to point to your work-in-progress.

>>> 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.
>> 
> 
> I think a key thing is that we need a way to discover that an already
> configured stub resolver supports this kind of confidentiality. When
> the stub software updates, the resolver that is already configured
> could be upgraded to use the privacy preserving path, for example.

That would take an API. I really don't want to force that into this document, but as I said above, if you or someone wants to tackle the API question, I'm happy to point to it.

--Paul Hoffman