Internet DRAFT - draft-zuo-dprive-encryption-over-udp
draft-zuo-dprive-encryption-over-udp
DPRIVE P. Zuo
Internet-Draft H. Li
Intended status: Informational N. Kong
Expires: January 3, 2016 X. Lee
G. Deng, Ed.
J. Yao, Ed.
N. Wang, Ed.
CNNIC
July 2, 2015
Approach on encrypting DNS message over UDP
draft-zuo-dprive-encryption-over-udp-00
Abstract
This document offers an approach to encrypt DNS queries and responses
between the stub resolver and the recursive server over UDP to
protect user privacy. The public key of the recursive server is
distributed to the stub resolver through the Certificate Authority
infrastructure, and the public key of the stub resolver is sent to
the recursive server together with the DNS query where the public key
is inserted to the additional section of the DNS query. Then the
recursive server encrypts the DNS responses sent to the stub resolver
with the public key of that stub resolver, and similarly the DNS
query sent to the recursive server is encrypted by the stub resolver
with the public key of that recursive server and thus the user
privacy is protected.
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 January 3, 2016.
Zuo, et al. Expires January 3, 2016 [Page 1]
Internet-Draft dns encryption over UDP July 2015
Copyright Notice
Copyright (c) 2015 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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol changes . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Encryption flag . . . . . . . . . . . . . . . . . . . . . 3
2.2. Public key of the stub resolver . . . . . . . . . . . . . 4
2.3. Use by the stub resolver . . . . . . . . . . . . . . . . 5
2.4. Use by the recursive server . . . . . . . . . . . . . . . 6
3. Performance Considerations . . . . . . . . . . . . . . . . . 7
4. IANA consideration . . . . . . . . . . . . . . . . . . . . . 7
5. Security considerations . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
Zuo, et al. Expires January 3, 2016 [Page 2]
Internet-Draft dns encryption over UDP July 2015
1. Introduction
Nowadays, almost all DNS queries and responses between the stub
resolver and the recursive server are sent unencrypted, which makes
the user privacy (in terms of query names and source IPs) vulnerable
to attackers that has access to the network channel. Towards this
issue, multiple methods are proposed to protect the user privacy.
DNSCurve [draft-dempsky-dnscurve] defines a method to add
confidentiality to the link between DNS clients and servers with a
new cryptographic protocol; ConfidentialDNS
[draft-wijngaards-confidentialdns] and IPSECA
[draft-osterweil-dane-ipsec] use opportunistic encryption to offer
privacy for DNS queries and responses. Unlike these three methods,
DNS-over-TLS [draft-ietf-dprive-start-tls-for-dns] and DNS-over-DTLS
[draft-ietf-dprive-dnsodtls] use existing standard protocols such as
TLS and DTLS to fully encrypt the DNS queries and responses and these
two approaches attract much attention now. However, DNS service is
latency sensitive, for many other Internet applications such as web
browsing and E-mail begin with DNS resolution. And thus how to
encrypt the DNS queries and responses with low DNS latency becomes
one issue that needs more consideration. In this draft, one
encryption approach is proposed to provide fully as well as
opportunistic encryption for DNS queries and responses without
additional transmission latency. In this approach, the asymmetric
encryption technology is used where the stub resolver and recursive
server generate their own private and public keys independently. The
public key of the recursive server is distributed to stub resolver
through Certificate Authority infrastructure [RFC5280] while that of
the stub resolver is sent to the recursive server together with the
DNS query packet where a public key encapsulation method is built so
that the public key can be inserted into the additional section of
the DNS query.
1.1. Terminology
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 [RFC2119].
2. Protocol changes
2.1. Encryption flag
To upgrade the current unencrypted DNS into encrypted one, one
encryption flag is needed for both stub resolver and recursive server
to check whether one DNS message is encrypted or not. In this draft,
the first octet after the Header of the DNS message is extended to be
one encryption flag. Specifically, if the value of the above octet
Zuo, et al. Expires January 3, 2016 [Page 3]
Internet-Draft dns encryption over UDP July 2015
is not larger than 63, both the stub resolver and the recursive serve
process the DNS message just as usual. If the value of the first
octet is larger than 64 (255, for instance), the corresponding DNS
message is an encrypted one, which should be processed just as
described in the following sections. Of course, for those stub
resolvers and recursive servers that do not support the encryption
approach proposed in this draft, the encrypted DNS message should be
discarded.
2.2. Public key of the stub resolver
The public key of the stub resolver is appended to the RDATA part of
EDNS0 meta-RR as one OPTION in the DNS query sent by the stub
resolver to the recursive server. The encapsulation of the public
key is shown in figure 1. Just as defined in [RFC6891], the public
key is formatted into three parts, namely the option-code (16 bits),
option-length (16bits) and option-data (variable length) for the
public key. And the option-code needs to be assigned according to
[RFC6891].
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0: | option-code for the public key |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2: | option-length for the public key |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
4: | |
/ option-data for the public key /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--
Figure 1. The encapsulation of the public key of stub resolver
The format of the option-data for the public key is shown in figure
2. The first 16 bits is named as Algorithm and is used to specify
the specific encryption algorithm that is supported. The next 16
bits is reserved as flag for future use. And then the last part is
the actet string of the corresponding public key.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm | flag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Public Key /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. The structure of the public key
Zuo, et al. Expires January 3, 2016 [Page 4]
Internet-Draft dns encryption over UDP July 2015
2.3. Use by the stub resolver
The stub resolver can independently determine whether to encrypt the
DNS queries or not. If the query name is very common and not
relating to user privacy, the stub resolver can do name resolution
through traditional unencrypted way and thus does not need to
implement the approach proposed in this draft. While if the query
name relates to user privacy, the stub resolver can use the method
presented in this draft to encrypt the DNS queries. And accordingly,
the recursive server also encrypts the DNS response with the public
key extracted from the DNS query.
The process of the stub resolver encrypting the DNS query is as
follows. First, the stub resolver needs to configure the public key
of the corresponding recursive server through the current Certificate
Authority infrastructure [RFC5280]. Second, the stub resolver
generates the normal DNS query (namely unencrypted one) and then
extracts all the parts after the DNS query Header and encrypts them
with the public key of the recursive server. Third, add a prefix of
three octets before the encrypted content where the first octet is
the encryption flag just as shown in the previous section while the
other two octets are used to store the length of the encrypted
content. Fourth, append the above content (namely a three bytes of
prefix plus the encrypted content) to the DNS query Header and thus
the encrypted DNS query is formed, just as shown in figure 3.
If the stub resolver encrypts the DNS query, the recursive server
must encrypt the corresponding DNS response whose format is the same
as shown in figure 3. And the process of encrypting the DNS response
by the recursive server is shown in the following section. The
process of processing the DNS response at the stub resolver side is
as follows. First, check the Encryption flag. If it is less than
64, the DNS response is processed just as usual; otherwise, the DNS
response must be encrypted one and the corresponding decryption
process is as follows. First, extract the encrypted content with the
help of the Length field and decrypts the encrypted content with the
public key of the recursive server. Third, append the decrypted
content to the Header of the DNS response and thus the original DNS
response is formed.
The structure of the encrypted DNS query is as follows: the
Zuo, et al. Expires January 3, 2016 [Page 5]
Internet-Draft dns encryption over UDP July 2015
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ /
/ Header /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Encryption flag | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Length | /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ encrypted content /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 3. The structure of the encrypted DNS message
2.4. Use by the recursive server
When receiving one DNS query where the Encryption flag is not larger
than 63, the recursive server process the DNS query just as usual.
While if the Encryption flag is larger than 63, the recursive server
can throw away the DNS query if it does not support the mechanism
proposed in this draft; otherwise, the recursive server processes the
DNS query like this: extract the encrypted content with the
indication of Length field shown in figure 3 and decrypts them with
the private key of the recursive server. Then the recursive server
combines the Header of the DNS query and the decrypted content and
thus the original DNS query is formed. Note that the public key of
the stub resolver is available in the decrypted DNS query and thus
the recursive server can obtain it easily.
After obtaining the original DNS query, the recursive server executes
normal DNS lookups and then forms the corresponding unencrypted DNS
response. If the DNS query received by the recursive server is
encrypted, then the corresponding DNS response also should be
encrypted. The way to encrypt the DNS response is as follows: first,
the recursive server encrypts all the parts of the DNS response
except the Header with the public key of the stub resolver. Second,
add a prefix of three octets to the encrypted content where one octet
is the encryption flag while the other two octets are for the length
of the encrypted content in terms of byte. Third, append above
content to the Header of the DNS response and thus the encrypted DNS
response is formed.
Zuo, et al. Expires January 3, 2016 [Page 6]
Internet-Draft dns encryption over UDP July 2015
3. Performance Considerations
Additional DNS message transmission delay is not added by the method
proposed in this draft since the public key of the stub resolver is
inserted into the DNS query as one part of it. Higher CPU usage is
caused by the use of the encryption and decryption with asymmetric
keys. The recursive server can choose to discard the new DNS query
if the CPU limit is exceeded. More bandwidth is needed because the
DNS message is increased due to the insertion of the public key of
the stub resolver to the DNS query message. Also the encryption of
the DNS message enlarges both the DNS query and response.
4. IANA consideration
This draft extends the first octet after the Header of each DNS
message to indicate whether the DNS message is encrypted or not.
IANA is requested to assign one new value (255, for instance) for the
above octet as the flag of DNS message encryption. Also, IANA is
requested to assign the option code for the public key of the stub
resolver in the EDNS0 meta-RR.
5. Security considerations
The encrypted DNS message may be blocked by the middleware devices
such as the firewall which does not support the method proposed in
this draft. The recursive server becomes a bit more vulnerable due
to higher CPU usage caused by the encryption of DNS responses
especially when the DDOS attack occurs.
6. References
6.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[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.
Zuo, et al. Expires January 3, 2016 [Page 7]
Internet-Draft dns encryption over UDP July 2015
[RFC4560] Quittek, J. and K. White, "Definitions of Managed Objects
for Remote Ping, Traceroute, and Lookup Operations", RFC
4560, June 2006.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891, April 2013.
6.2. Informative References
[draft-dempsky-dnscurve]
Dempsky, M., "DNSCurve: Link-Level Security for the Domain
Name System", August 2010,
<http://tools.ietf.org/html/draft-dempsky-dnscurve-01>.
[draft-ietf-dprive-dnsodtls]
Reddy, T., "DNS over DTLS", June 2015,
<http://datatracker.ietf.org/doc/
draft-ietf-dprive-dnsodtls/>.
[draft-ietf-dprive-start-tls-for-dns]
Hu, Z., "TLS for DNS", May 2015,
<http://datatracker.ietf.org/doc/
draft-ietf-dprive-start-tls-for-dns/>.
[draft-osterweil-dane-ipsec]
Osterweil, E., "Opportunistic Encryption with DANE
Semantics and IPsec: IPSECA", February 2014,
<http://tools.ietf.org/html/
draft-osterweil-dane-ipsec-00>.
[draft-wijngaards-confidentialdns]
Wijngaards, W., "Confidential DNS", March 2015,
<http://tools.ietf.org/html/
draft-wijngaards-dnsop-confidentialdns-03>.
Authors' Addresses
Zuo, et al. Expires January 3, 2016 [Page 8]
Internet-Draft dns encryption over UDP July 2015
Peng Zuo
CNNIC
4 South 4th Street, Zhongguancun, Haidian District
Beijing, Beijing 100190
China
Phone: +86 10 5881 2629
Email: zuopeng@cnnic.cn
Hongtao Li
CNNIC
4 South 4th Street, Zhongguancun, Haidian District
Beijing, Beijing 100190
China
Phone: +86 10 5881 3164
Email: lihongtao@cnnic.cn
Ning Kong
CNNIC
4 South 4th Street, Zhongguancun, Haidian District
Beijing, Beijing 100190
China
Phone: +86 10 5881 3147
Email: xx@cnnic.cn
Xiaodong Lee
CNNIC
4 South 4th Street, Zhongguancun, Haidian District
Beijing, Beijing 100190
China
Phone: +86 10 5881 3020
Email: xl@cnnic.cn
Guangqing Deng (editor)
CNNIC
4 South 4th Street, Zhongguancun, Haidian District
Beijing, Beijing 100190
China
Phone: +86 10 5881 3680
Email: dengguangqing@cnnic.cn
Zuo, et al. Expires January 3, 2016 [Page 9]
Internet-Draft dns encryption over UDP July 2015
Jiankang Yao (editor)
CNNIC
4 South 4th Street, Zhongguancun, Haidian District
Beijing, Beijing 100190
China
Phone: +86 10 5881 3007
Email: yaojiankang@cnnic.cn
Nan Wang (editor)
CNNIC
4 South 4th Street, Zhongguancun, Haidian District
Beijing, Beijing 100190
China
Phone: +86 10 5881 3275
Email: wangnan@cnnic.cn
Zuo, et al. Expires January 3, 2016 [Page 10]
