Subject: [dns-privacy] Multiple DNS requests per packet, multiple packet responses

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 19 Mar 2014 13:40:01 -0400

One consequence of encrypting DNS traffic is that we break backwards
compatibility. Since we are going to break backwards compatibility we
should take the opportunity to fix some of the problems in the DNS protocol.

In particular, to guarantee compatibility with legacy DNS infrastructure, a
query must:

* Be 500 bytes or less
* Have only one query (QDCOUNT = 1)
* Have a response of 500 bytes or less

Now in practice the first limit it 'usually' not enforced. But going to
encryption is an opportunity to go from 'not enforced' to 'knock it off, if
your implementation does not accept decent sized packets then its broken,
broken, broken'.

I would also like to fix the other two issues. In particular, if we let a
DNS query ask more than one question at a time then we improve latency of
responses. But much more importantly, we also make more interesting
discovery strategies possible because asking for the AAAA, SRV, NAPTR and
URI record along with the A record is no longer a 5 request penalty. And
yes, it really is a penalty because much of the deployed infrastructure
limits the number of parallel DNS queries an app can make in interesting
and painful ways.

So I would like to require a server that supports the crypto query protocol
to be required to actually implement what is written in 1035 and respond to
multiple queries. As in Servers SHALL implement RFC1035 and respond to
queries with QDCOUNT>1. But since I don't think I will get that I will
settle for this being an option that a server can advertise during the key
setup. If the server can tell the client what its key is then it can tell
the client what options it supports.

One problem that comes of multiple requests is the potential for multiple
responses being longer than one packet. And here the traditional thinking
is rather limited.

It is of course highly undesirable for a DNS server to have to respond to
queries that are more than one packet long because that requires the server
to maintain state. And state is expensive. It wrecks anycast, massively
parallel server farms and any number of things that we don't want wrecked.

But returning multiple response packets does not require additional state.
The server just receives a packet, does some work and returns zero to 16
packets in response. Moreover, even though individual queries are slightly
more expensive, the overall load on the server goes down.

One possible objection here is that this would enable more effective
amplification attacks or complicate the DDoS against the server scenario.
These are important considerations and are the main reason I don't want to
try to use IPSEC or DTLS as the basis of a solution. When I started working
on OmniBroker in 2012, these were the issues that drove me to adopt the
architecture I did.

In brief, I don't think we should worry about making DDoS or amplification
attacks worse. Instead we have to have a strategy that allows us to
mitigate them to the point where they are not worth the results.

-- 
Website: http://hallambaker.com/

---

From: Tony Finch <[email-masked]>
Date: Wed, 19 Mar 2014 18:06:27 +0000

Phillip Hallam-Baker <[email-masked]> wrote:
>
> In particular, if we let a DNS query ask more than one question at a
> time then we improve latency of responses.

No need to change the protocol, just make the queries concurrently. If
your implementation makes that slow, fix the implementation. You would
have to fix it anyway in order to support the protocol changes, so you
might as well do the fix without the protocol change. No need to waste
time and money on talking about paper protocols.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Lundy, Fastnet: Southwest 5 to 7, occasionally gale 8, perhaps severe gale 9
later. Moderate or rough, becoming rough or very rough. Rain later. Good,
occasionally poor.

---

From: Ted Hardie <[email-masked]>
Date: Wed, 19 Mar 2014 11:09:17 -0700

On Wed, Mar 19, 2014 at 10:40 AM, Phillip Hallam-Baker <[email-masked]>wrote:

> compatibility.

Howdy,

Backwards compatibility with what part of the system?  Or perhaps first,
what question are we answering, that makes you presume this?

Imagine for a moment that the question is: "How do I prevent exposure of
clear text DNS queries from pervasive surveillance when they are sent from
my home to a recursive resolver in a data center?"  One answer certainly
could be "Set up an IPSEC tunnel between yourself and that data
center-based resolver, then run DNS across it".  There are a bunch of
trade-offs that will tell you whether that is a good idea, but one piece of
the puzzle is that the DNS bits would look exactly the same.

