DNSE W. Hardaker Internet-Draft Parsons, Inc. Intended status: Standards Track April 01, 2014 Expires: October 03, 2014 Anonymizing and privatizing requests and responses in the DNS draft-hardaker-dnse-split-key-dns-00 Abstract This document discusses the type of architecture necessary to make DNS requests not just private between parties, but functionally anonymous so that the only entity that knows who made the request is the source entity itself. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 03, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Hardaker Expires October 03, 2014 [Page 1] Internet-Draft Anonymizing and privatizing the DNS April 2014 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Work in Progress Warning . . . . . . . . . . . . . . . . 2 1.2. Request/Response Protection Through Encrypted Links . . . 2 1.2.1. True DNS Privacy Requirements . . . . . . . . . . . . 3 1.3. A New Model For Protecting End Entities . . . . . . . . . 3 2. The Solution . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Minimal Requirements . . . . . . . . . . . . . . . . . . 4 3. Operational Considerations . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. Normative References . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction 1.1. Work in Progress Warning Warning: the content in this document is mostly a crazy scheme to show the problems with current approaches to anonymize requests and responses in the DNS. The architecture is an example solution and is not necessarily the best available. Consider it a discussion point. Specifically: THIS WILL NOT WORK FULLY IN PRACTICE. 1.2. Request/Response Protection Through Encrypted Links Today, most end-entities talk to a select number of recursive resolvers that are responsible for handling the bulk of their DNS lookups. An end entity system may wish to lookup an A record for the www.example.com domain name, and rather than starting from the root itself and finding the answer, they'll pass the buck to a recursive resolver to take advantage of their better processing power and cache. Typically thees resolvers are hosted by ISPs on behalf of their clients. +--------------------+ | root | +--------------------+ ^ | | v +-----------+ +--------------------+ +-------------+ | endEntity | <--> | recursive resolver | <--> | example.com | +-----------+ +--------------------+ +-------------+ ^ Hardaker Expires October 03, 2014 [Page 2] Internet-Draft Anonymizing and privatizing the DNS April 2014 | | v +--------------------+ | com | +--------------------+ In this architecture (based on how DNS is implemented), only the endEntity and the recursive resolver know who made the request for www.example.com, unless someone ("Eve") is actively monitoring the link(s) between the endEntity and the recursive resolver. To protect against attacks by Eve, solutions spaces being discussed today are trying to protect these links by tunneling DNS over encrypted methods such as encrypted transports (DTLS and TLS) or through modifying DNS itself. However, this architecture assumes that the recursive resolver itself is trustable and has not been taken over, either legally or maliciously, itself. The endEntity still has no assurance against a well funded advisory that their requests are not being logged by the recursive resolver. 1.2.1. True DNS Privacy Requirements For true privacy, only the end-entity can be aware of "what is being asked for". If anyone other entity knows both of these two pieces of information, the end entity no longer has exclusive control over their privacy. 1.3. A New Model For Protecting End Entities In order to protect against this threat, the endEntity must transmit the request to the recursive resolver in such a way that the recursive resolver in such a way that the recursive resolver must not be aware of which end entity sent the request in the first place. This can only be done through carefully funneling encrypted versions of the request through aggregators in the middle in such a way that the traffic aggregators themselves can't see the request. +-----------+ +-----------+ +-----------+ +-------------+ | endEntity | ==> | resolver2 | ==> | | --> | example.com | +-----------+ +-----------+ | | +-------------+ || | | || | recursive | \/ | resolver | +-----------+ | | +-------------+ | resolver1 | ====================> | | --> | com | Hardaker Expires October 03, 2014 [Page 3] Internet-Draft Anonymizing and privatizing the DNS April 2014 +-----------+ +-----------+ +-------------+ | | v +--------------------+ | root | +--------------------+ ===> Special Encrypted ---> Normal DNS How this can be accomplished in a way that makes the recursive resolver unaware of who is making the original request is discussed in the next section 2. The Solution 2.1. Minimal Requirements To truly protect the end entity against anyone but them knowing the requests they make, we must: o The end-entity must encrypt the request for the recursive resolver. o The end-entity must transmit the request to the recursive resolver in a way that the middle entities don't know both "what is being asked for" and "who is requesting the information". True privacy is only accomplished if both of these facts are only known by the requestor. To implement this, the standard DNS system can be used to transmit encrypted requests to an anonymous supporting distant recursive resolver as follows: 1. It does this by creating a symmetric key, KK, and using it to encrypt the "real" request (name="www.example.com",type="A",class="IN") using the secret key KK and an encryption algorithm. This will result in an encrypted blob "EEEEEEE". Hardaker Expires October 03, 2014 [Page 4] Internet-Draft Anonymizing and privatizing the DNS April 2014 2. It then encodes this, and half of the symmetric key (we'll call the split halves K1 and K2) into a DNS request with a special domain suffix that is known to be supported by the anonymizing recursive resolver. For this example, we'll use "exmaple.org" as the anonymizing recursive resolver's special name space. E.G., the resulting request might look like "EEEEEEEEE.K1.example.org" for type NEWTYPE (or TXT records for those that want to brave the wrath). It transmits this request, and the corresponding request containing EEEEEEE.K2.example.org, to two different generic recursive resolvers. [These need to be two organizationally separate resolvers and delivered over two separate networks, such as one over a TOR network and one over a regular network such that both requests never go over the same "link" and can not be seen together]. In the architecture diagram above, resolver1 and resolver2 will both receive two different request packets and process them normally. Though they know the source end-entity that submitted the DNS requests, they do not know what's really in them. Both requests will eventually end up at the anonymizing name servers associated with example.org. They will eventually collect the two halves being sent to them from resolver1 and resolver2 and can combine the key halves to determine the real request contained inside EEEEEEE. At this point, the recursive resolver knows the real request, but not what end-entity initiated it. It only knows the two resolvers (1 and 2) that it came through. The anonymizing recursive resolver can then perform the actual lookup with the extracted information, encrypt it into a new response packet to be put in the DNS RR payload for EEEEEEEEE.K1.example.org and EEEEEEEEE.K2.example.org and return the answers to the recursive resolvers. The recursive resolvers can then return the results to the end- entity, who can take either of the two responses and decode the results (or both responses if they don't keep a key cache and need K1 and K2 both again). 3. Operational Considerations This is truly a hack. It could be made to work, sure, but it's a big big hack. Maybe a better solution will come out of it that provides more privacy than just protecting the link between the end-entity and the recursive resolver, which is insufficient as shown above. 4. Security Considerations Hardaker Expires October 03, 2014 [Page 5] Internet-Draft Anonymizing and privatizing the DNS April 2014 Security definitely should be considered. Do not try this at home kids. Splitting the keys into more than two pieces and sending them to more resolvers provides, obviously, even greater protection. 5. IANA Considerations TBD 6. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. Author's Address Wes Hardaker Parsons, Inc. P.O. Box 382 Davis, CA 95617 US Phone: +1 530 792 1913 Email: ietf@hardakers.net Hardaker Expires October 03, 2014 [Page 6]