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

[Paul Wouters <[e-mail]>]

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.

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

Paul