There are other approaches which retain the current syntax and change out
only the transport (for many other values of transport).  There is no
reason to believe those are wrong  on first principles, so let's not start
with a "this means DNS 2.0" until we've worked out what the actual issues
are, okay?

regards,

Ted Hardie

> Since we are going to break backwards compatibility we should take the
> opportunity to fix some of the problems in the DNS protocol.
>
> In particular, to guarantee compatibility with legacy DNS infrastructure,
> a query must:
>
> * Be 500 bytes or less
> So I would like to require a server that supports the crypto query
> protocol to be required to actually implement what is written in 1035 and
> respond to multiple queries. As in Servers SHALL implement RFC1035 and
> respond to queries with QDCOUNT>1. But since I don't think I will get
> that I will settle for this being an option that a server can advertise
> during the key setup. If the server can tell the client what its key is
> then it can tell the client what options it supports.
>
>
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 19 Mar 2014 14:19:43 -0400

> time and money on talking about paper protocols.

This is not a change. It is implementing RFC1035 as written.

BIND and co have done it wrong all these years. If the implementations are
not wrong then where is the RFC that states QDCOUNT = 1?

I have talked to the engineers at several browser companies and they tell
me that parallel queries do not actually work the way you imagine.

In the first place it is only possible to issue the queries at all if you
override the built in platform API. But even when you do, problems are
caused by middleboxes and ISPs which limit the number of concurrent queries.

For a resolver, the change is cheap. The benefit to the client is enormous.

---

From: Tony Finch <[email-masked]>
Date: Wed, 19 Mar 2014 18:31:44 +0000

> me that parallel queries do not actually work the way you imagine.

They do as far as the protocol is concerned and there are many
stub resolver implementations that make concurrent queries.

> caused by middleboxes and ISPs which limit the number of concurrent queries.

So fix them. You will have to anyway.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
South-east Iceland: Cyclonic 6 to gale 8, occasionally severe gale 9 in west.
Very rough or high. Rain or wintry showers. Moderate or poor, occasionally
good.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 19 Mar 2014 14:34:25 -0400 (EDT)

On Wed, 19 Mar 2014, Phillip Hallam-Baker wrote:

[ still finding your replies to replies basiclly unreadable due to your
   email client quoting settings, so if I'm mis-attributing, thats why.
   When these go like 3 deep, I basically have to just give up and delete
   the emails unread. You are the only person I have this problem with,
   and plenty of people use gmail.]

> BIND and co have done it wrong all these years. If the implementations are not wrong then where is the RFC that states QDCOUNT = 1?

We tested this a few months ago while discussing draft-wouters-edns-keepalive using
a modified dig command.

All servers support multiple queries at once fine. Only google dns
capped it at 80 queries before closing the connection. Things will be
different when the TCP connection is idle of course, as the server might
hang up on you, hence the above mentioned draft to match up client and
server behaviour.

> I have talked to the engineers at several browser companies and they tell me that parallel queries do not actually work the way you imagine.

All the more reason for draft-wouters-edns-keepalive (and
draft-wouters-edns-chain-query)

Paul

---

From: Paul Wouters <[email-masked]>
Date: Wed, 19 Mar 2014 14:36:47 -0400 (EDT)

On Wed, 19 Mar 2014, Phillip Hallam-Baker wrote:

> One consequence of encrypting DNS traffic is that we break backwards compatibility.

Various proposals that are floating around do no such thing. I have been
critical of djb putting dnscurve over port 53 and I would be just as
critical to others suggesting we put non-DNS over port 53.

Paul

---

From: Mark Andrews <[email-masked]>
Date: Thu, 20 Mar 2014 05:51:55 +1100

In message <[email-masked]>
> not wrong then where is the RFC that states QDCOUNT = 1?

