Re: [dns-privacy] Private-DNS drafts

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

On Mon, May 19, 2014 at 9:40 AM, Stephane Bortzmeyer <[e-mail]> wrote:
> On Fri, May 09, 2014 at 05:38:46PM -0400,
>  Phillip Hallam-Baker <[e-mail]> wrote
>  a message of 120 lines which said:
>
>> * A General requirements draft for DNS privacy and related security
>> * concerns
>
> In this message, I'll talk only about this one,
> draft-hallambaker-dnse-01.
>
> Good idea to try to have a "requirments" document between the "privacy
> considerations" document and the various "solution"
> documents. However, I find that the requirments expressed in
> draft-hallambaker-dnse are too general: for instance, "[R-C-ACTIVE]
> Prevent or mitigate disclosure of request and response data against an
> active attacker on every contact" is nice but seems very difficult to
> achieve, and the draft does not mention the costs or the tradoffs
> (except the last sentence of "security considerations").

These are architectural requirements. To talk about the tradeoffs we
have to have a proposed solution.

Private-DNS does provide protection against active attack but it is
optional. The design tradeoff is that the client has to authenticate
the service. Which is fairly straightforward when leveraging TLS. But
this does come at the cost of requiring the service to have a
credential (WebPKI, DANE, whatever).

The point about detaching the requirements discussion from the
implementation is that other people might have better ways to achieve
that requirement.


> Also, I find that a requirment is missing: "limiting, to the maximum
> extent possible, the amount of data sent to forwarders or
> authoritative name servers". The draft only mentions the risk of
> profiling (so I assume a solution allowing anonymous clients would
> address it). But the qnames themselves are information and sometimes
> personal information and we want to limit every leak.

This still looks to me to be more of an implementation than an
architectural requirement. But the ESA scheme had design requirements,
perhaps we could incorporate that into the discussion.

The other part of the ESA scheme was discussion of constraints. Those
are also pieces that can be factored out of the design. Things like
'low latency matters'.



On Mon, May 19, 2014 at 9:56 AM, Stephane Bortzmeyer <[e-mail]> wrote:
> On Mon, May 19, 2014 at 02:49:47PM +0100,
>  Stephen Farrell <[e-mail]> wrote
>  a message of 11 lines which said:
>
>> Still haven't had a chance to read the others, but that one looks
>> good,
>
> I did not spend a lot of time on draft-hallambaker-privatedns but it
> frightens me a bit: very different from today's DNS and requiring to
> understand a new technology.

It isn't all that new. The architecture is mostly Kerberos. The key
exchange is a simple JSON/REST approach and the packet framing is just
a TLS style framing applied to a ticket based scheme.

The data that flows inside the messages is just plain old DNS with one
query per request. Bundling up multiple requests per packet isn't
making the protocol any more complex but allows the servers to be a
lot more efficient.


I do have a proposal that is a radical departure from DNS which is to
move to a meta-directory approach where the client asks the server to
return all the information required from all sources for discovery of
service X. Which includes sources like IP blacklists and domain
blocklists and PKIX CRLs, OCSP, etc.

But Private-DNS itself is very small. It is implementable on Arduino
class devices without taking up the whole memory space for the
implementation. Though you would probably want to modify the key
exchange so that you didn't need the whole TLS stack as well.


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