draft-ietf-dprive-dnsodtls-14.txt   draft-ietf-dprive-dnsodtls-15.txt 
DPRIVE T. Reddy DPRIVE T. Reddy
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Experimental D. Wing Intended status: Experimental D. Wing
Expires: June 18, 2017 Expires: June 19, 2017
P. Patil P. Patil
Cisco Cisco
December 15, 2016 December 16, 2016
Specification for DNS over Datagram Transport Layer Security (DTLS) Specification for DNS over Datagram Transport Layer Security (DTLS)
draft-ietf-dprive-dnsodtls-14 draft-ietf-dprive-dnsodtls-15
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 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 June 18, 2017. This Internet-Draft will expire on June 19, 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 9, line 13 skipping to change at page 9, line 13
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. The DNS client SHOULD use the TLS followed to avoid attacks on DTLS. The DNS client SHOULD use the TLS
Certificate Status Request extension (Section 8 of [RFC6066]), Certificate Status Request extension (Section 8 of [RFC6066]),
commonly called "OCSP stapling" to check the revocation status of commonly called "OCSP stapling" to check the revocation status of
public key certificate of the DNS server. OCSP stapling, unlike public key certificate of the DNS server. OCSP stapling, unlike OCSP
OSCP, does not suffer from scale and privacy issues. DNS clients [RFC6960], does not suffer from scale and privacy issues. DNS
keeping track of servers known to support DTLS enables clients to clients keeping track of servers known to support DTLS enables
detect downgrade attacks. To interfere with DNS-over-DTLS, an on- or clients to detect downgrade attacks. To interfere with DNS-over-
off-path attacker might send an ICMP message towards the DTLS client DTLS, an on- or off-path attacker might send an ICMP message towards
or DTLS server. As these ICMP messages cannot be authenticated, all the DTLS client or DTLS server. As these ICMP messages cannot be
ICMP errors should be treated as soft errors [RFC1122]. If the DNS authenticated, all ICMP errors should be treated as soft errors
query was sent over DTLS then the corresponding DNS response MUST [RFC1122]. If the DNS query was sent over DTLS then the
only be accepted if it is received over the same DTLS connection. corresponding DNS response MUST only be accepted if it is received
This behavior mitigates all possible attacks described in Measures over the same DTLS connection. This behavior mitigates all possible
for Making DNS More Resilient against Forged Answers [RFC5452]. attacks described in Measures for Making DNS More Resilient against
Security considerations in [RFC6347] and 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.
skipping to change at page 11, line 45 skipping to change at page 11, line 45
DOI 10.17487/RFC6066, January 2011, DOI 10.17487/RFC6066, January 2011,
<http://www.rfc-editor.org/info/rfc6066>. <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>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, DOI 10.17487/RFC6960, June 2013,
<http://www.rfc-editor.org/info/rfc6960>.
[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. 6 change blocks. 
16 lines changed or deleted 22 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/