[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/