The HEADER is future proof.  The protocol is written for QDCOUNT = 1 for QUERY.
The HEADER does NOT support QDCOUNT != 1 for general <QNAME,QTYPE,QCLASS> in
the query section.  There is no defined behaviour for fixed <QNAME,QCLASS>
and variable <QCLASS>.
 
> caused by middleboxes and ISPs which limit the number of concurrent queries.

Total BS.  There are system resolvers that are thread aware.  Fire
off # threads in parallel then join. 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 19 Mar 2014 14:55:28 -0400

> what question are we answering, that makes you presume this?

Since my client does not currently know about encryption it is going to
have to be upgraded to send encrypted packets.

Once my client sends encrypted packets they cannot by definition be read
unless the receiver has the key and decryption algorithm. Since no server
currently implements said decryption, a new server is needed.

Hence the new protocol cannot be backwards compatible with the old. There
can be a transition path and of course that needs to be considered. But
both the plug and the socket have to change and so there is no reason to
insist on the same connector.

> the puzzle is that the DNS bits would look exactly the same.

If the answer was IPSEC then we would be doing it already.

There are times to persevere and there are times to just let go. IPSEC has
been in the last category for a decade.

Every IPSEC VPN I have ever used has come with instructions on how to
install a third party IPSEC stack for use with it. And every one of those
has been an unending tale of incompatibility and instability.

The only reason to build on existing specifications is to make use of
existing implementations. If the implementations are huge and unstable then
its time to move on.

> with a "this means DNS 2.0" until we've worked out what the actual issues

My point is that once you decide to change out the transport, you have made
a major change.

All I am proposing to do is to change out the transport. I am suggesting a
KeyExchange + Encapsulation type solution. So it would still be RFC1035
messages inside the encapsulation. But we do have some choices in the way
we design the encapsulation.

Now you can argue that we could just use IPSEC or DTLS. But those are both
really complicated protocols and they are both wired up to PKIX. Yes, I
know that in theory you can do other stuff but in practice you can't
because the stacks have only been tested for interop on PKIX.

PKIX is built on top of DNS. Which is not a show stopper form making use of
PKIX to secure DNS but you have to do it carefully and in a controlled way.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 19 Mar 2014 15:18:02 -0400

> critical to others suggesting we put non-DNS over port 53.

My point is that  E(DNS, k) <> DNS

If you take DNS messages and encrypt them, the result is not DNS
messages. There are hacks that can be used to tunnel non-DNS messages
over DNS but that is a different issue.

As I see it, port 53 is for DNS protocol messages as in DNSv1.0
protocol without encryption.

If people are encrypting by whatever means, then they should be on a
different port. But that is easy enough to do.

---

From: Joe Abley <[email-masked]>
Date: Wed, 19 Mar 2014 15:25:42 -0400

> over DNS but that is a different issue.

Well, to the extent that you believe that DNS is not extensible for these purposes (e.g. via EDNS0 or EDNSn, n > 0).

> protocol without encryption.

This was a point we made (perhaps weakly) in draft-jabley-dnsop-dns-onion.

The bits of that idea that use port 53 are regular, unmolested DNS queries. All the other bits could be RESTful APIs over HTTPS pools, or whatever else you like. Whatever other weaknesses one might reasonably point out in that proposal, the facts that it (a) works with existing stub resolvers and authority servers without modification and (b) does not require deployment of DNSSEC, are strengths, I think.

Joe

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 19 Mar 2014 15:27:04 -0400

> hang up on you, hence the above mentioned draft to match up client and

Wow, so we have the capability there in the infrastructure but people
are saying that they can't check for DANE records or other policy
records and other people are saying that we shouldn't 'change' the
protocol?

> draft-wouters-edns-chain-query)

That looks like a perfectly sensible suggestion. But I would prefer to
avoid going to TCP unless it is absolutely necessary.

If we go to TCP then the shortest distance between two points is to
make DNS a Web Service and run it over TLS. Now I do in fact do
precisely that in OmniBroker to provide a 'last ditch' resolution
service for cases where the user is stuck behind a hotel portal. But I
was hoping to avoid that for DNSE.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 19 Mar 2014 15:38:51 -0400 (EDT)

