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

[Jacob Appelbaum <[e-mail]>]

On 8/20/14, Paul Hoffman <[e-mail]> wrote:
> 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.
>

Ok. Sounds great - I'm looking forward to reading the updated draft!

>> 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.
>

Really? I'm surprised. I've cc'ed David Ulevitch - perhaps he or
someone at OpenDNS can chime in with something helpful here?

>>> 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.

OK.

Perhaps it would be useful to state assumptions about what a different
policy means?

If a user manually configures a confidential server (and loads the
fingerprint or learns the key with DANE) - it is expected that an
implementation MUST fail closed? I think this is what happens when you
use the OpenDNS resolver with their crypto implementation. I don't
think it falls back to plaintext.

>
>>>>>> 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.

I think you have a compelling point. Let us split the tasks. :)

>
>>>> 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.
>

Hrm - would it? I think that we could just add something like "stub
resolvers SHOULD automatically request the following DANE record
foo.bar.baaz.keys.whatver to learn the key for their encrypted
resolver. Recursive resolvers supporting DNSSEC MUST verify that this
record is correctly signed."

Does it need to be more complicated than that? I mean, we'd need to
agree on the record but I suppose there is a PTR record name that
would fit here, no?

All the best,
Jacob