draft-ietf-dprive-dnsodtls-12.txt   draft-ietf-dprive-dnsodtls-13.txt 
DPRIVE T. Reddy DPRIVE T. Reddy
Internet-Draft D. Wing Internet-Draft D. Wing
Intended status: Experimental P. Patil Intended status: Experimental P. Patil
Expires: March 12, 2017 Cisco Expires: June 1, 2017 Cisco
September 8, 2016 November 28, 2016
Specification for DNS over Datagram Transport Layer Security (DTLS) Specification for DNS over Datagram Transport Layer Security (DTLS)
draft-ietf-dprive-dnsodtls-12 draft-ietf-dprive-dnsodtls-13
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 40
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 March 12, 2017. This Internet-Draft will expire on June 1, 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
skipping to change at page 4, line 19 skipping to change at page 4, line 19
By default, DNS-over-DTLS MUST run over standard UDP port 853 as By default, DNS-over-DTLS MUST run over standard UDP port 853 as
defined in Section 8, unless the DNS server has mutual agreement with defined in Section 8, unless the DNS server has mutual agreement with
its clients to use a port other than 853 for DNS-over-DTLS. In order its clients to use a port other than 853 for DNS-over-DTLS. In order
to use a port other than 853, both clients and servers would need a to use a port other than 853, both clients and servers would need a
configuration option in their software. configuration option in their software.
The DNS client should determine if the DNS server supports DNS-over- The DNS client should determine if the DNS server supports DNS-over-
DTLS by sending a DTLS ClientHello message to port 853 on the server, DTLS by sending a DTLS ClientHello message to port 853 on the server,
unless it has mutual agreement with its server to use a port other unless it has mutual agreement with its server to use a port other
than port 853 for DNS-over-DTLS. Such another port MUST NOT be port than port 853 for DNS-over-DTLS. Such another port MUST NOT be port
53 but MAY be from the "first-come, first-served" port range. This 53 but MAY be from the "first-come, first-served" port range (User
recommendation against use of port 53 for DNS-over-DTLS is to avoid Ports [RFC6335], range 1024- 49151) . This recommendation against use
complication in selecting use or non-use of DTLS and to reduce risk of port 53 for DNS-over-DTLS is to avoid complication in selecting
of downgrade attacks. use or non-use of DTLS and to reduce risk of downgrade attacks.
A DNS server that does not support DNS-over-DTLS will not respond to A DNS server that does not support DNS-over-DTLS will not respond to
ClientHello messages sent by the client. If no response is received ClientHello messages sent by the client. If no response is received
from that server, and the client has no better round-trip estimate, from that server, and the client has no better round-trip estimate,
the client SHOULD retransmit the DTLS ClientHello according to the client SHOULD retransmit the DTLS ClientHello according to
Section 4.2.4.1 of [RFC6347]. After 15 seconds, it SHOULD cease Section 4.2.4.1 of [RFC6347]. After 15 seconds, it SHOULD cease
attempts to re-transmit its ClientHello. The client MAY repeat that attempts to re-transmit its ClientHello. The client MAY repeat that
procedure to discover if DNS-over-DTLS service becomes available from procedure to discover if DNS-over-DTLS service becomes available from
the DNS server, but such probing SHOULD NOT be done more frequently the DNS server, but such probing SHOULD NOT be done more frequently
than every 24 hours and MUST NOT be done more frequently than every than every 24 hours and MUST NOT be done more frequently than every
skipping to change at page 8, line 18 skipping to change at page 8, line 18
encrypted and authenticated transport) but MAY fallback to encrypted and authenticated transport) but MAY fallback to
intermediate cases and eventually the worst case scenario (clear intermediate cases and eventually the worst case scenario (clear
text) in order to obtain a response. text) in order to obtain a response.
6. Anycast 6. Anycast
DNS servers are often configured with anycast addresses. While the DNS servers are often configured with anycast addresses. While the
network is stable, packets transmitted from a particular source to an network is stable, packets transmitted from a particular source to an
anycast address will reach the same server that has the cryptographic anycast address will reach the same server that has the cryptographic
context from the DNS-over-DTLS handshake. But when the network context from the DNS-over-DTLS handshake. But when the network
configuration changes, a DNS-over-DTLS packet can be received by a configuration or routing changes, a DNS-over-DTLS packet can be
server that does not have the necessary cryptographic context. To received by a server that does not have the necessary cryptographic
encourage the client to initiate a new DTLS handshake, DNS servers context. Clients using DNS-over-DTLS need to always be prepared to
SHOULD generate a DTLS fatal alert message in response to receiving a re-initiate DTLS handshake and in the worst case this could even
DTLS packet for which the server does not have any cryptographic happen immediately after re-initiating a new handshake. To encourage
context. Upon receipt of an un-authenicated DTLS fatal alert, the the client to initiate a new DTLS handshake, DNS servers SHOULD
DTLS client validates the fatal alert is within the replay window generate a DTLS fatal alert message in response to receiving a DTLS
packet for which the server does not have any cryptographic context.
Upon receipt of an un-authenicated DTLS fatal alert, the DTLS client
validates the fatal alert is within the replay window
(Section 4.1.2.6 of [RFC6347]). It is difficult for the DTLS client (Section 4.1.2.6 of [RFC6347]). It is difficult for the DTLS client
to validate that the DTLS fatal alert was generated by the DTLS to validate that the DTLS fatal alert was generated by the DTLS
server in response to a request or was generated by an on- or off- server in response to a request or was generated by an on- or off-
path attacker. Thus, upon receipt of an in-window DTLS fatal alert, path attacker. Thus, upon receipt of an in-window DTLS fatal alert,
the client SHOULD continue re-transmitting the DTLS packet (in the the client SHOULD continue re-transmitting the DTLS packet (in the
event the fatal alert was spoofed), and at the same time it SHOULD event the fatal alert was spoofed), and at the same time it SHOULD
initiate DTLS session resumption. When the DTLS client receives an initiate DTLS session resumption. When the DTLS client receives an
authenticated DNS response from one of those DTLS sessions, the other authenticated DNS response from one of those DTLS sessions, the other
DTLS session should be terminated. DTLS session should be terminated.
skipping to change at page 9, line 38 skipping to change at page 9, line 38
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 and Geoff Huston for discussions and Mayrhofer, Allison Mankin, Jouni Korhonen and Geoff Huston for
comments on the design of DNS-over-DTLS. The authors would like to discussions and comments on the design of DNS-over-DTLS. The authors
give special thanks to Sara Dickinson for her help. 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
skipping to change at page 11, line 10 skipping to change at page 11, line 10
[RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830,
DOI 10.17487/RFC7830, May 2016, DOI 10.17487/RFC7830, May 2016,
<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-03 (work in progress), July dprive-dtls-and-tls-profiles-07 (work in progress),
2016. 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>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011,
<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
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <http://www.rfc-editor.org/info/rfc7250>. June 2014, <http://www.rfc-editor.org/info/rfc7250>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<http://www.rfc-editor.org/info/rfc7413>. <http://www.rfc-editor.org/info/rfc7413>.
 End of changes. 8 change blocks. 
20 lines changed or deleted 30 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/