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

[Stephane Bortzmeyer <[e-mail]>]

On Tue, Dec 13, 2016 at 03:46:25PM +0100,
 Shane Kerr <[e-mail]> wrote 
 a message of 120 lines which said:

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

Same thing (even worse) for persistent TCP connections.

But the problem is made less serious by the huge concentration of
authoritative name servers (this concentration is a bad thing, but it
helps for clients who maintain per-server state, which would be the
case with TCP Fast Open). Among the Alexa top 100k, only 24 k servers
<https://blog.imirhil.fr/2015/02/18/vie-privee-dns.html>

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

Eric Rescorla talked about it at the London BoF
<https://www.ietf.org/proceedings/89/slides/slides-89-dnse-5.pdf>

> The other alternative is to invent some novel crypto (fun but
> ill-advised)

This was the opinion defended by Mukund Sivaraman at the Seoul
meeting, and this is why draft-krecicki-dprive-dnsenc is mentioned in
my draft (there is also draft-wijngaards-dnsop-confidentialdns).

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

I disagree. We can look up without keys. It just has to be without
privacy. See for instance the discussion on
draft-ietf-dprive-dtls-and-tls-profiles, specially
<https://mailarchive.ietf.org/arch/msg/dns-privacy/U9bGDAOReP_zYc4tPZY4AdWc2eM>

> * 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)

This is for me a stopper.