One document matched: draft-jabley-dnsop-dns-onion-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc1034 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml'>
<!ENTITY rfc1035 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml'>
<!ENTITY draft-bortzmeyer-dnsop-dns-privacy PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bortzmeyer-dnsop-dns-privacy.xml'>
<!ENTITY draft-koch-perpass-dns-confidentiality PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.koch-perpass-dns-confidentiality.xml'>
]>
<rfc category="info" ipr="trust200902"
docName="draft-jabley-dnsop-dns-onion-00">
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title>DNS Privacy with a Hint of Onion</title>
<author initials='R.' surname="Arends" fullname='Roy Arends'>
<organization>Nominet</organization>
<address>
<postal>
<street>Sandford Gate</street>
<street>Sandy Lane West</street>
<city>Oxford</city>
<code>OX4 6LB</code>
<country>UK</country>
</postal>
<email>roy@nominet.org.uk</email>
</address>
</author>
<author initials='J.' surname="Abley" fullname='Joe Abley'>
<organization>Dyn, Inc.</organization>
<address>
<postal>
<street>470 Moore Street</street>
<city>London</city>
<region>ON</region>
<code>N6C 2C2</code>
<country>Canada</country>
</postal>
<phone>+1 519 670 9327</phone>
<email>jabley@dyn.com</email>
</address>
</author>
<author initials='J.' surname="Damas" fullname='Joao Luis Silva Damas'>
<organization>Dyn, Inc.</organization>
<address>
<postal>
<street>Avenida de la Albufera 14</street>
<city>San Sebastian de los Reyes</city>
<region>Madrid</region>
<code>28701</code>
<country>Spain</country>
</postal>
<email>jdamas@dyn.com</email>
</address>
</author>
<date day="5" month="March" year="2014"/>
<abstract>
<t>The Domain Name System (DNS) has no inherent capability
to protect the privacy of end users. The data associated
with DNS queries and responses can be observed by intermediate
systems, and such observations could provide a source of
metadata relating to end user behaviour.</t>
<t>This document describes an approach which separates the data
in DNS queries and responses from the identity of the DNS
resolver used by DNS clients.</t>
<t>This approach does not address privacy concerns between a
stub resolver and a recursive resolver.</t>
<t>This approach imposes no requirement for modification of
authority servers, and does not depend upon widespread
deployment of DNSSEC signing or validation.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The Domain Name System (DNS), as described in <xref
target="RFC1034"/> and <xref target="RFC1035"/>, has
no inherent capability to protect the privacy of end
users. Privacy concerns are described in
<xref target="I-D.bortzmeyer-dnsop-dns-privacy"/> and
<xref target="I-D.koch-perpass-dns-confidentiality"/>.</t>
<t>This document describes an approach which separates the data
in DNS queries and responses from the identity of the DNS
resolver used by DNS clients.</t>
<t>This approach does not address privacy between a stub
resolver and a recursive resolver.</t>
<t>This approach imposes no requirement for modification of
authority servers, and does not depend upon widespread
deployment of DNSSEC signing or validation.</t>
<t>The approach described here is derived from (and is similar
or identical in many respects to) the Tor project <xref
target="Tor"/>. The motivation to write up a DNS-specific,
Tor-like solution is to explore opportunities to optimise
the solution space specifically for the DNS, e.g. for very
short-lived transactions.</t>
</section>
<section title="Notes to Readers">
<t>This is an incomplete proposal. It has been distributed
in its current form for the purposes of discussion, such that
the high-level approach can be considered amongst other
options in the general consideration of DNS privacy.</t>
<t>The authors have called out particular gaps in this document.
The authors are confident that there are many other gaps
that have not been mentioned. The absence of a description
of a gap in this document does not imply there is no gap.
Contents may have settled in transit. Your statutory rights
are not affected.</t>
<t>The origins of this document lie in a beer-soaked afternoon
conversation in the lobby bar of the Hilton Metropole,
London, UK. Should this document play any future part in
preserving human life or dignity, the authors recommend the
installation of a small but elegant brass plaque, the text
embossed upon which should naturally be encrypted.</t>
</section>
<section title="Nomenclature">
<t>The following terms used in this document are intended in
the sense described below, in the interests of avoiding
ambiguity. The definitions presented here are abridged and
tilted towards the subject matter of this document. For
more exhaustive treatment please consult <xref target="RFC1034"/>
and <xref target="RFC1035"/>.
<list style="hanging">
<t hangText="Authority Server">A DNS component that
provides authoritative responses on behalf of a Zone
Manager, typically in response to queries received from
Recursive Resolvers (q.v.); also known as "authoritative
server" and "authoritative-only server".</t>
<t hangText="Recursive Resolver">A DNS component that
finds answers for queries on behalf of a Stub Resolver
(q.v.). A Recursive resolver draws upon data stored in
a local cache and fills in where necessary using an
iterative process of sending relevant queries to Authority
Servers. A Recursive Resolver may be located on the
same host as its dependant Stub Resolver, or it may be
located on a different host and be used remotely across
a network by multiple Stub Resolvers.</t>
<t hangText="Stub Resolver">A DNS component, present on
a host used locally by an end user, that sends DNS
queries to and receives responses from a Recursive
Resolver (q.v.)</t>
<t hangText="Zone Manager">The party responsible for the
contents of a DNS zone, and consequently (directly or
indirectly) for the provisioning of the Authority Servers
(q.v.) for that zone.</t>
</list>
</t>
<t>The following terms are specific to this proposal, and are
used in this document accordingly. These are not terms commonly
used within the taxonomy of DNS. See <xref target="approach"/>
for more details.
<list style="hanging">
<t hangText="Entry Resolver">A component of a
Recursive Resolver service which accepts queries from
a Stub Resolver, encrypts the query towards one or more
Relay Resolvers and an Exit Resolver, and forwards
towards the first Relay Resolver.</t>
<t hangText="Relay Resolver">A component of a Recursive
Resolver service that accepts an encrypted query from
an Entry Resolver, decrypts it and forwards it to the
next Relay Resolver.</t>
<t hangText="Exit Resolver">The last Relay Resolver
in a chain of Relay Resolvers.</t>
</list>
</t>
</section>
<section title="General Approach" anchor="approach">
<t>For the purposes of this document, consider that the network
path between a Stub Resolver and a Recursive Resolver is
entirely trustworthy. The Recursive Resolver might run on the
same host as the Stub Resolver, for example, or might lie
within the same trust perimeter as the Stub Resolver in an
enterprise network.</t>
<t>A query received by an Entry Resolver is assigned a chain of
Relay Resolvers, the number and choice of which are decided
according to local policy. The Entry Resolver must have
available a public key and knowledge of and capability of
using the appropriate corresponding encryption algorithm
for each selected Relay Resolver along the chain.</t>
<figure>
<artwork><![CDATA[
,------. ,----------------.
| Stub | ----===----> | Entry Resolver |
`------' ^ `----------------'
|
`---- [ Standard-format DNS request ]
]]>
</artwork>
</figure>
<t>An Entry Resolver generates a symmetric session key and
encrypts it towards the Exit Resolver.</t>
<t>The Entry Resolver encrypts the query once for each
Relay Resolver on the selected chain, in order.</t>
<t>The Entry Resolver constructs a package that consists
of the encrypted session key and the multiply-encrypted
(onion-wrapped) query and forwards it to the first Relay
Resolver.</t>
<figure>
<artwork><![CDATA[
,----------------. ,------------------.
| Entry Resolver | ----===----> | Relay Resolver 1 |
`----------------' ^ `------------------'
|
`---- [ encrypted session key,
onion-wrapped query ]
]]>
</artwork>
</figure>
<t>Each Relay Resolver in the chain decrypts the query and
identifies from the result the next Relay Resolver in the
chain. The source of the query from the Relay Resolver's
perspective (the Entry Resolver, or the previous Relay
Resolver) is encrypted towards the Relay Resolver itself and
included in the package with the peeled query. The resulting
package is forwarded to the next Relay Resolver in the
chain.</t>
<figure>
<artwork><![CDATA[
,------------------. ,------------------.
| Relay Resolver 1 | ----===----> | Relay Resolver 2 |
`------------------' ^ `------------------'
|
`---- [ encrypted session key,
onion-wrapped query (peeled once),
onion-wrapped path (wrapped once) ]
]]>
</artwork>
</figure>
<t>A Relay Resolver that receives a package in which the query
component is encrypted only towards itself is the Exit
Resolver for this chain. The Relay Resolver decrypts the
query and follows the normal DNS Resolver process to obtain
a response.</t>
<figure>
<artwork><![CDATA[
,---------------. ,--------------------------.
| Exit Resolver | ----===----> | Various Authorit Servers |
`---------------' ^ `--------------------------'
| |
( local cache ) `---- [ standard-format DNS requests ]
]]>
</artwork>
</figure>
<t>The Exit Resolver obtains the session key from the original
package and encrypts the response using it. The Exit Resolver
then sends the package back down the chain, each Relay Resolver
in turn identifying the next hop for the package using the
directions it encrypted on the forward path.</t>
<figure>
<artwork><![CDATA[
,----------------------. ,---------------.
| Relay Resolver [i-1] | <---===---- | Exit Resolver |
`----------------------' ^ `---------------'
|
`--- [ encrypted response,
onion-wrapped path ]
]]>
</artwork>
</figure>
<t>Once the response is received by the Entry resolver, it is
decrypted with the session key and a response is dispatched
to the original stub resolver.</t>
<figure>
<artwork><![CDATA[
,---------------. ,----------------.
| Stub Resolver | <---===---- | Entry Resolver |
`---------------' ^ `----------------'
|
`--- [ standard-format DNS response ]
]]>
</artwork>
</figure>
</section>
<section title="Operational Considerations">
<t>An Entry Resolver might be primed with information about
a large number of candidate Relay Resolvers, together with
local policy relating to the minimum chain length required
for particular (or, e.g., any) outbound queries. An Entry
Resolver might build random chains from the available pool
of Entry Resolvers and select between them when dealing
with particular queries.</t>
<t>Care should be taken when re-using session keys for
particular Exit Resolvers, since repeated use of the same
session keys might be used to identify that different queries
originate from the same user. A sufficiently large pool of
candidate chains might provide an opportunity for session
key regeneration in parallel to query processing.</t>
<t>An Entry Resolver might be configured to send padding
queries down particular chains (e.g. CHAOS-class queries
that can be resolved cheaply on an Exit Resolver) in order
to reduce the opportunity to compare query frequency between
different Resolver Relays and make inferences about chain
construction by particular Entry Resolvers.</t>
<t>All Relay Resolvers ought to be usable as Exit Resolvers,
and hence every Relay Resolver has an opportunity to build
and maintain a DNS cache in the manner of a conventional
DNS Resolver. The cache of course will only be used in the
event that a particular Relay Resolver is acting as an Exit
Resolver for a particular chain.</t>
<t>It should be expected that particular Relay Resolvers will
become unavailable from time to time, e.g. due to scheduled
maintenance or unexpected device failure. Entry Resolvers
should time out and retry in the event that a chain is
broken, and should take observed failure into account when
building candidate chains for use for queries yet to be
sent.</t>
<t>There is no requirement for the communication between Entry
Resolvers and Relay Resolvers, or between Relay Resolvers,
to use the DNS protocol. We might imagine that communication
being made using modern APIs and dynamically-provisioned
pools of TCP sessions, for example. The only requirement
for the standard DNS protocol is between the Stub Resolver
and the Entry Resolver, and between the Exit Resolver and
Authority Servers.</t>
</section>
<section title="Security Considerations">
<t>This document describes an approach for improving the
privacy of the DNS, reducing opportunities to map an
end user identity to data present in the DNS queries
triggered by end user behaviour.</t>
<t>This document does not include an assessment of
the impact of the proposed approach on the use of the DNS
to launch denial of service (or other) attacks. Such analysis
seems prudent to include in future revisions of this document,
should there be interest in proceeding with it.</t>
<t>The ability of a chain of Relay Resolvers to provide privacy
for an Entry Resolver depends on choosing a chain that
crosses privacy domains (e.g. organisational or geopolitical
boundaries). This document is missing guidance on how this
might be done reliably.</t>
</section>
<section title="IANA Considerations">
<t>This document makes no request of the IANA.</t>
</section>
<section title="Acknowledgements">
<t>Many aspects of the approach described in this document
are similar or identical to the approach taken in the design
and implemnetation of The Onion Router <xref target="Tor"/>,
a project which has produced software that is widely-used
to protect end-user privacy.</t>
<t>Also, your name here, etc.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc1034;
&rfc1035;
</references>
<references title="Informative References">
&draft-bortzmeyer-dnsop-dns-privacy;
&draft-koch-perpass-dns-confidentiality;
<reference anchor="Tor">
<front>
<title>Tor Protocol Specification</title>
<author initials="R." surname="Dingledine" fullname="Roger Dingledine">
<organization/>
<address/>
</author>
<author initials="N." surname="Mathewson" fullname="Nick Mathewson">
<organization/>
<address/>
</author>
</front>
<format type="TXT" target="https://gitweb.torproject.org/torspec.git?a=blob_plain;hb=HEAD;f=tor-spec.txt"/>
</reference>
</references>
<section title="Editorial Notes">
<t>This section (and sub-sections) to be removed prior to
publication.</t>
<section title="Change History">
<t>
<list style="hanging">
<t hangText="00">Initial idea, circulated for the purposes of
entertainment.</t>
</list>
</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:25:14 |