draft-ietf-dprive-dnsodtls-13.txt   draft-ietf-dprive-dnsodtls-14.txt 
DPRIVE T. Reddy DPRIVE T. Reddy
Internet-Draft D. Wing Internet-Draft Cisco
Intended status: Experimental P. Patil Intended status: Experimental D. Wing
Expires: June 1, 2017 Cisco Expires: June 18, 2017
November 28, 2016 P. Patil
Cisco
December 15, 2016
Specification for DNS over Datagram Transport Layer Security (DTLS) Specification for DNS over Datagram Transport Layer Security (DTLS)
draft-ietf-dprive-dnsodtls-13 draft-ietf-dprive-dnsodtls-14
Abstract Abstract
DNS queries and responses are visible to network elements on the path DNS queries and responses are visible to network elements on the path
between the DNS client and its server. These queries and responses between the DNS client and its server. These queries and responses
can contain privacy-sensitive information which is valuable to can contain privacy-sensitive information which is valuable to
protect. protect.
This document proposes the use of Datagram Transport Layer Security This document proposes the use of Datagram Transport Layer Security
(DTLS) for DNS, to protect against passive listeners and certain (DTLS) for DNS, to protect against passive listeners and certain
skipping to change at page 1, line 40 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 1, 2017. This Internet-Draft will expire on June 18, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Relationship to TCP Queries and to DNSSEC . . . . . . . . 3 1.1. Relationship to TCP Queries and to DNSSEC . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Document Status . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Establishing and Managing DNS-over-DTLS Sessions . . . . . . 4 3. Establishing and Managing DNS-over-DTLS Sessions . . . . . . 4
3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 4 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 4
3.2. DTLS Handshake and Authentication . . . . . . . . . . . . 4 3.2. DTLS Handshake and Authentication . . . . . . . . . . . . 5
3.3. Established Sessions . . . . . . . . . . . . . . . . . . 5 3.3. Established Sessions . . . . . . . . . . . . . . . . . . 5
4. Performance Considerations . . . . . . . . . . . . . . . . . 6 4. Performance Considerations . . . . . . . . . . . . . . . . . 6
5. PMTU issues . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. PMTU issues . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . 11 11.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
The Domain Name System is specified in [RFC1034] and [RFC1035]. DNS The Domain Name System is specified in [RFC1034] and [RFC1035]. DNS
queries and responses are normally exchanged unencrypted and are thus queries and responses are normally exchanged unencrypted and are thus
vulnerable to eavesdropping. Such eavesdropping can result in an vulnerable to eavesdropping. Such eavesdropping can result in an
undesired entity learning domains that a host wishes to access, thus undesired entity learning domains that a host wishes to access, thus
resulting in privacy leakage. The DNS privacy problem is further resulting in privacy leakage. The DNS privacy problem is further
skipping to change at page 3, line 42 skipping to change at page 3, line 46
that desire Strict Privacy as described in that desire Strict Privacy as described in
[I-D.ietf-dprive-dtls-and-tls-profiles]. [I-D.ietf-dprive-dtls-and-tls-profiles].
DNS Security Extensions (DNSSEC [RFC4033]) provides object integrity DNS Security Extensions (DNSSEC [RFC4033]) provides object integrity
of DNS resource records, allowing end-users (or their resolver) to of DNS resource records, allowing end-users (or their resolver) to
verify legitimacy of responses. However, DNSSEC does not provide verify legitimacy of responses. However, DNSSEC does not provide
privacy for DNS requests or responses. DNS-over-DTLS works in privacy for DNS requests or responses. DNS-over-DTLS works in
conjunction with DNSSEC, but DNS-over-DTLS does not replace the need conjunction with DNSSEC, but DNS-over-DTLS does not replace the need
or value of DNSSEC. or value of DNSSEC.
1.2. Document Status
This document is an Experimental RFC. One key aspect to judge
whether the approach is usable on a large scale is by observing the
uptake, usability, and operational behavior of the protocol in large-
scale, real-life deployments.
This DTLS solution was considered by the DPRIVE working group as an
option to use in case the TLS based approach specified in [RFC7858]
turns out to have some issues when deployed. At the time of writing,
it is expected that [RFC7858] is what will be deployed, and so this
specification is mainly intended as a backup.
The following guidelines should be considered when performance
benchmarking DNS over DTLS:
1. DNS over DTLS can recover from packet loss and reordering, and
does not suffer from network head-of-line blocking. DNS over
DTLS performance in comparison with DNS over TLS may be better in
lossy networks.
2. The number of round trips to send the first DNS query over DNS
over DTLS is less than the number of round trips to send the
first DNS query over TLS. Even if TCP Fast Open is used, it only
works for subsequent TCP connections between the DNS client and
server (Section 3 in [RFC7413]).
3. If DTLS 1.3 protocol [I-D.rescorla-tls-dtls13] is used for DNS
over DTLS, it provides critical latency improvements for
connection establishment over DTLS 1.2.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119] . [RFC2119] .
3. Establishing and Managing DNS-over-DTLS Sessions 3. Establishing and Managing DNS-over-DTLS Sessions
3.1. Session Initiation 3.1. Session Initiation
skipping to change at page 5, line 48 skipping to change at page 6, line 30
server is quiescent, the DNS client MAY want to probe the server server is quiescent, the DNS client MAY want to probe the server
using DTLS heartbeat [RFC6520] to ensure it has maintained using DTLS heartbeat [RFC6520] to ensure it has maintained
cryptographic state. Such probes can also keep alive firewall or NAT cryptographic state. Such probes can also keep alive firewall or NAT
bindings. This probing reduces the frequency of needing a new bindings. This probing reduces the frequency of needing a new
handshake when a DNS query needs to be resolved, improving the user handshake when a DNS query needs to be resolved, improving the user
experience at the cost of bandwidth and processing time. experience at the cost of bandwidth and processing time.
A DTLS session is terminated by the receipt of an authenticated A DTLS session is terminated by the receipt of an authenticated
message that closes the connection (e.g., a DTLS fatal alert). If message that closes the connection (e.g., a DTLS fatal alert). If
the server has lost state, a DTLS handshake needs to be initiated the server has lost state, a DTLS handshake needs to be initiated
with the server. For the client, state should be destroyed when with the server. For the server, to mitigate the risk of
disconnecting from the network (e.g., associated IP interface is unintentional server overload, it is RECOMMENDED that the default
brought down). For the server, to mitigate the risk of unintentional DNS-over-DTLS server application-level idle time be set to several
server overload, it is RECOMMENDED that the default DNS-over-DTLS seconds and not set to less than a second, but no particular value is
server application-level idle time out be on the order of several specified. When no DNS queries have been received from the client
seconds, but no particular value is specified. When no DNS queries after idle time out, the server MUST send a DTLS fatal alert and then
have been received from the client after idle time out, the server destroy its DTLS state. The DTLS fatal alert packet indicates the
MUST send a DTLS fatal alert and then destroy its DTLS state. The server has destroyed its state, signaling to the client if it wants
DTLS fatal alert packet indicates the server has destroyed its state, to send a new DTLS message it will need to re-establish cryptographic
signaling to the client if it wants to send a new DTLS message it context with the server (via full DTLS handshake or DTLS session
will need to re-establish cryptographic context with the server (via resumption). In practice, the idle period can vary dynamically, and
full DTLS handshake or DTLS session resumption). In practice, the servers MAY allow idle connections to remain open for longer periods
idle period can vary dynamically, and servers MAY allow idle as resources permit.
connections to remain open for longer periods as resources permit.
Figure 1 shows DTLS handshake and issuing new session ticket for
session resumption.
Client Server
------ ------
ClientHello -------->
(empty SessionTicket extension)
ServerHello
(empty SessionTicket extension)
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
(ChangeCipherSpec)
Finished -------->
NewSessionTicket
(ChangeCipherSpec)
<-------- Finished
DNS Request --------->
<--------- DNS Response
Figure 1: Message Flow for Full Handshake Issuing New Session Ticket
4. Performance Considerations 4. Performance Considerations
DTLS protocol profile for DNS-over-DTLS is discussed in Section 11 of DTLS protocol profile for DNS-over-DTLS is discussed in Section 11 of
[I-D.ietf-dprive-dtls-and-tls-profiles]. To reduce the number of [I-D.ietf-dprive-dtls-and-tls-profiles]. To reduce the number of
octets of the DTLS handshake, especially the size of the certificate octets of the DTLS handshake, especially the size of the certificate
in the ServerHello (which can be several kilobytes), DNS clients and in the ServerHello (which can be several kilobytes), DNS clients and
servers can use raw public keys [RFC7250] or Cached Information servers can use raw public keys [RFC7250] or Cached Information
Extension [RFC7924]. Cached Information Extension avoids Extension [RFC7924]. Cached Information Extension avoids
transmitting the server's certificate and certificate chain if the transmitting the server's certificate and certificate chain if the
skipping to change at page 9, line 10 skipping to change at page 9, line 10
8. IANA Considerations 8. IANA Considerations
This specification uses port 853 already allocated in the IANA port This specification uses port 853 already allocated in the IANA port
number registry as defined in Section 6 of [RFC7858]. number registry as defined in Section 6 of [RFC7858].
9. Security Considerations 9. Security Considerations
The interaction between a DNS client and DNS server requires Datagram The interaction between a DNS client and DNS server requires Datagram
Transport Layer Security (DTLS) with a ciphersuite offering Transport Layer Security (DTLS) with a ciphersuite offering
confidentiality protection. The guidance given in [RFC7525] MUST be confidentiality protection. The guidance given in [RFC7525] MUST be
followed to avoid attacks on DTLS. DNS clients keeping track of followed to avoid attacks on DTLS. The DNS client SHOULD use the TLS
servers known to support DTLS enables clients to detect downgrade Certificate Status Request extension (Section 8 of [RFC6066]),
attacks. To interfere with DNS-over-DTLS, an on- or off-path commonly called "OCSP stapling" to check the revocation status of
attacker might send an ICMP message towards the DTLS client or DTLS public key certificate of the DNS server. OCSP stapling, unlike
server. As these ICMP messages cannot be authenticated, all ICMP OSCP, does not suffer from scale and privacy issues. DNS clients
errors should be treated as soft errors [RFC1122]. If the DNS query keeping track of servers known to support DTLS enables clients to
was sent over DTLS then the corresponding DNS response MUST only be detect downgrade attacks. To interfere with DNS-over-DTLS, an on- or
accepted if it is received over the same DTLS connection. This off-path attacker might send an ICMP message towards the DTLS client
behavior mitigates all possible attacks described in Measures for or DTLS server. As these ICMP messages cannot be authenticated, all
Making DNS More Resilient against Forged Answers [RFC5452]. Security ICMP errors should be treated as soft errors [RFC1122]. If the DNS
considerations in [RFC6347] and query was sent over DTLS then the corresponding DNS response MUST
only be accepted if it is received over the same DTLS connection.
This behavior mitigates all possible attacks described in Measures
for Making DNS More Resilient against Forged Answers [RFC5452].
Security considerations in [RFC6347] and
[I-D.ietf-dprive-dtls-and-tls-profiles] are to be taken into account. [I-D.ietf-dprive-dtls-and-tls-profiles] are to be taken into account.
A malicious client might attempt to perform a high number of DTLS A malicious client might attempt to perform a high number of DTLS
handshakes with a server. As the clients are not uniquely identified handshakes with a server. As the clients are not uniquely identified
by the protocol and can be obfuscated with IPv4 address sharing and by the protocol and can be obfuscated with IPv4 address sharing and
with IPv6 temporary addresses, a server needs to mitigate the impact with IPv6 temporary addresses, a server needs to mitigate the impact
of such an attack. Such mitigation might involve rate limiting of such an attack. Such mitigation might involve rate limiting
handshakes from a certain subnet or more advanced DoS/DDoS techniques handshakes from a certain subnet or more advanced DoS/DDoS techniques
beyond the scope of this paper. beyond the scope of this paper.
10. Acknowledgements 10. Acknowledgements
Thanks to Phil Hedrick for his review comments on TCP and to Josh Thanks to Phil Hedrick for his review comments on TCP and to Josh
Littlefield for pointing out DNS-over-DTLS load on busy servers (most Littlefield for pointing out DNS-over-DTLS load on busy servers (most
notably root servers). The authors would like to thank Simon notably root servers). The authors would like to thank Simon
Josefsson, Daniel Kahn Gillmor, Bob Harold, Ilari Liusvaara, Sara Josefsson, Daniel Kahn Gillmor, Bob Harold, Ilari Liusvaara, Sara
Dickinson, Christian Huitema, Stephane Bortzmeyer, Alexander Dickinson, Christian Huitema, Stephane Bortzmeyer, Alexander
Mayrhofer, Allison Mankin, Jouni Korhonen and Geoff Huston for Mayrhofer, Allison Mankin, Jouni Korhonen, Stephen Farrell, Mirja
discussions and comments on the design of DNS-over-DTLS. The authors Kuehlewind, Benoit Claise and Geoff Huston for discussions and
would like to give special thanks to Sara Dickinson for her help. comments on the design of DNS-over-DTLS. The authors would like to
give special thanks to Sara Dickinson for her help.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>. <http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>. November 1987, <http://www.rfc-editor.org/info/rfc1035>.
skipping to change at page 11, line 13 skipping to change at page 11, line 23
<http://www.rfc-editor.org/info/rfc7830>. <http://www.rfc-editor.org/info/rfc7830>.
11.2. Informative References 11.2. Informative References
[I-D.ietf-dprive-dtls-and-tls-profiles] [I-D.ietf-dprive-dtls-and-tls-profiles]
Dickinson, S., Gillmor, D., and T. Reddy, "Authentication Dickinson, S., Gillmor, D., and T. Reddy, "Authentication
and (D)TLS Profile for DNS-over-(D)TLS", draft-ietf- and (D)TLS Profile for DNS-over-(D)TLS", draft-ietf-
dprive-dtls-and-tls-profiles-07 (work in progress), dprive-dtls-and-tls-profiles-07 (work in progress),
October 2016. October 2016.
[I-D.rescorla-tls-dtls13]
Rescorla, E. and H. Tschofenig, "The Datagram Transport
Layer Security (DTLS) Protocol Version 1.3", draft-
rescorla-tls-dtls13-00 (work in progress), October 2016.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<http://www.rfc-editor.org/info/rfc1122>. <http://www.rfc-editor.org/info/rfc1122>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<http://www.rfc-editor.org/info/rfc6066>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA) Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165, Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011, RFC 6335, DOI 10.17487/RFC6335, August 2011,
<http://www.rfc-editor.org/info/rfc6335>. <http://www.rfc-editor.org/info/rfc6335>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport Transport Layer Security (TLS) and Datagram Transport
skipping to change at page 12, line 22 skipping to change at page 12, line 45
Tirumaleswar Reddy Tirumaleswar Reddy
Cisco Systems, Inc. Cisco Systems, Inc.
Cessna Business Park, Varthur Hobli Cessna Business Park, Varthur Hobli
Sarjapur Marathalli Outer Ring Road Sarjapur Marathalli Outer Ring Road
Bangalore, Karnataka 560103 Bangalore, Karnataka 560103
India India
Email: tireddy@cisco.com Email: tireddy@cisco.com
Dan Wing Dan Wing
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, California 95134
USA
Email: dwing@cisco.com
Email: dwing-ietf@fuggles.com
Prashanth Patil Prashanth Patil
Cisco Systems, Inc. Cisco Systems, Inc.
Bangalore Bangalore
India India
Email: praspati@cisco.com Email: praspati@cisco.com
 End of changes. 15 change blocks. 
74 lines changed or deleted 86 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/