On Wed, 19 Mar 2014, Phillip Hallam-Baker wrote:

> messages.

That depends. If you use a new RRTYPE for this, it could very well be
DNS.

> different port. But that is easy enough to do.

And trivial to block by adversaries?

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 19 Mar 2014 16:02:05 -0400

> And trivial to block by adversaries?

Well, that get us into the whole discussion of what the attack model is.

First off, my DNS privacy proposal is not the OmniBroker proposal I
have been working on for about two years now. What we are talking
about here is just being able to transport DNS protocol between a
client and server with minimal privacy compromise to third parties. In
Omnibroker I support additional queries such as fast access to OCSP
certificate status data and other trusted data.

That said, many of the security considerations are the same. In
particular we have denial of service considerations that are hard and
we want the protocol to have minimal impact on latency.

The problem dealing with blocking of requests is deciding how to
respond. You have basically three options

a) Attempt to tunnel over another protocol
b) Tell the user that they can't go to the site because of blocking
c) Fallback to standard DNS

If the attack is coming from a stupid firewall or other middlebox,
option a is likely to succeed. If the problem is an active attack then
you are going to be left with b or c.

That said, in Omnibroker, the protocol is divided into two parts.

1) Connection (Key Exchange and service discovery) which is always
implemented as a JSON Web Service over TLS.

2) Query/Response which is supported over multiple protocols:

A) UDP Protocol with JSON-B messages
B) Tunneling over DNS TXT requests using BASE-32 & BASE-64
C) As a JSON Web Service over TLS

Option A is available in 97% of network situations and Option B works
in the other 3%. Option C is only necessary in cases where there is an
active attack and the attacker can still block the IP address of the
Web Service if they can work out where that is.

One of the countermeasures I take to prevent this type of attack is
that the client is given the address of the resolver during the key
exchange. This allows me to keep the address of the resolver private.

Keeping the resolver address private does not do anything for me in
IPv4 space. But it provides a lot of leverage in IPv6 world. I can put
every client session on a separate IPv6 address and then filter out
the DoS attacks by IP address.

   [I-D.hallambaker-omnibroker]  Hallam-Baker, P, "OmniBroker Protocol",
              Internet-Draft draft-hallambaker-omnibroker-07, 21 January
              2014.

   [I-D.hallambaker-wsconnect]  Hallam-Baker, P, "JSON Service Connect
              (JCX) Protocol", Internet-Draft draft-hallambaker-
              wsconnect-05, 21 January 2014.

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 20 Mar 2014 08:42:23 +0100

Hi,

On 03/19/2014 07:55 PM, Phillip Hallam-Baker wrote:
> On Wed, Mar 19, 2014 at 2:09 PM, Ted Hardie <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     On Wed, Mar 19, 2014 at 10:40 AM, Phillip Hallam-Baker
>     <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Backwards compatibility with what part of the system?  Or perhaps
>     first, what question are we answering, that makes you presume this?
> 
> 
> unless the receiver has the key and decryption algorithm. Since no
> server currently implements said decryption, a new server is needed.
> 
> 
> Hence the new protocol cannot be backwards compatible with the old.
> There can be a transition path and of course that needs to be
> considered. But both the plug and the socket have to change and so there
> is no reason to insist on the same connector.

My client also didn't knew about DNSSEC and had to be upgraded to
validate responses. We indeed needed a new server that could add those
RRSIG records. But the protocol was backwards compatible. So, I don't
see why we couldn't end up with a solution that is backwards compatible
here.

Best regards,
  Matthijs

