Network Working Group P. Hoffman
Internet-Draft VPN Consortium
Intended status: Standards Track December 8, 2010
Expires: June 11, 2011
Wrapping Last-Hop DNS for Traffic Protection
draft-hoffman-dns-last-hop-01
Abstract
DNS queries from one resolver to an upstream resolver are often run
over connections with no protection of any kind. The stub resolvers
that initiate queries for an application are ofte called "last-hop",
and their queries go to trusted recursive resolvers. The connection
between last-hop resolvers and their upstream resolver is currently
susceptible to both malicious and unintentional alteration that
prevents the querying resolver from being sure that the results it
receives are valid. Some middleboxes can prevent a stub resolver,
even one that does DNSSEC validation, from getting enough information
to validate a response. Further, a non-validating stub resolver is
susceptible to active attacks in which the results are purposely
altered.
The protocol described in this document provides a method to avoid
these problems and thus make resolution significantly more secure.
This protocol can be used between any two DNS resolvers, but the
focus of this document is on last-hop resolvers.
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 June 11, 2011.
Copyright Notice
Hoffman Expires June 11, 2011 [Page 1]
Internet-Draft Wrapping Last-Hop DNS December 2010
Copyright (c) 2010 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.
1. Introduction
In the original specification of DNS (which is broadly defined in
[RFC1034], [RFC1035], and others), queries travel between a resolver
and a server without any cryptographic integrity protection. DNSSEC
(which is broadly defined in RFCs 4033, 4034, and 4035 ([RFC4033],
[RFC4034], and [RFC4035]) adds integrity protection of the response
message and thus allows a validating resolver to verify that a
message has not been altered in transit.
RFCs 1034, 1035, and 4033 have many definitions that apply to the
discussion here. The term "resolver" is defined in RFC 1034. A
"stub resolver" is a resolver that sends queries in recursive mode to
a recursive resolver, but does not do recursion itself. In the
context of these definitions, "security-aware" means supports the
EDNS0 message size extension from [RFC2671] and the DO bit from
[RFC3225], and supports the RR types and message header bits defined
in the DNSSEC documents. A "security-aware resolver" is an entity
that acts as a resolver and that understands DNSSEC. Two types of
stub resolvers are discussed in this document. A "validating stub
resolver" is a security-aware resolver that sends queries in
recursive mode but that performs signature validation on its own
rather than just blindly trusting an upstream security-aware
recursive name server. A "non-validating stub resolver" is a
security-aware resolver that trusts one or more security-aware
recursive name servers to perform DNSSEC validation on its behalf.
In typical deployments of DNS, there is a stub resolver that is the
original source of the DNS query. This query usually traverses one
or more recursive DNS servers on its way to the authoritative server
for the data. DNSSEC provides a mode (using the AD bit) in which a
security-aware but non-validating resolver (usually a stub resolver)
may trust that the data it receives has been validated, but only if
the connection between it and the upstream resolver that applied the
Hoffman Expires June 11, 2011 [Page 2]
Internet-Draft Wrapping Last-Hop DNS December 2010
AD bit is secured with cryptographic integrity protection. It is
currently not clear how useful the AD bit will be in practice, but
without a secured connection between the stub resolver and the
validating resolver at the next hop, it is certainly useless.
A challenge facing deployment of DNSSEC is that non-validating stub
resolvers often have no way of trusting their connection to the
validating resolver at the next hop. Worse, for a client that wants
to do its own validation, some ISPs block or otherwise alter traffic
on the DNS port, so that it is not possible to receive an unaltered
response that will pass DNSSEC validation. Other challenges include
travelling users who are behind firewalls that modify DNS requests
and responses, and only allow access to ports 80 and 443.
1.1. Known Problems with Intermediaries and Attackers
DNS intermediaries have been found to cause a number of tenacious and
difficult-to-solve problems. An intermediary might change a query
traversing it, might redirect the query to a different resolver,
might alter a response coming back to a query, might try to parse a
query or response and drop it if the intermediary doesn't understand
it, or a combination of two or more of the above. [RFC5625] talks
about some of the many ways that intermediaries have been known to
make DNS resolution unstable (and, in some cases, unusable).
Attackers have shown great creativity in finding ways to spoof DNS
responses. [RFC5452] describes some of these, but more are being
discovered at a frequent pace. Spoofing does not affect DNS
responses that are protected by DNSSEC that are sent to resolvers
that validate; note, however, that non-validating resolvers,
particularly non-validating stub resolvers, are quite common. Also
note that this document only tries to prevent active attacks, and
does not attempt to deal with denial-of-service (DoS) attacks on
resolvers.
1.2. Proposed Solution
This document defines a method to tunnel in TLS [RFC5246] DNS traffic
that is wrapped in HTTP [RFC2616]. Although these might at first
seem like an ugly hack, they achieve the following goals:
o Hiding DNS traffic from intermediaries that change DNS requests
and/or responses on port 53
o Cryptographic integrity protection for DNS responses sent to non-
validating resolvers
Hoffman Expires June 11, 2011 [Page 3]
Internet-Draft Wrapping Last-Hop DNS December 2010
o Easy implementation in resolvers using existing toolkits and
software
o No changes to the DNS, HTTP, PKIX, or TLS protocols
o Does not require that the responding resolvers run DNS protocols
such as SIG(0) and TKEY that are open to trivial denial-of-service
attacks.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Description of the Protocol
This section defines the a protocol that first wraps encoded DNS in
HTTP, then tunnels wrapped DNS in TLS.
The following steps are used by the querying resolver to create and
send wrapped queries from one DNS resolver to a second resolver:
1. Start with the binary query that would have been sent to the
second resolver.
2. Create a 128-bit nonce. Prepend it to the binary query from the
previous step.
3. Encode the combined nonce-and-query with base64, as described in
Section 4 of [RFC4648]. This results in a string of ASCII
characters.
4. Create a URI with a path component consisting of "/.well-known/
dnsreq/" prepended to the encoded nonce-and-query. (The "/.well-
known/" prefix comes from [RFC5785]; the string "dnsreq" is
registered with IANA later in this document.)
5. If a TLS session to the second resolver is already set up, that
session is reused. If not, start a TLS session on port 443 with
the second resolver. The querying resolver MUST verify that the
TLS session is set up correctly before continuing.
6. Send an HTTP GET request with the URI from the previous step in
the TLS tunnel. This request has an empty message body. Wait
for the HTTP response.
Responding resolvers listen for TLS queries on TCP port 443. As
appropriate, they leave the TLS session open to handle further
Hoffman Expires June 11, 2011 [Page 4]
Internet-Draft Wrapping Last-Hop DNS December 2010
requests from the same client after the HTTP response is sent.
The following steps are used by the responding resolver to create and
send wrapped responses to wrapped queries that come in from the HTTP
GET request:
1. Strip off the "/.well-known/dnsreq/" preamble. If that preamble
is not present in the request, then the request is for a
different service and should be handled by that service.
2. The request to process is the remainder after stripping the
preamble. Decode the request to process using base64. The first
128 bits of the decoded request is a nonce, and the rest is a DNS
query.
3. Process the DNS request as one would any DNS request, as
described in the DNS (and possibly DNSSEC) protocol documents.
The result is a binary DNS response
4. Prepend the nonce to DNS response from the previous step and
encode the resulting nonce-and-response using base64.
5. Respond to the HTTP request using a status code of 200, a media
type of "text/plain", and the encoded DNS nonce-and-response in
the HTTP response body. In order to help prevent overloading of
any HTTP cache that may be between the HTTP server and client,
the HTTP response SHOULD include a "Cache-Control" general-header
field with the "no-store" directive, as described in RFC 2616.
The HTTP status code returned in the response is important to the
querying resolover.
o Every DNS response MUST always be sent with an HTTP status code of
200 ("OK"). For example, even if the DNS response that is encoded
is SERVFAIL or NXDOMAIN, the HTTP status code is still 200.
Another way to look at this is if the HTTP service actually
executes a query, the result will have an HTTP status code of 200.
This design prevents the protocol from having to state one-by-one
which DNS responses are "significant enough" errors to warrant an
HTTP status code from the 4xx family.
o If the HTTP server knows that it cannot do the above processing,
the HTTP response code MUST be 503 ("Service Unavailable"). An
example of this would be if the HTTP server is up but that server
knows that the DNS resolver service is down or cannot be reached
from the HTTP server.
Hoffman Expires June 11, 2011 [Page 5]
Internet-Draft Wrapping Last-Hop DNS December 2010
o The HTTP server MAY send a status code in the 3xx family if the
server has been moved to a different location; however, note that
the client might not be able to follow this redirection,
particularly if the location is given with a host name instead of
an IP address.
o Other HTTP-level error conditions (such as malformed request
message, unexpected server-side problems, and so on) may yield
other responses in the 4xx (client error) and 5xx (server error)
range.
There are two possible types of HTTP responses, differentiated by the
HTTP status code in the response. The originating DNS resolver acts
differently for the two types of responses.
o If the response has an HTTP status code of 200, the body of the
HTTP response contains a single body part that is plain text.
Decode the text using base64: the result of decoding is the 128-
bit nonce followed by the DNS response. Validate that the nonce
received is the same as the nonce that was sent; if not, ignore
the response.
o If the response has an HTTP status code of anything other than
200, the HTTP message body of the response can be ignored, and the
only the HTTP status code (and possibly the HTTP status reason) is
used by the querying resolver.
In order for the resolver to communicate over TLS to the second
resolver using this protocol, the querying resolver needs a trust
anchor to which the certificate proffered by the TLS server will
chain. Without such a trust anchor, the TLS session will not start.
To reduce processing stress on the client and server, and to reduce
DNS query times, TLS sessions SHOULD be long-lived. Further, for the
same reason, TLS clients and servers SHOULD support TLS session
resumption [RFC5077].
3. IANA Considerations
This document requests a new registration for a well-known URI, as
defined in RFC 5785. The registration template is:
URI suffix: dnsreq
Change controller: IETF (when approved)
Specification document(s): This document
Hoffman Expires June 11, 2011 [Page 6]
Internet-Draft Wrapping Last-Hop DNS December 2010
4. Security Considerations
The security considerations for the protocol are the same as those
for TLS.
It is important to note that the nonce is only used to prevent cached
HTTP responses from being served, not to prevent replay attacks in
the inner HTTP protocol. If the inner HTTP queries and responses are
cached, and the client reuses a nonce with the same DNS query, it
could receive an out-of-date response instead of a fresh response.
The use of fresh random nonces prevents this problem.
5. Acknowledgements
The ideas of wrapping DNS in HTTP-in-TLS have been discussed in many
places by many people for a long time; the author of this document
comes to the discussion quite late.
Andrew Sullivan did an early review of this document and contributed
some of the text. Julian Reschke gave some good suggestions for the
HTTP handling. Suggestions to ditch the HTTP-without-TLS protocol in
an earlier draft came from many people.
6. References
6.1. 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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
Hoffman Expires June 11, 2011 [Page 7]
Internet-Draft Wrapping Last-Hop DNS December 2010
6.2. Informative References
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
RFC 2671, August 1999.
[RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56,
RFC 3205, February 2002.
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC",
RFC 3225, December 2001.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, January 2008.
[RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More
Resilient against Forged Answers", RFC 5452, January 2009.
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines",
BCP 152, RFC 5625, August 2009.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
Uniform Resource Identifiers (URIs)", RFC 5785,
April 2010.
Appendix A. Appropriateness of Using HTTP as a Substrate
[RFC3205] describes best practices for using HTTP as a substrate,
such as is done in this document. The following is an approximate
checklist of how this protocol matches those practices. The section
numbers are those from RFC 3205.
o 2.1: The complexity of HTTP is not significant here because
standard clients and servers are used. No new headers or status
codes are introduced, and normal HTTP paradigms like content
Hoffman Expires June 11, 2011 [Page 8]
Internet-Draft Wrapping Last-Hop DNS December 2010
encoding are handled in their standard fashion.
o 2.2: The overhead is minimal for the size of DNS requests and
responses.
o 2.3: The inner HTTP protocol does not expect to add any security
to DNS. Authentication of the server in the full protocol is
provided by TLS. Authentication of the client in the full
protocol is not needed for DNS, although admission control to the
server can be achieved in this protocol in the same way that it is
for typical DNS, namely by IP address.
o 2.4: Compatibility with proxies, firewalls, and NATs is maximized
by using TLS on port 443 in the protocol. Even if the HTTP in the
inner protocol interacts with caching proxies, the nonce will
cause caching proxies to never have repeated queries, and the
SHOULD-level directive to include a "Cache-Control" general-header
field with the "no-store" directive reduces the chance that HTTP-
compliant proxies will be burdened by the high overhead of
queries.
o 2.5, bullet 1: The payload size is only slightly increased, and
DNS queries and response patterns can be similar to those seen on
popular web sites.
o 2.5, bullet 2: This protocol is not meant to be used by web
browsers.
o 2.5, bullet 3: Additional authentication is not needed in the
inner HTTP protocol, and TLS adds the needed authentication for
the full protocol.
o 2.5, bullet 4: Current HTTP status codes are fine for this
protocol.
o 2.5, bullet 5: DNS servers do not normally support HTTP or other
public-facing protocols.
o 3: The inner HTTP described in the protocol is not a substantially
new service. It uses normal HTTP with the only significant
restriction being on which response codes are used.
o 4: The http: and https: schemes are not expected to be used here.
Instead, the HTTP requests that are wrapped in TLS are used
directly.
o 5, bullet 1: An existing media type is used.
Hoffman Expires June 11, 2011 [Page 9]
Internet-Draft Wrapping Last-Hop DNS December 2010
o 5, bullet 2: There is no need for multipart or messages when
wrapping a DNS response.
o 5, bullet 3: Electronic mail is not a consideration here.
o 5, bullet 4: There is only one set of semantics for bodies in
responses.
o 6: The GET method is used.
o 7: All existing client and server toolkits should be able to
handle the few limitations in the protocol.
o 8: HTTP status codes are used as-is, and no new ones are created
for the protocol.
Author's Address
Paul Hoffman
VPN Consortium
Email: paul.hoffman@vpnc.org
Hoffman Expires June 11, 2011 [Page 10]