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

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

On Thu, Mar 20, 2014 at 3:42 AM, Matthijs Mekking <[e-mail]> wrote:
> Hi,
>
> On 03/19/2014 07:55 PM, Phillip Hallam-Baker wrote:
>> On Wed, Mar 19, 2014 at 2:09 PM, Ted Hardie <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>>     On Wed, Mar 19, 2014 at 10:40 AM, Phillip Hallam-Baker
>>     <[e-mail] <mailto:[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.
>
> 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.

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/