Subject: [dns-privacy] DNS over TLS

From: Stuart Cheshire <[email-masked]>
Date: Tue, 11 Nov 2014 16:45:53 -0800

I’m unable to attend the DPRIVE meeting in person because it overlaps with TAPS.

I see on the agenda discussion of items like Private DNS and DNS over TLS.

A historical note: Apple’s Back to My Mac service uses DNS over TLS to provide confidentiality for the queries. This is described in RFC 6281.

The client looks up the SRV record “_dns-query-tls._tcp.example.com” to find the target host and port which will answer DNS-over-TLS queries for the domain “example.com”, and then the client sends subsequent queries for “example.com” names directly there (bypassing the local DNS cache).

Stuart Cheshire

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 13 Nov 2014 10:24:13 -1000

I see two distinct use cases:

1) Web browsing
2) Everything else.

The challenges for (1) are latency, latency and latency.

Shaving 10ms off the response of a browser is very important to the
Web browser team. Folk can argue that it should not be, but that is
the situation.

If we are going to do DNS over TLS then looking at the existing Back
to my MAC protocol makes sense. But the caveat is that does not look
like an application where ultra-low latency is a requirement.

There are two ways to address the latency issue for Web browsing:

1) Design a protocol tuned for ultra low latency with 1 round trip over UDP.
2) Combine the DNS requests with other data requests that the browser
would make.

Private-DNS takes approach 1
OmniQuery takes approach 1 and 2

Once you decide to combine data feeds, you have changed the protocol
anyway and might as well tune for performance.

On Tue, Nov 11, 2014 at 2:45 PM, Stuart Cheshire <[email-masked]> wrote:
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: Paul Wouters <[email-masked]>
Date: Thu, 13 Nov 2014 15:26:11 -0500 (EST)

> The client looks up the SRV record “_dns-query-tls._tcp.example.com” to find the target host and port which will answer DNS-over-TLS queries for the domain “example.com”, and then the client sends…

Thanks for the pointer. I was not aware of this.

I skimmed the RFC but it does not state on which port the DNS over TLS
happens. Is it on port 53 or port 443 or another port?

Paul

---

From: Joshua Smith <[email-masked]>
Date: Thu, 13 Nov 2014 15:29:59 -0500

> Web browser team. Folk can argue that it should not be, but that is

Perhaps this is a case where anyone wishing to make use of the
additional privacy/security features provided from using DNS over TLS
will need to accept the trade off that the addition comes at a
performance cost?

Especially if you consider the case where your local (stub?) resolver
caches the responses I would imagine that after the first few minutes of
browsing, once the cache is reasonably populated, that the overall
performance impact of the changes will approach nil.

-- 
Joshua Smith
Lead Systems Administrator WVNET

Montani Semper Liberi

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 13 Nov 2014 10:48:32 -1000

> will need to accept the trade off that the addition comes at a

No, there is a proposal that meets the performance criteria.

I see no reason to force users to choose between security and
performance when the simplest, best proposal provides both. Do you?

> performance impact of the changes will approach nil.

That would be an incorrect assumption. Talk to the Chrome team.

---

From: Joshua Smith <[email-masked]>
Date: Thu, 13 Nov 2014 16:06:33 -0500

> performance when the simplest, best proposal provides both. Do you?

Agreed.

> That would be an incorrect assumption. Talk to the Chrome team.

This is definitely an area I'll have to do more research on.

Montani Semper Liberi

---

From: Stuart Cheshire <[email-masked]>
Date: Thu, 13 Nov 2014 14:25:09 -0800

> happens. Is it on port 53 or port 443 or another port?

There is no fixed port. It uses whatever port you choose, and the client looks up the SRV record “_dns-query-tls._tcp.example.com” to find that information. The LLQ server machine can even be a “hidden secondary” in the sense that it’s not listed in any NS record.

I’m not suggesting that DNS-over-TLS-over-TCP is the solution for DNS Privacy. I was only pointing it out so that people discussing DNS-over-TLS-over-TCP would be aware of this existing deployment. If you use Back to My Mac, you’re using DNS-over-TLS-over-TCP.

Stuart Cheshire

---

