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

[Phillip Hallam-Baker <[e-mail]>]

On Wed, Mar 19, 2014 at 2:09 PM, Ted Hardie <[e-mail]> wrote:

> On Wed, Mar 19, 2014 at 10:40 AM, Phillip Hallam-Baker <[e-mail]>wrote:
>
>> One consequence of encrypting DNS traffic is that we break backwards
>> compatibility.
>>
>
> Howdy,
>
> Backwards compatibility with what part of the system?  Or perhaps first,
> 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.



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

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.


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.

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