draft-ietf-dprive-dnsodtls-04.txt   draft-ietf-dprive-dnsodtls-05.txt 
DPRIVE T. Reddy DPRIVE T. Reddy
Internet-Draft D. Wing Internet-Draft D. Wing
Intended status: Standards Track P. Patil Intended status: Standards Track P. Patil
Expires: July 24, 2016 Cisco Expires: September 16, 2016 Cisco
January 21, 2016 March 15, 2016
DNS over DTLS (DNSoD) DNS over DTLS (DNSoD)
draft-ietf-dprive-dnsodtls-04 draft-ietf-dprive-dnsodtls-05
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. An active attacker can send bogus responses causing protect. An active attacker can send bogus responses causing
misdirection of the subsequent connection. misdirection of the subsequent connection.
To counter passive listening and active attacks, this document To counter passive listening and active attacks, this document
skipping to change at page 1, line 42 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 July 24, 2016. This Internet-Draft will expire on September 16, 2016.
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 2, line 28 skipping to change at page 2, line 28
1.1. Relationship to TCP Queries and to DNSSEC . . . . . . . . 3 1.1. Relationship to TCP Queries and to DNSSEC . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. DTLS session initiation, Polling and Discovery . . . . . . . 3 3. DTLS session initiation, Polling and Discovery . . . . . . . 3
4. Performance Considerations . . . . . . . . . . . . . . . . . 4 4. Performance Considerations . . . . . . . . . . . . . . . . . 4
5. Established sessions . . . . . . . . . . . . . . . . . . . . 5 5. Established sessions . . . . . . . . . . . . . . . . . . . . 5
6. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Downgrade attacks . . . . . . . . . . . . . . . . . . . . . . 7 7. Downgrade attacks . . . . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9.1. Authenticating a DNS Privacy Server . . . . . . . . . . . 8 9.1. Authenticating a DNS Privacy Server . . . . . . . . . . . 8
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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
skipping to change at page 3, line 50 skipping to change at page 3, line 50
DNSoD MUST run over standard UDP port 853 as defined in Section 8. A DNSoD MUST run over standard UDP port 853 as defined in Section 8. A
DNS server that supports DNSoD MUST listen for and accept DTLS DNS server that supports DNSoD MUST listen for and accept DTLS
packets on a designated port 853. packets on a designated port 853.
The host should determine if the DNS server supports DNSoD by sending The host should determine if the DNS server supports DNSoD by sending
a DTLS ClientHello message. A DNS server that does not support DNSoD a DTLS ClientHello message. A DNS server that does not support DNSoD
will not respond to ClientHello messages sent by the client. The will not respond to ClientHello messages sent by the client. The
client MUST use timer values defined in Section 4.2.4.1 of [RFC6347] client MUST use timer values defined in Section 4.2.4.1 of [RFC6347]
for retransmission of ClientHello message and if no response is for retransmission of ClientHello message and if no response is
received from the DNS server. After 15 seconds, it MUST cease received from the DNS server. After 15 seconds, it MUST cease
attempts to re-transmit its ClientHello. If the DNS client receives attempts to re-transmit its ClientHello. The client MAY repeat that
a hard ICMP error [RFC1122], it MUST immediately cease attempts to
re-transmit its ClientHello. Thereafter, the client MAY repeat that
procedure in the event the DNS server has been upgraded to support procedure in the event the DNS server has been upgraded to support
DNSoD, but such probing SHOULD NOT be done more frequently than every DNSoD, but such probing SHOULD NOT be done more frequently than every
24 hours and MUST NOT be done more frequently than every 15 minutes. 24 hours and MUST NOT be done more frequently than every 15 minutes.
This mechanism requires no additional signaling between the client This mechanism requires no additional signaling between the client
and server. and server.
4. Performance Considerations 4. Performance Considerations
To reduce number of octets of the DTLS handshake, especially the size To reduce number of octets of the DTLS handshake, especially the size
of the certificate in the ServerHello (which can be several of the certificate in the ServerHello (which can be several
kilobytes), DNS client and server can use raw public keys [RFC7250] kilobytes), DNS client and server can use raw public keys [RFC7250]
or Cached Information Extension [I-D.ietf-tls-cached-info]. Cached or Cached Information Extension [I-D.ietf-tls-cached-info]. Cached
Information Extension avoids transmitting the server's certificate Information Extension avoids transmitting the server's certificate
and certificate chain if the client has cached that information from and certificate chain if the client has cached that information from
a previous TLS handshake. a previous TLS handshake.
Multiple DNS queries can be sent over a single DTLS session and the Multiple DNS queries can be sent over a single DTLS session and the
DNSoD client need not wait for an outstanding reply before sending DNSoD client need not wait for an outstanding reply before sending
the next query. The existing Query ID allows multiple requests and the next query. The existing Query ID, Query type and Query class
responses to be interleaved in whatever order they can be fulfilled allows multiple requests and responses to be interleaved in whatever
by the DNS server. This means DNSoD reduces the consumption of UDP order they can be fulfilled by the DNS server. This means DNSoD
port numbers, and because DTLS protects the communication between a reduces the consumption of UDP port numbers, and because DTLS
DNS client and its server, the resolver SHOULD NOT use random protects the communication between a DNS client and its server, the
ephemeral source ports (Section 9.2 of [RFC5452]) because such source resolver SHOULD NOT use random ephemeral source ports (Section 9.2 of
port use would incur additional, unnecessary DTLS load on the DNSoD [RFC5452]) because such source port use would incur additional,
server. When sending multiple queries over a single DTLS session, unnecessary DTLS load on the DNSoD server. When sending multiple
clients MUST take care to avoid Message ID collisions. In other queries over a single DTLS session, clients MUST take care to avoid
words, they MUST NOT re-use the DNS Message ID of an in-flight query. Message ID collisions. In other words, they MUST NOT re-use the DNS
Message ID of an in-flight query.
It is highly advantageous to avoid server-side DTLS state and reduce It is highly advantageous to avoid server-side DTLS state and reduce
the number of new DTLS sessions on the server which can be done with the number of new DTLS sessions on the server which can be done with
[RFC5077]. This also eliminates a round-trip for subsequent DNSoD [RFC5077]. This also eliminates a round-trip for subsequent DNSoD
queries, because with [RFC5077] the DTLS session does not need to be queries, because with [RFC5077] the DTLS session does not need to be
re-established. re-established.
Compared to normal DNS, DTLS adds at least 13 octets of header, plus Compared to normal DNS, DTLS adds at least 13 octets of header, plus
cipher and authentication overhead to every query and every response. cipher and authentication overhead to every query and every response.
This reduces the size of the DNS payload that can be carried. DNS This reduces the size of the DNS payload that can be carried. DNS
skipping to change at page 5, line 5 skipping to change at page 5, line 4
so that the DNS client can indicate to the DNS server the maximum DNS so that the DNS client can indicate to the DNS server the maximum DNS
response size it can handle without IP fragmentation. If the DNS response size it can handle without IP fragmentation. If the DNS
server's response exceeds the EDNS0 value, the DNS server sets the TC server's response exceeds the EDNS0 value, the DNS server sets the TC
(truncated) bit. On receiving a response with the TC bit set, the (truncated) bit. On receiving a response with the TC bit set, the
client establishes a DNS-over-TLS connection to the same server, and client establishes a DNS-over-TLS connection to the same server, and
sends a new DNS request for the same resource record sends a new DNS request for the same resource record
DNSoD puts an additional computational load on servers. The largest DNSoD puts an additional computational load on servers. The largest
gain for privacy is to protect the communication between the DNS gain for privacy is to protect the communication between the DNS
client (the end user's machine) and its caching resolver. client (the end user's machine) and its caching resolver.
Implementing DNSoD on root servers is outside the scope of this
document.
5. Established sessions 5. Established sessions
In DTLS, all data is protected using the same record encoding and In DTLS, all data is protected using the same record encoding and
mechanisms. When the mechanism described in this document is in mechanisms. When the mechanism described in this document is in
effect, DNS messages are encrypted using the standard DTLS record effect, DNS messages are encrypted using the standard DTLS record
encoding. When a user of DTLS wishes to send an DNS message, it encoding. When a user of DTLS wishes to send an DNS message, it
delivers it to the DTLS implementation as an ordinary application delivers it to the DTLS implementation as an ordinary application
data write (e.g., SSL_write()). To reduce client and server data write (e.g., SSL_write()). To reduce client and server
workload, clients SHOULD re-use the DTLS session. A single DTLS workload, clients SHOULD re-use the DTLS session. A single DTLS
skipping to change at page 7, line 4 skipping to change at page 7, line 4
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 changes, a DNS over DTLS packet can be received by a
server that does not have the necessary cryptographic context. To server that does not have the necessary cryptographic context. To
encourage the client to initiate a new DTLS handshake, DNS servers encourage the client to initiate a new DTLS handshake, DNS servers
SHOULD generate a DTLS Alert message in response to receiving a DTLS SHOULD generate a DTLS Alert message in response to receiving a DTLS
packet for which the server does not have any cryptographic context. packet for which the server does not have any cryptographic context.
Upon receipt of an un-authenicated DTLS alert, the DTLS client Upon receipt of an un-authenicated DTLS alert, the DTLS client
validates the Alert is within the replay window, as usual validates the Alert is within the replay window (Section 4.1.2.6 of
(Section 4.1.2.6 of [RFC6347]). It is difficult for the DTLS client [RFC6347]). It is difficult for the DTLS client to validate the DTLS
to validate the DTLS alert was generated by the DTLS server in alert was generated by the DTLS server in response to a request or
response to a request or was generated by an on- or off-path was generated by an on- or off-path attacker. Thus, upon receipt of
attacker. Thus, upon receipt of an in-window DTLS Alert, the client an in-window DTLS Alert, the client SHOULD continue re-transmitting
SHOULD continue re-transmitting the DTLS packet (in the event the the DTLS packet (in the event the Alert was spoofed), and at the same
Alert was spoofed), and at the same time it SHOULD initiate DTLS time it SHOULD initiate DTLS session resumption.
session resumption.
7. Downgrade attacks 7. Downgrade attacks
Using DNS privacy with an authenticated server is most preferred, DNS Using DNS privacy with an authenticated server is most preferred, DNS
privacy with an unauthenticated server is next preferred, and plain privacy with an unauthenticated server is next preferred, and plain
DNS is least preferred. This section gives a non-normative DNS is least preferred. This section gives a non-normative
discussion on common behaviors and choices. discussion on common behaviors and choices.
An implementation MAY attempt to obtain DNS privacy by contacting DNS An implementation MAY attempt to obtain DNS privacy by contacting DNS
servers on the local network (provided by DHCP) and on the Internet, servers on the local network (provided by DHCP) and on the Internet,
skipping to change at page 8, line 19 skipping to change at page 8, line 19
Contact dwing@cisco.com Contact dwing@cisco.com
Description DNS query-response protocol runs over Description DNS query-response protocol runs over
DTLS and TLS DTLS and TLS
Reference This document Reference This document
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 and guidance given in [RFC7525] must be confidentiality protection and guidance given in [RFC7525] must be
followed to avoid attacks on DTLS. Once a DNSoD client has followed to avoid attacks on DTLS. DNS clients keeping track of
established a security association with a particular DNS server, and servers known to support DTLS enables clients to detect downgrade
outstanding normal DNS queries with that server (if any) have been attacks. For servers with no connection history and no apparent
received, the DNSoD client MUST ignore any subsequent normal DNS support for DTLS, depending on their Privacy Profile and privacy
responses from that server, as all subsequent responses should be requirements, clients may choose to (a) try another server when
encrypted. This behavior mitigates all possible attacks described in available, (b) continue without DTLS, or (c) refuse to forward the
Measures for Making DNS More Resilient against Forged Answers query. Once a DNSoD client has established a security association
[RFC5452]. with a particular DNS server, and outstanding normal DNS queries with
that server (if any) have been received, the DNSoD client MUST ignore
any subsequent normal DNS responses from that server, as all
subsequent responses should be encrypted. This behavior mitigates
all possible attacks described in Measures for Making DNS More
Resilient against Forged Answers [RFC5452].
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.
9.1. Authenticating a DNS Privacy Server 9.1. Authenticating a DNS Privacy Server
skipping to change at page 8, line 52 skipping to change at page 9, line 10
active attackers pretending to be the server, the server itself needs active attackers pretending to be the server, the server itself needs
to be authenticated. To authenticate the server providing DNS to be authenticated. To authenticate the server providing DNS
privacy, DNS client can use the authenication mechanisms discussed in privacy, DNS client can use the authenication mechanisms discussed in
[I-D.dgr-dprive-dtls-and-tls-profiles]. [I-D.dgr-dprive-dtls-and-tls-profiles].
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 DNSoD load on busy servers (most notably Littlefield for pointing out DNSoD load on busy servers (most notably
root servers). The authors would like to thank Simon Josefsson, root servers). The authors would like to thank Simon Josefsson,
Daniel Kahn Gillmor, Bob Harold, Ilari Liusvaara, Sara Dickinson and Daniel Kahn Gillmor, Bob Harold, Ilari Liusvaara, Sara Dickinson,
Christian Huitema for discussions and comments on the design of Christian Huitema and Stephane Bortzmeyer for discussions and
DNSoD. comments on the design of DNSoD.
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 10, line 36 skipping to change at page 10, line 40
11.2. Informative References 11.2. Informative References
[I-D.dgr-dprive-dtls-and-tls-profiles] [I-D.dgr-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-TLS and DNS-over-DTLS", and (D)TLS Profile for DNS-over-TLS and DNS-over-DTLS",
draft-dgr-dprive-dtls-and-tls-profiles-00 (work in draft-dgr-dprive-dtls-and-tls-profiles-00 (work in
progress), December 2015. progress), December 2015.
[I-D.ietf-dprive-dns-over-tls] [I-D.ietf-dprive-dns-over-tls]
Zi, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., Zi, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "DNS over TLS: Initiation and Performance and P. Hoffman, "Specification for DNS over TLS", draft-
Considerations", draft-ietf-dprive-dns-over-tls-04 (work ietf-dprive-dns-over-tls-07 (work in progress), March
in progress), January 2016. 2016.
[I-D.ietf-tls-cached-info] [I-D.ietf-tls-cached-info]
Santesson, S. and H. Tschofenig, "Transport Layer Security Santesson, S. and H. Tschofenig, "Transport Layer Security
(TLS) Cached Information Extension", draft-ietf-tls- (TLS) Cached Information Extension", draft-ietf-tls-
cached-info-21 (work in progress), December 2015. cached-info-22 (work in progress), January 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>.
[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,
 End of changes. 12 change blocks. 
43 lines changed or deleted 44 lines changed or added

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