Re: [dns-privacy] [Step 2] More discussion needed: state your opinion

[Shane Kerr <[e-mail]>]

Stephane,

At 2016-12-13 11:59:36 +0100
Stephane Bortzmeyer <[e-mail]> wrote:

> In the minutes of the Seoul meeting, we see:
> 
> Strong hum for sticking around to work on this.
> Terry (as AD): more mailing list discussion, please
> 
> So, this email is to request this
> discussion. draft-bortzmeyer-dprive-step-2-04 is published, with all
> the remarks from the Seoul meeting integrated. Now, it is time to give
> an advice on things like:
> 
> 1) Use TLS for the resolver-to-auth link, or not?

I think that TLS may be more painful in the resolver-to-auth case, as
TCP Fast Open will be generally less useful, right?

But what are the other alternatives?

DTLS is mentioned in the draft. Do we have any benchmarks or
simulations as to the expected relative benefits of DTLS vs. TLS for
DNS?

IIRC the idea of using IPsec was also discussed somewhere. IIRC, IPsec
may have problems traversing NAT. It is also usually implemented by the
kernel, which may cause deployment issues. I *want* IPsec to be an
option here, but realistically I don't think it is.

The other alternative is to invent some novel crypto (fun but
ill-advised) or steal some equivalent (like the crypto part of
DNScurve, also mentioned in the draft). After TSIG, DNSSEC, DNS
cookies, and the rest, it would be weird if DNS used something
standard, but maybe we can try it for once? ;)

> 2) Which authentication(s) to use?

I really like the CGA approach, but realistically I don't think that
would be accepted. If we think that it would be, then I'm all for it.

----

Otherwise I think we should lean towards putting authentication tokens
in the DNS itself.

AIUI the draft, if we want to use DNS the problem is that we want to
know how to encrypt a session to a name server, but we can't look up
anything about the name server in the DNS because we don't yet know how
to encrypt a session to the name server.

Is it possible to tie the authentication to the domain instead of the
name server?

We could say sessions looking up EXAMPLE.COM use certificate 1234,
regardless of which name server they are talking to.

If we could do this, then we could even publish certificate 1234 in a DS
record, and then it would be returned by the parent. (We can use a new
type for this, which is more elegant but requires server modification
and protocol changes.)

There are several advantages of this:

* no bootstrapping issues

* no modification to existing software needed for parents

* an observer/attacker cannot know that a resolver is going to use an
  encrypted session unless they observe the actual session between the
  resolver and authoritative server (which is unavoidable)

Also some disadvantages:

* a single authoritative server may have to configure thousands of
  certificates (although of course this is less of a problem for
  hosters that are the masters of the zones, as they can share
  certificates between zones)

* keys must be shared across administrative boundaries (that is, if I
  use Dyn and FreeDNS for hosting, then both hosters can impersonate
  the other or decrypt traffic to the other)

* resolvers can't just store certificates with the name server
  information

* could be interpreted as another layer of indirection in the DNS ;)

Cheers,

--
Shane