From: 🔓Dan Wing <[email-masked]>
Date: Tue, 18 Nov 2014 21:43:01 -1000

> Private-DNS takes approach 1

(D)TLS 1.3 takes approach 1 with TLS 1.3, which is optimizing for 0 round trip (for servers previously used) or 1 round trip (for new servers).

-d

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 19 Nov 2014 09:05:19 -0500

> (D)TLS 1.3 takes approach 1 with TLS 1.3, which is optimizing for 0 round trip (for servers previously used) or 1 round trip (for new servers).

If its 1 round trip then we are talking about DTLS not TLS.

The thing I didn't like about using DTLS is that I have to profile
pretty severely to make the code footprint minimal. And once you
profile you have to rewrite libraries to only use the profile
features.

TLS has a stateless session resumption option but it would need to be
mandatory for DNS over TLS to be viable. And it would have to be
possible to set decent sized timeouts for the negotiated sessions.

On the performance side, PRIVATE-DNS is providing better performance
for the typical approach of doing an A and a AAAA record lookup in
parallel since these are typically handled in one request/response
packet rather than two.

---

From: 🔓Dan Wing <[email-masked]>
Date: Wed, 19 Nov 2014 07:08:41 -1000

> profile you have to rewrite libraries to only use the profile

Umkay.  It is good you have personally concluded that a completely new library and new protocol is better than profiling DTLS, but I don't yet share that conclusion.

> possible to set decent sized timeouts for the negotiated sessions.

Acknowledged.  However, that requirement for how long to retain 0-RTT capability is not unique to DTLS's session resumption.

> parallel since these are typically handled in one request/response

If also SRV and arbitrary other resource records invented in the future, that sounds compelling.

-d

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 19 Nov 2014 09:13:06 -0800

Given that the problem statement for the group is stub-to-resolver, and a stub generally uses one resolver, it is quite believable that one would have a TCP connection open to the resolver that is reused for future DNS queries. After the initial TCP connection to the resolver (which is normally done before the first web page request), the speed of the request is the same for an open TCP connection as it is for a new UDP "connection".

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 19 Nov 2014 13:40:35 -0500

> Umkay.  It is good you have personally concluded that a completely new library and new protocol is better than profiling DTLS, but I don't yet share that conclusion.

I don't think it is helpful to thing in terms of the number of
libraries or protocols involved. I would rather add a new library of
10K code than grow an existing library from 200Kb to 300Kb.

I am really not writing a whole new protocol here. What I am doing is
decoupling the key negotiation part of TLS from the framing part by
introducing a small amount of JSON.

> If also SRV and arbitrary other resource records invented in the future, that sounds compelling.

SRV, TLSA, plus new security policy records to be defined all with DNSSEC.

So lets say you want to connect to www.example.com via HTTP, the DNS
queries might be:

www.example.com ? A
www.example.com ? AAAA
_80._tcp.www.example.com ? TSLA
_http._tcp.www.example.com ? SRV
_http._tcp.www.example.com ? ESRV  (A security policy record TBS)

Note that while the existing DNS protocol supports multiple queries in
theory, it does not support multiple response codes which makes it
pretty useless.

So the above would be five separate DNS protocol messages all framed
in a single UDP packet.

In most cases the results will fit in a single packet as well.

Taking away the performance penalty for multiple record lookups would
make a huge difference to the viability of proposals to extend DNS
discovery services.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 19 Nov 2014 13:43:40 -0500

> Given that the problem statement for the group is stub-to-resolver, and a stub generally uses one resolver, it is quite believable that one would have a TCP connection open to the resolver that is…

That becomes very problematic when running a big public DNS server.
Basically it would require every client to keep a TCP connection open
permanently. That is a huge load. I have 40 computers with IP in this
house that are used regularly. My network traces are clogged enough
without TCP keepalive packets.

---

From: "Mankin, Allison" <[email-masked]>
Date: Wed, 19 Nov 2014 22:33:14 +0000

We quantified this in measurement/modeling studies joint with USC/ISI - TCP connections from stub to recursive need to be held open only on the order of 20 seconds at at time in order to have high reuse rates.  One of the measurement sets we used in the study is the DITL set from Level3’s big public DNS server, and these numbers held up.  And TCP TFO (almost RFC) and TLS Resume add to the optimizations beyond that.  Phillip, what you wrote is extremely oversimplified.

