Subject: [dns-privacy] Updated comparison, Was: DNS over TLS

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 20 Nov 2014 09:10:38 -0500

On Thu, Nov 20, 2014 at 4:44 AM, Tony Finch <[email-masked]> wrote:
> Phillip Hallam-Baker <[email-masked]> wrote:
>>
>> 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)
>>
>> 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.
>
> If you already have a TCP connection open to your recursive server then
> you can get the same performance with the current DNS protocol.

Yes, we established that already. That is the advantage of TLS over DTLS.

The way I would score proposals objectively:

100%: Are connections guaranteed unless under active attack?
MM: Are multiple messages per transaction supported?
1RT: What percentage of transactions are completed in a single round trip?
PDoS: Is the query host required to perform pki processing on
unauthenticated requests?
QDoS: Prevent use of open resolver to relay a DoS attack on an
authoritative server?
State: Stateless server?

We also have code criteria but those are pretty much subjective. We
are all using TLS as a base. We all have some additional glue. DTLS
support isn't universal and fast open is only supported on Linux. If
you want to do mutual authentication then you are going to need more
mechanism than bare TLS.

The first one I consider to be a qualification requirement. DNS over
TLS and DTLS can be configured to meet it but doing so requires some
mechanism.

So:

DNS over TLS:
   MM - Yes
   1RT - 65%
   PDoS - In loop PKI gated by cookie authentication
   QDoS - ?
   State - No

DNS over DTLS
   MM - No
   1RT - 97% [3% of real world network circumstances are bjorked]
   PDoS - In loop PKI gated by cookie authentication
   QDoS - ?
   State - Yes (but requires specific configuration)

Private DNS
   MM - Yes
   1RT - 97%
   PDoS - No in-loop PKI
   QDoS - All requests authenticated by MAC
   State - Server is stateless.

Now granted this is my scorecard so its not surprising I win based on
it. But I have been at this since long before there was a demand for
confidentiality in DNS. And so I have spent quite a lot of time
talking to various DNS people to find out what their requirements are.
And I have accepted pretty much every requirement that has been
suggested.

The only requirements I don't address in the proposal on the table are
the traffic analysis and anti-censorship requirements. And I am not
putting the extensions to address those requirements on the table
because they depend on steganography to an extent.

In addition, the service connection module I am introducing can be
used to simplify a lot of other Web Services. Certificate enrollment
for example. That is important because even though TLS client auth is
an excellent authentication mechanism, it isn't a solution to client
auth without an automated certificate enrollment protocol.

One final point. If people decide to adopt my draft then we can wrap
up the DNS privacy work pretty quickly we can recharter and extend the
scope to apply the same approach to time and other trusted protocols.
While time does not necessarily need confidentiality, it does need
authentication. And this is obviously meant to be since this group is
called DPRIV, pronounced 'deprive'. Which means there has to be a
successor DPRAVE, pronounced 'deprave'.