draft-ietf-dprive-dnsodtls-11.txt   draft-ietf-dprive-dnsodtls-12.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 5, 2017 Cisco Expires: March 12, 2017 Cisco
September 1, 2016 September 8, 2016
Specification for DNS over Datagram Transport Layer Security (DTLS) Specification for DNS over Datagram Transport Layer Security (DTLS)
draft-ietf-dprive-dnsodtls-11 draft-ietf-dprive-dnsodtls-12
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 5, 2017. This Internet-Draft will expire on March 12, 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 2, line 20 skipping to change at page 2, line 20
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. 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 . . . . . . . . . . . . 4
3.3. Established Sessions . . . . . . . . . . . . . . . . . . 5 3.3. Established Sessions . . . . . . . . . . . . . . . . . . 5
4. Performance Considerations . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . 10 11.1. Normative References . . . . . . . . . . . . . . . . . . 9
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 37 skipping to change at page 3, line 37
for DNS messages in all circumstances, specifically when the DTLS for DNS messages in all circumstances, specifically when the DTLS
record size is larger than the path MTU. In such situations the DNS record size is larger than the path MTU. In such situations the DNS
server will respond with a truncated response (see Section 5). server will respond with a truncated response (see Section 5).
Therefore DNS clients and servers that implement DNS-over-DTLS MUST Therefore DNS clients and servers that implement DNS-over-DTLS MUST
also implement DNS-over-TLS in order to provide privacy for clients also implement DNS-over-TLS in order to provide privacy for clients
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 protect verify legitimacy of responses. However, DNSSEC does not provide
privacy of 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.
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] .
skipping to change at page 4, line 27 skipping to change at page 4, line 27
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. This
recommendation against use of port 53 for DNS-over-DTLS is to avoid recommendation against use of port 53 for DNS-over-DTLS is to avoid
complication in selecting use or non-use of DTLS and to reduce risk complication in selecting use or non-use of DTLS and to reduce risk
of downgrade attacks. 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 MUST 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 MUST 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
15 minutes. This mechanism requires no additional signaling between 15 minutes. This mechanism requires no additional signaling between
the client and server. the client and server.
DNS clients and servers MUST NOT use port 853 to transport cleartext DNS clients and servers MUST NOT use port 853 to transport cleartext
DNS messages. DNS clients MUST NOT send and DNS servers MUST NOT DNS messages. DNS clients MUST NOT send and DNS servers MUST NOT
respond to cleartext DNS messages on any port used for DNS-over-DTLS respond to cleartext DNS messages on any port used for DNS-over-DTLS
skipping to change at page 6, line 14 skipping to change at page 6, line 14
seconds, but no particular value is specified. When no DNS queries seconds, but no particular value is specified. When no DNS queries
have been received from the client after idle time out, the server have been received from the client after idle time out, the server
MUST send a DTLS fatal alert and then destroy its DTLS state. The MUST send a DTLS fatal alert and then destroy its DTLS state. The
DTLS fatal alert packet indicates the server has destroyed its state, DTLS fatal alert packet indicates the server has destroyed its state,
signaling to the client if it wants to send a new DTLS message it signaling to the client if it wants to send a new DTLS message it
will need to re-establish cryptographic context with the server (via will need to re-establish cryptographic context with the server (via
full DTLS handshake or DTLS session resumption). In practice, the full DTLS handshake or DTLS session resumption). In practice, the
idle period can vary dynamically, and servers MAY allow idle idle period can vary dynamically, and servers MAY allow idle
connections to remain open for longer periods as resources permit. connections to remain open for longer periods as resources permit.
Figure 1 shows DTLS handshake using cookie and issuing new session Figure 1 shows DTLS handshake and issuing new session ticket for
ticket for session resumption. session resumption.
Client Server Client Server
------ ------ ------ ------
ClientHello --------> ClientHello -------->
<------- HelloVerifyRequest
(contains cookie)
ClientHello -------->
(contains cookie)
(empty SessionTicket extension) (empty SessionTicket extension)
ServerHello ServerHello
(empty SessionTicket extension) (empty SessionTicket extension)
Certificate* Certificate*
ServerKeyExchange* ServerKeyExchange*
CertificateRequest* CertificateRequest*
<-------- ServerHelloDone <-------- ServerHelloDone
Certificate* Certificate*
ClientKeyExchange ClientKeyExchange
skipping to change at page 7, line 12 skipping to change at page 7, line 5
Figure 1: Message Flow for Full Handshake Issuing New Session Ticket 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 [I-D.ietf-tls-cached-info]. Cached Information Extension Extension [RFC7924]. Cached Information Extension avoids
avoids transmitting the server's certificate and certificate chain if transmitting the server's certificate and certificate chain if the
the client has cached that information from a previous TLS handshake. client has cached that information from a previous TLS handshake.
TLS False Start [I-D.ietf-tls-falsestart] can reduce round-trips by TLS False Start [RFC7918] can reduce round-trips by allowing the TLS
allowing the TLS second flight of messages (ChangeCipherSpec) to also second flight of messages (ChangeCipherSpec) to also contain the
contain the (encrypted) DNS query. (encrypted) DNS 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
TLS Session Resumption without server state [RFC5077]. This also TLS Session Resumption without server state [RFC5077]. This also
eliminates a round-trip for subsequent DNS-over-DTLS queries, because eliminates a round-trip for subsequent DNS-over-DTLS queries, because
with [RFC5077] the DTLS session does not need to be re-established. with [RFC5077] the DTLS session does not need to be re-established.
Since responses within a DTLS session can arrive out of order, Since responses within a DTLS session can arrive out of order,
clients MUST match responses to outstanding queries on the same DTLS clients MUST match responses to outstanding queries on the same DTLS
connection using the DNS Message ID. If the response contains a connection using the DNS Message ID. If the response contains a
skipping to change at page 11, line 23 skipping to change at page 11, line 13
<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-03 (work in progress), July
2016. 2016.
[I-D.ietf-tls-cached-info]
Santesson, S. and H. Tschofenig, "Transport Layer Security
(TLS) Cached Information Extension", draft-ietf-tls-
cached-info-23 (work in progress), May 2016.
[I-D.ietf-tls-falsestart]
Langley, A., Modadugu, N., and B. Moeller, "Transport
Layer Security (TLS) False Start", draft-ietf-tls-
falsestart-02 (work in progress), May 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,
June 2014, <http://www.rfc-editor.org/info/rfc7250>. June 2014, <http://www.rfc-editor.org/info/rfc7250>.
skipping to change at page 12, line 15 skipping to change at page 11, line 42
[RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
D. Wessels, "DNS Transport over TCP - Implementation D. Wessels, "DNS Transport over TCP - Implementation
Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
<http://www.rfc-editor.org/info/rfc7766>. <http://www.rfc-editor.org/info/rfc7766>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <http://www.rfc-editor.org/info/rfc7858>. 2016, <http://www.rfc-editor.org/info/rfc7858>.
[RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport
Layer Security (TLS) False Start", RFC 7918,
DOI 10.17487/RFC7918, August 2016,
<http://www.rfc-editor.org/info/rfc7918>.
[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security
(TLS) Cached Information Extension", RFC 7924,
DOI 10.17487/RFC7924, July 2016,
<http://www.rfc-editor.org/info/rfc7924>.
Authors' Addresses 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
 End of changes. 13 change blocks. 
35 lines changed or deleted 29 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/