Please see Section 3, Performance Considerations, in draft-hzhwm-dprive-start-tls-for-dns-00.txt.  Some of the numbers are in the presentation John Heidemann and Sara Dickinson gave in DPRIVE. Extensive numbers and full methodology are in a tech report referenced by both:  ftp://ftp.isi.edu/isi-pubs/tr-688.pdf

In addition, I think we're unwise to be debating between mechanisms anyway. Different providers and different end-sites will have different deployment and operational circumstances.  A small selection of tools with diverse deployment and operations characteristics are likely to all be used.

Allison

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 19 Nov 2014 19:29:57 -0500

> We quantified this in measurement/modeling studies joint with USC/ISI - TCP connections from stub to recursive need to be held open only on the order of 20 seconds at at time in order to have high…

Can you explain what you think I oversimplified in a simple manner?

I think that you are making things needlessly complex. If you want to
match the traditional DNS latency of one UDP round trip then use a
protocol that uses one UDP round trip.

What interests the browser folk is how much time it takes to download
a page and they split that into the original HTML and the attachments.
Today pages typically contain lots of iFrame elements and CDN hosted
content and so it isn't surprising that DNS lookups tend to be
batched. But you will still incur the cost of the TCP open on the
first lookup.

Sure we can do performance tests, but lets ask the browser folk to set
the criteria.

There is nothing particularly great about TLS framing. And in fact you
have to set a flag to do encryption and authentication in the right
order. Framing is easy, its key exchange that is the hard part.

Rather than trying to work in a straightjacket with the key exchange
welded to one framing, separate the two and allow folk to choose
framing that fits their task. TCP Fast Open looks like a great idea.
But are you seriously suggesting that you can rely on a proposal that
is not an RFC yet to score a performance tradeoff?

The vast majority of platforms in use today are Windows and OSX.
Neither supports TFO right now as far as I can find out from the
Google.

> In addition, I think we're unwise to be debating between mechanisms anyway. Different providers and different end-sites will have different deployment and operational circumstances.  A small select…

Have you looked at SXS-Connect?

It is designed to enable exactly that type of service agility.

---

From: John Heidemann <[email-masked]>
Date: Wed, 19 Nov 2014 17:09:18 -0800

>Please see Section 3, Performance Considerations, in draft-hzhwm-dprive-start-tls-for-dns-00.txt.  Some of the numbers are in the presentation John Heidemann and Sara Dickinson gave in DPRIVE. Exten…

One small addition.  That's an our older tech report, and that link is
now broken.  

The current version is TR-693, at

http://www.isi.edu/publications/trpublic/files/tr-693.pdf

(the old version is now
http://www.isi.edu/publications/trpublic/files/tr-688.pdf
for folks who want to wax nostolgic about where DNS-over-TCP and TLS was
back in Feb. 2014 :-).

   -John

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 19 Nov 2014 20:54:18 -0500

> for folks who want to wax nostolgic about where DNS-over-TCP and TLS was

Referring to table 7 in the report. This is giving average time for a
DNS transaction but as I explained to Alison, the issue for browser
providers is how fast their page loads.

Any chance you could run the numbers and identify the times for the first load?

Even on those numbers, one round trip 62% of the time is not the same
as one round trip 97% of the time.

I do however strongly agree with Alison that we are going to need more
than one protocol because we have to achieve 100% connectivity. And
that means being able to bypass hotel and coffee shop DNS.

That means either DNS over TLS or HTTP with encrypted content (or both).

What I like about DNS over TLS is that we get the ability to use
multiple records. I think that is an important feature.

---

From: Tony Finch <[email-masked]>
Date: Thu, 20 Nov 2014 09:44:01 +0000

> make a huge difference to the viability of proposals to extend DNS

If you already have a TCP connection open to your recursive server then
you can get the same performance with the current DNS protocol.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Lundy, Fastnet: Northeast 4 or 5, veering southeast 5 to 7. Moderate or rough.
Rain later in Fastnet. Moderate or good, occasionally poor at first.