Subject: [dns-privacy] tcpinc ?

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 2 Mar 2015 12:13:36 +0100

There never was a mention of this working group here, so here it is:
"tcpinc" tries to encrypt all TCP flows, without caring (too much)
about authentication.

https://datatracker.ietf.org/wg/tcpinc/

Together with RFC 5966, could it be a "lightweight" solution for DNS
encryption?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 2 Mar 2015 07:49:08 -0500

> Together with RFC 5966, could it be a "lightweight" solution for DNS

The objective of TCPINC is to provide best effort privacy. We are chartered
to provide privacy. That does not look like a good match.

Having long experience of trying to persuade browser providers to do OCSP
with TLS, I do not see any possibility that DNS over TCP is going to be
acceptable to them.

I don't care how many graphs are presented showing that TCP is as fast
under lab conditions or with a specific stack or with new extensions etc. I
would not be convinced and I see no reason why Google is going to be.
Reducing the time to load of the first page is a really big deal for the
Chrome team.

So when people are saying 'DNS over TCP isn't a major overhead' what the
Chrome team are probably hearing is 'giving up half your annual bonus to do
privacy our way shouldn't be a problem'.

I don't think the other big five browser providers are any different. They
don't compete on security. Security has never been a priority or we would
have done this twenty years ago.

The aim here is to write a spec that gets used. Taking short cuts to safe
ourselves some dev time is a false economy. The real challenge is
deployment.

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 2 Mar 2015 16:00:42 +0200

> privacy our way shouldn't be a problem'.

Are you talking about:

- Overhead of establishing (secured) TCP connection (AFAIK, 2RTT without
  extensions)?
- Bad handling of packet loss by TCP (don't know)?
- Latency increase from increased bandwidth and encryption/decryption
  (AFAICT, on order of 0.1ms or so)?

The hot assoication performance looks acceptable. Are you talking about
cold association performance being important?

Also, the end that bears the burnt of keeping hot associations is the
server end (recursive resolver in case of stub<->recursive), not the
client (stub) end. I have heard of single system image managing to keep
1 million TCP connections at once (that was some time ago, likely
higher now).

I would see the point of using UDP (which means increased complexity):
- If cold case 2RTT is unacceptable.
- If packet loss handling of TCP proves too troublesome.
- If maintaining enough associations is problem for recursive servers.

Using UDP does virtually nothing to extra bandwidth latency.

And finally, if one compares to OCSP:
- OCSP cold-case performance matters much more due to amount of OCSP
  responders involved (to-recursive DNS only has 1 + backup(s) if
  primary fails).
- OCSP makes privacy issues worse, not better (by introducing another
  party).

-Ilari

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 2 Mar 2015 07:46:20 -0800

> Together with RFC 5966, could it be a "lightweight" solution for DNS

Sure, but one that the client will never know about. TCPINC is for environments where the client application will never know that their TCP traffic is encrypted; I assumed that DPRIVE was for when the stub resolver *would* know and could make choices based on that.

From the stub resolver's point of view, TCPINC is no different than running over an IPsec tunnel.

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 2 Mar 2015 11:15:55 -0500

On Mon, Mar 2, 2015 at 9:00 AM, Ilari Liusvaara <[email-masked]

>   (AFAICT, on order of 0.1ms or so)?

All of the above

> cold association performance being important?

As soon as you put an adjective in there, I think you lose them.

The origin of my proposal is that I was trying to reduce the overhead of
doing OCSP checks to an acceptable level because they were refusing to
hardfail on TLS cert status checks. Now DPRIV might be a higher security
priority but I somehow doubt it.

I don't think we have any chance of getting the fish to bite unless we can
show a performance advantage in virtually every case without exception.

> 1 million TCP connections at once (that was some time ago, likely

Again, that is an argument that I think only has weight if it comes from
some party that is going to deploy a highly trafficked recursive.

And I think it is only something that we should even consider if there
isn't any other alternative. We have an alternative and it is just as easy
to implement and guarantees performance at least as good as current DNS for
97% of network circumstances.

> Using UDP does virtually nothing to extra bandwidth latency.

The startup and session maintenance costs are significant.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 2 Mar 2015 11:28:54 -0500

> I would see the point of using UDP (which means increased complexity):

No it does not.

UDP is a lot simpler than any of the TCP proposals.

* Fewer states
* Smaller library
* Fewer options

TLS is a big complicated specification and the open source libraries are in
a woeful state. Take a look at the date the tutorial on the OpenSSL API was
written.

The expeditious approach to setting up a client-service binding is to
leverage TLS. But that is separate from the DNS session transport question
and something that can be revisited later.

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 2 Mar 2015 19:16:07 +0200

> UDP is a lot simpler than any of the TCP proposals.

- TCP orders the packets
- TCP retransmits
- TCP does error correction.
- TCP deals with reflection.

Sure, one can do all the above with UDP-based protocols, but that means
extra code.

DNS requires TCP already (as fallback for when packet limits get busted).

> a woeful state. Take a look at the date the tutorial on the OpenSSL API was

There is UDP counterpart to TLS called DTLS. It is more complicated than
TLS (due to above factors).

> and something that can be revisited later.

I think (D)TLS is too complicated for stub<->recursive protocol (even if
profiled down).

Also, can't deal with fast session startup until TLS 1.3 (which is still
quite complex and doesn't look even near finished, let alone DTLS 1.3).
Plus the scope of present challenge looks much smaller than TLS (e.g. no
client authentication, server recon is feasible, etc...).

Of course, designing a new crypto protocol is pretty scary prospect
(I have seen one that has even simpler scope and looks totally messed
up).

-Ilari