Internet DRAFT - draft-hardaker-dnse-split-key-dns
draft-hardaker-dnse-split-key-dns
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]
