On Mon, May 19, 2014 at 9:40 AM, Stephane Bortzmeyer <[email protected]> wrote: > On Fri, May 09, 2014 at 05:38:46PM -0400, > Phillip Hallam-Baker <[email protected]> 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 <[email protected]> wrote: > On Mon, May 19, 2014 at 02:49:47PM +0100, > Stephen Farrell <[email protected]> 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/ _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