>     Imagine for a moment that the question is: "How do I prevent
>     exposure of clear text DNS queries from pervasive surveillance when
>     they are sent from my home to a recursive resolver in a data
>     center?"  One answer certainly could be "Set up an IPSEC tunnel
>     between yourself and that data center-based resolver, then run DNS
>     across it".  There are a bunch of trade-offs that will tell you
>     whether that is a good idea, but one piece of the puzzle is that the
>     DNS bits would look exactly the same.
> 
> 
> There are times to persevere and there are times to just let go. IPSEC
> has been in the last category for a decade. 
> 
> install a third party IPSEC stack for use with it. And every one of
> those has been an unending tale of incompatibility and instability.
> 
> existing implementations. If the implementations are huge and unstable
> then its time to move on.
> 
> 
>     There are other approaches which retain the current syntax and
>     change out only the transport (for many other values of transport). 
>     There is no reason to believe those are wrong  on first principles,
>     so let's not start with a "this means DNS 2.0" until we've worked
>     out what the actual issues are, okay?
> 
> 
> My point is that once you decide to change out the transport, you have
> made a major change.
> 
> All I am proposing to do is to change out the transport. I am suggesting
> a KeyExchange + Encapsulation type solution. So it would still be
> RFC1035 messages inside the encapsulation. But we do have some choices
> in the way we design the encapsulation.
> 
> 
> Now you can argue that we could just use IPSEC or DTLS. But those are
> both really complicated protocols and they are both wired up to PKIX.
> Yes, I know that in theory you can do other stuff but in practice you
> can't because the stacks have only been tested for interop on PKIX.
> 
> PKIX is built on top of DNS. Which is not a show stopper form making use
> of PKIX to secure DNS but you have to do it carefully and in a
> controlled way.
> 
> --

---

From: Tony Finch <[email-masked]>
Date: Thu, 20 Mar 2014 10:14:21 +0000

> records and other people are saying that we shouldn't 'change' the

The problems that browsers have is NOT lack of concurrency in the DNS.
For example I pointed a computer at Google Public DNS which is about
12ms away, and observed plenty of concurrent DNS requests - see below for
tcpdump output.

The problem with DANE is more to do with middleboxes (especially home CPE)
breaking DNSSEC. If that were not the case it would be straightforward for
browsers to request all the necessary DANE records at the same time as the
site's address records, without harming latency.

The problem with TLS policy records is that the browser does not know
ahead of time what queries it will need to make, so looking up the records
adds latency between receiving the certificate and being able to use the
TLS connection.

10:06:19.874220 IP 172.24.193.148.55349 > google-public-dns-a.google.com.domain: 61217+ A? www.ietf.org. (30)
10:06:19.874335 IP 172.24.193.148.60888 > google-public-dns-a.google.com.domain: 63087+ AAAA? www.ietf.org. (30)
10:06:19.874462 IP 172.24.193.148.59022 > google-public-dns-a.google.com.domain: 48942+ A? www.iab.org. (29)
10:06:19.874588 IP 172.24.193.148.52688 > google-public-dns-a.google.com.domain: 57512+ AAAA? www.iab.org. (29)
10:06:19.874713 IP 172.24.193.148.59194 > google-public-dns-a.google.com.domain: 37286+ A? www.rfc-editor.org. (36)
10:06:19.874834 IP 172.24.193.148.51605 > google-public-dns-a.google.com.domain: 62361+ AAAA? www.rfc-editor.org. (36)
10:06:19.886559 IP google-public-dns-a.google.com.domain > 172.24.193.148.55349: 61217 1/0/0 A 4.31.198.44 (46)
10:06:19.886733 IP google-public-dns-a.google.com.domain > 172.24.193.148.60888: 63087 1/0/0 AAAA 2001:1900:3001:11::2c (58)
10:06:19.886894 IP google-public-dns-a.google.com.domain > 172.24.193.148.59194: 37286 1/0/0 A 209.208.19.211 (52)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Trafalgar: Variable 3 or 4, becoming southwesterly 4 or 5 later in northwest.
Moderate. Occasional drizzle. Moderate or good.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 20 Mar 2014 08:54:26 -0400

> see why we couldn't end up with a solution that is backwards compatible

