Re: [perpass] DNS confidentiality

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

On Tue, Sep 24, 2013 at 4:43 AM, Stephen Farrell
<[e-mail]>wrote:

>
> Hiya,
>
> I've not seen mention of this so far here that I recall.
>
> Even as we improve the security of loads of protocols, there
> will still be issues with meta-data monitoring based on
> DNS queries for example. This point was sort of raised on
> the IETF list e.g. in [1].
>
> DNSSEC doesn't provide any confidentiality. There are
> proposals that do try do that.
>
> Do we think this is worth looking at?
> If so, anyone up for doing some work on that?
> If so, how, or starting from what?
>

I have been looking at this for over a year now. Does anyone have issues
with the following:

* The communication between the client and the DNS resolver need not be the
same as the protocol between the DNS resolver and the Authoritative servers.

* System must offer fault tolerance with the client having access to
multiple service points.

* Use JSON over HTTP wherever possible

* Individual DNS queries MUST result in low latency responses, this limits
us to using UDP.

* The scheme MUST work in ANY network configuration unless the provider
takes explicit steps to block use. Therefore the scheme SHOULD support
tunneling over DNS as an option but a clean protocol over UDP is better.

* The scheme need not be limited to returning DNS information, if we have a
long term security association between a client and a resolution service we
can use it for speeding up access to OCSP data and much else if we choose.


The above analysis led me to the following conclusion:

http://tools.ietf.org/html/draft-hallambaker-omnibroker-06

This does not currently offer the UDP and DNS options but they are what
motivated the following proposal:

http://tools.ietf.org/html/draft-hallambaker-jsonbcd-00

There are important design differences between this proposal and CBOR. In
particular JSON-B is a minimal extension of the JSON framework to add in
efficient encoding of strings and binary data while CBOR is a rehash of
ASN.1 without the schema.


Note that the query currently supported is a replacement for the
gethostbyname API call rather than a full DNS interface. The reason for
this is that 99% of all applications only perform gethostbyname in the
first place. The spec does allow a service to respond with a DNSSEC proof
chain as advice on client request.


Adding direct DNS queries to the spec is very simple, these can certainly
be added if there is a desire for them. I would make one major change
however and that is to support multiple DNS queries per request. One of the
biggest limitations in the current DNS scheme is that it is only possible
to query for one DNS record at a time or the ANY pseudo record which
returns everything (and likely forces a TCP switchover).

The requests actual applications want to make are things like the following:

[example.com ? A, AAAA] [_http._tcp.example.com ? SRV, URI, URI2]

Use of extended DNS features would be much easier if a client could tell
the resolver to send back data for multiple queries at once.


Moving to a pure UDP protocol allows requests and responses to be longer
than 500 bytes. It is also possible for a single request packet to return
multiple responses. These mean that it is very unlikely that fallback to
TCP is ever going to be necessary for client queries where low latency is
essential. It is however possible that a complex DNSSEC interaction might
require a large amount of response data.

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