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

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

On Wed, Mar 19, 2014 at 3:38 PM, Paul Wouters <[e-mail]> wrote:
> On Wed, 19 Mar 2014, Phillip Hallam-Baker wrote:
>
>> If you take DNS messages and encrypt them, the result is not DNS
>> messages.
>
>
> That depends. If you use a new RRTYPE for this, it could very well be
> DNS.
>
>
>> If people are encrypting by whatever means, then they should be on a
>> different port. But that is easy enough to do.
>
>
> And trivial to block by adversaries?
>
> Paul

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.

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