Really?

When DNSSEC was first proposed in 1995 or thereabouts it wasn't
deployable because most of the DNS infrastructure could not support
new RR types, there was a 500 byte limit on messages in many cases and
several other issues.

It took another five years to fix those issues in the infrastructure
before deployment became practical.

What I am saying here is that we have an opportunity to say that we
leave certain parts of the legacy behind without additional cost.

Or we could start the work by declaring that the DNS protocols were
handed down in a state of grace and that they represent the most
shining example of perfection we can hope to achieve and that anyone
who suggests the mere possibility of alternative approaches must be
cast out as a heretic.

The hard part here is how to apply public key crypto to a low latency
protocol without exposing the server to DoS attacks. And no, Bernstein
et. al. are not close to having solved it and nor is some exotic
public key algorithm likely to be the solution either.

DNSSEC has always had to dance round the problem that DNS responses
have to fit in one packet. And that pushes a huge number of
contortions onto designs. I think it is more than reasonable to
require that if people are going to start encrypting packets that they
be required to have a strategy that can transport DNSSEC packets for
almost all real world protocols without having to switch from UDP to
TCP. That could mean staying in UDP all along or starting in TCP from
the start. But switching horses in midstream from UDP to TCP hits all
sorts of ugly real world deployment issues.
-- 
Website: http://hallambaker.com/

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 21 Mar 2014 00:33:04 -0400

> who suggests the mere possibility of alternative approaches must be

Or we can do something like HTTP/2 is doing and approaching it as a new 
mechanism and allow methods for choosing, but having a fall back strategy.

> sorts of ugly real world deployment issues.

I would agree it should either all work in UDP or start in TCP.

And Pauls' drafts are very relevant to this conversation.

tim

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 21 Mar 2014 07:32:47 -0400

> mechanism and allow methods for choosing, but having a fall back strategy.

That is what I was proposing.

Every time we try to use the DNS for a particular project we end up
hitting our heads against a slew of deployment restrictions that make
it unusable or limit the value.

Encrypting the traffic is inevitably a significant discontinuity.

> And Pauls' drafts are very relevant to this conversation.

Or possibly more practical would be to have a strategy where UDP is
the default but there is a fallback over HTTP.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 21 Mar 2014 15:54:34 +0100

On Wed, Mar 19, 2014 at 01:40:01PM -0400,
 Phillip Hallam-Baker <[email-masked]> wrote 

> One consequence of encrypting DNS traffic is that we break backwards

Just a reminder: "This list is for the discussion of the problem
statement surrounding the addition of privacy to the DNS protocol."
Privacy is the goal, encryption may be a solution. This list is
dns-privacy, not dns-encryption.

> Since we are going to break backwards compatibility we should take
> the opportunity to fix some of the problems in the DNS protocol.

I disagree with this approach: adding encryption, should we decide it,
is more than enough work to keep an IETF mailing list active for many
months (years?) Saying "hey, cool, the gates are open, let's try to
push all the other stuff I want" seems a sure recipe for a second
system failure <http://en.wikipedia.org/wiki/Second-system_effect>.

> multiple queries.

RFC 1035 is quite broken here since it does not say how to set the
status code when the different questions yield differente results. In
the last years, several people have proposed to update RFC 1035 to
make this scheme workable (for instance by requesting that all the
questions use the same qname or by having several response packets, as
you suggest) but it never went far.

---

From: "Wiley, Glen" <[email-masked]>
Date: Fri, 21 Mar 2014 14:57:38 +0000

-- 
Glen Wiley
KK4SFV

Sr. Engineer
The Hive, Verisign, Inc.

>dns-privacy, not dns-encryption.

+1

>system failure <http://en.wikipedia.org/wiki/Second-system_effect>.

The past decade of chatter regarding changes to DNS is a strong indicator
of the need to keep the scope of these changes tightly constrained if
there is any hope of producing consensus on a solution.

>>protocol

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 21 Mar 2014 11:55:38 -0400

