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

Hi,

On 03/19/2014 07:55 PM, Phillip Hallam-Baker wrote:
> On Wed, Mar 19, 2014 at 2:09 PM, Ted Hardie <ted.ietf@gmail.com
> <mailto:ted.ietf@gmail.com>> wrote:
> 
>     On Wed, Mar 19, 2014 at 10:40 AM, Phillip Hallam-Baker
>     <hallam@gmail.com <mailto:hallam@gmail.com>> 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.

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.
> 
> 
> 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/
> 
> 
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
> 