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

[John Heidemann <[e-mail]>]

On Tue, 13 Dec 2016 15:46:25 +0100, Shane Kerr wrote: 
>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?

You're correct that connections are less sticky from recursive-to-auth,
and so persistent connections and fast open are less helpful.  From the
server's perspective, they are still helpful---we see about 90%
connection reuse in replays of root-server traffic with a 30s connection
timeout (see figure 2c in http://www.isi.edu/~johnh/PAPERS/Zhu16b.pdf ).

But the set of clients seen by a root is somewhat
skewed by the number of bogus clients.  From the *client* perspective,
we see less connection reuse from recursive-to-auth: only about 25% with
a 30s connection timeout (figure 8 in the paper).

The other real cost is in memory for state (memory that is in both TCP
and TLS, so DTLS doesn't make it go away).  Memory at auths is much
higher if all traffic is TCP, but well within the reach of current
servers.  Our estimate was about 4GB of connection state at a root with
a 30s timeout window.

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

It seems unlikely that there would be significant benefit from DTLS.
The only thing DTLS saves is the SYN / SYN-ACK RTT,
otherwise it runs the same TLS handshake.  The SYN / SYN-ACK RTT can also be
avoided with TCP fast open, if you get a cache hit.
The main place where DTLS wins is not performance, but in allowing out-of-order
packet processing once the connection is setup.
(If you drop a query packet after handshae, you don't need to recover it
before processing later ones).

Our experiments with TCP fastopen and persistent TLS are basically the
same performance as UDP when you get a cache hit (compare bars e and f
vs. bar a for Figure 6 in that paper).  So the main performance question
is: how often do you find an already open connection.




>
>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? ;)

Can you please clarify, what is the problem IPsec or novel crypto is
trying to solve?

   -John Heidemann