> system failure <http://en.wikipedia.org/wiki/Second-system_effect>.

And end up with systems like DNSSEC which have taken as long as they
have because necessary changes to the protocol were fought tooth and
nail for absolutely no good reason.

There is no point in a specification that nobody is going to use
because they can't or it does not solve enough problems. Right now we
have a million people trying to connect to Twitter despite DNS
blocking. That is just as important a use case as stopping other
governments seeing that people are connecting to Twitter.

If people were willing to think about new ideas for just 5% of the
time they spend trying to block them in the DNS space because they
find the idea of new ideas scary we might get somewhere.

DNSSEC would have been deployed in 2002 if you had been willing to
consider doing things my way. You guys never intended to give me a
chance to help you then.

The main reason everything takes so long in the DNS area is that there
are so many people that think they add value by creating friction and
opposing every proposal before they have even heard what it is.

I have been thinking about and publishing on this problem for over two
years. As a result I know the problem space, the solution space and
the cost of various options pretty well.

> you suggest) but it never went far.

I did wonder about that. But I think I have a solution as follows.

PRIVATE-DNS (my scheme) has

1) a key exchange used to setup a relationship between a client and
server. That just reuses TLS at the moment but I expect that some
extra crypto will end up in the mix.

2) a wrapper for transporting DNS messages.

A simple wrapper would be something like:

Request:

ContextID:    Byte []   // The cryptographic session information
TID:    Byte []   // Transaction Identifier and Initialization Vector
for the crypto
Data: Byte []   // The encrypted DNS Request message as per RFC1035
MAC:   Byte []   // Authentication code (possibly optional)

Response

TID:    Byte []   // Transaction Identifier and Initialization Vector
for the crypto
Data: Byte []   // The encrypted DNS Request message as per RFC1035
MAC:   Byte []   // Authentication code (possibly optional)

Since the IV is 128+ bits of random data it makes perfect sense to
reuse it as a transaction identifier for matching requests and
responses. To do this securely the mechanism for converting the TID to
the IV has to be different on requests and responses. The simplest
scheme would be to XOR the TID and MAC values from the request to
produce the IV for the response.

All that is needed to put multiple requests in a request packet is to
change the schema to be:

Request:

Data: Byte []   // Encrypted list of DNS Request message as per RFC1035

i.e instead of the encoding being something like

<length> <bytes> <data-padding>

It would be

<length> <bytes> (<length> <bytes>) * <00> <data-padding>

For an application like DNS, the length of the message can reveal a
great deal about the request. So adding padding to bulk up the message
to an
integral multiple of 64 bytes (say) is quite important.

The data framing for the response would be the same except that if we
wanted to support multiple response packets the format of each packet
would be something like:

Packet:

PacketIndex:  Integer (0..15)
MaxIndex:  Integer (0..15)
TID:    Byte []
Segment:   Byte []

To process responses the client must first receive all the response
packets, match them to the request and assemble them in order. The
inner encoded data is then

<length> <bytes> (<length> <bytes>) * <00> <mac> <data-padding>

The responses are given in the same order as the original requests.

This mechanism is limited to 16 response packets (requests are always
1 packet). This is probably close to the upper limit for reliable UDP
since the receiver has to receive all the packets to use them. But
this is almost certainly ample for virtually all DNS queries we might
want to make.

Allowing multiple requests/responses does make the client
implementation a little more complex. But it avoids the need to
fallback to TCP which these days only works reliably on ports 80 and
443. It reduces latency and network traffic.

The big advantage is that it means that we can use DNSSEC now without
having to constantly worry a little bit of extra data in the response
is going to cripple performance and reliability due to clients having
to fallback to TCP over port 53.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 21 Mar 2014 12:42:45 -0400 (EDT)

> the default but there is a fallback over HTTP.

If you want to be censorship resistant, you should make DNS
encryption integral to DNS. Not have some appendix that someone
can easilly cut off.

Paul