draft-ietf-dprive-dnsodtls-05.txt   draft-ietf-dprive-dnsodtls-06.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: September 16, 2016 Cisco Expires: October 6, 2016 Cisco
March 15, 2016 April 4, 2016
DNS over DTLS (DNSoD) DNS over DTLS (DNSoD)
draft-ietf-dprive-dnsodtls-05 draft-ietf-dprive-dnsodtls-06
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 September 16, 2016. This Internet-Draft will expire on October 6, 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 22 skipping to change at page 2, line 22
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 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 . . . . . . . . . . . . . . . . . . . . 4
6. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Downgrade attacks . . . . . . . . . . . . . . . . . . . . . . 7 7. Downgrade attacks . . . . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9.1. Authenticating a DNS Privacy Server . . . . . . . . . . . 8 9.1. Authenticating a DNS Privacy Server . . . . . . . . . . . 8
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
11.1. Normative References . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . 8
11.2. Informative References . . . . . . . . . . . . . . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
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. DNS privacy problem is further resulting in privacy leakage. DNS privacy problem is further
discussed in [RFC7626]. discussed in [RFC7626].
skipping to change at page 4, line 18 skipping to change at page 4, line 18
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 Since pipelined responses can arrive out of order, clients MUST match
DNSoD client need not wait for an outstanding reply before sending responses to outstanding queries on the same DTLS connection using
the next query. The existing Query ID, Query type and Query class the Message ID. If the response contains a question section, the
allows multiple requests and responses to be interleaved in whatever client MUST match the QNAME, QCLASS, and QTYPE fields. Failure by
order they can be fulfilled by the DNS server. This means DNSoD clients to properly match responses to outstanding queries can have
reduces the consumption of UDP port numbers, and because DTLS serious consequences for interoperability ([RFC7766], Section 7).
protects the communication between a DNS client and its server, the
resolver SHOULD NOT use random ephemeral source ports (Section 9.2 of
[RFC5452]) because such source port use would incur additional,
unnecessary DTLS load on the DNSoD server. When sending multiple
queries over a single DTLS session, clients MUST take care to avoid
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 8, line 21 skipping to change at page 7, line 30
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. DNS clients keeping track of followed to avoid attacks on DTLS. DNS clients keeping track of
servers known to support DTLS enables clients to detect downgrade servers known to support DTLS enables clients to detect downgrade
attacks. For servers with no connection history and no apparent attacks. To interfere with DNS over DTLS, an on- or off-path
support for DTLS, depending on their Privacy Profile and privacy attacker might send an ICMP message towards the DTLS client or DTLS
requirements, clients may choose to (a) try another server when server. As these ICMP messages cannot be authenticated, all ICMP
available, (b) continue without DTLS, or (c) refuse to forward the errors should be treated as soft errors [RFC1122]. For servers with
query. Once a DNSoD client has established a security association no connection history and no apparent support for DTLS, depending on
with a particular DNS server, and outstanding normal DNS queries with their Privacy Profile and privacy requirements, clients may choose to
that server (if any) have been received, the DNSoD client MUST ignore (a) try another server when available, (b) continue without DTLS, or
any subsequent normal DNS responses from that server, as all (c) refuse to forward the query. Once a DNSoD client has established
subsequent responses should be encrypted. This behavior mitigates a security association with a particular DNS server, and outstanding
all possible attacks described in Measures for Making DNS More normal DNS queries with that server (if any) have been received, the
Resilient against Forged Answers [RFC5452]. 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 10, line 41 skipping to change at page 10, line 8
[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, "Specification for DNS over TLS", draft- and P. Hoffman, "Specification for DNS over TLS", draft-
ietf-dprive-dns-over-tls-07 (work in progress), March ietf-dprive-dns-over-tls-09 (work in progress), March
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-22 (work in progress), January 2016. 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,
skipping to change at page 11, line 23 skipping to change at page 10, line 39
<http://www.rfc-editor.org/info/rfc7413>. <http://www.rfc-editor.org/info/rfc7413>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, DOI 10.17487/RFC7435, Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <http://www.rfc-editor.org/info/rfc7435>. December 2014, <http://www.rfc-editor.org/info/rfc7435>.
[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
DOI 10.17487/RFC7626, August 2015, DOI 10.17487/RFC7626, August 2015,
<http://www.rfc-editor.org/info/rfc7626>. <http://www.rfc-editor.org/info/rfc7626>.
Authors' Addresses [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
D. Wessels, "DNS Transport over TCP - Implementation
Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
<http://www.rfc-editor.org/info/rfc7766>.
Authors' Addresses
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
 End of changes. 12 change blocks. 
38 lines changed or deleted 38 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/