DPRIVE TLS/DTLS Profile and Message Flows
draft-wing-dprive-profile-and-msg-flows-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Dan Wing , Tirumaleswar Reddy.K | ||
| Last updated | 2015-09-16 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wing-dprive-profile-and-msg-flows-00
DPRIVE Working Group D. Wing
Internet-Draft T. Reddy
Intended status: Standards Track Cisco
Expires: March 19, 2016 September 16, 2015
DPRIVE TLS/DTLS Profile and Message Flows
draft-wing-dprive-profile-and-msg-flows-00
Abstract
This document defines a Transport Layer Security (TLS) and Datagram
TLS (DTLS) 1.2 profile for providing DNS privacy. Message flows for
DNS-over-TLS and DNS-over-DTLS are discussed and compared.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 19, 2016.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Wing & Reddy Expires March 19, 2016 [Page 1]
Internet-Draft DPRIVE TLS/DTLS Profile and Message Flows September 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. (D)TLS Profile . . . . . . . . . . . . . . . . . . . . . . . 2
2.1. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Probing for Server State Loss . . . . . . . . . . . . . . . . 5
3.1. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. NAT or Firewall Pinhole Closed . . . . . . . . . . . . . . . 6
4.1. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Fallback to DNS-over-TLS . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
The DPRIVE working group has two active documents that provide DNS
confidentiality, DNS over DTLS [I-D.ietf-dprive-dnsodtls] and DNS
over TLS [I-D.ietf-dprive-start-tls-for-dns].
This document defines a profile of DTLS 1.2 [RFC6347] and TLS 1.2
[RFC5246] that offers DNS privacy. This profile defines the
configuration options and protocol extensions to perform connection
handshakes with the fewest round trips while maintaining privacy.
This document also shows message flows for those two documents.
2. (D)TLS Profile
This section defines the profile of DNS over DTLS and of DNS over
TLS. Implementations compliant with this profile MUST implement all
of the following items:
o TLS session resumption without server-side state [RFC5077], which
eliminates the need for the server to retain cryptographic state
for longer than necessary, and;
o TLS False Start [I-D.ietf-tls-falsestart], which reduces round-
trips by allowing the TLS second flight of messages
(ChangeCipherSpec) to also contain the (encrypted) DNS query, and;
o Cached Information Extension [I-D.ietf-tls-cached-info], which
avoids transmitting the server's certificate and certificate chain
Wing & Reddy Expires March 19, 2016 [Page 2]
Internet-Draft DPRIVE TLS/DTLS Profile and Message Flows September 2015
if the client has cached that information from a previous TLS
handshake, and;.
o Raw public keys [RFC7250], which reduce the size of the
ServerHello, and cannot obtain certificates (e.g., DNS resolvers
on private networks). DNS client and DNS resolver need to support
[RFC7250], and raw public key-based authentication mechanism
defined in [RFC7250] can be used by the client to authenticate the
DNS resolver. DNS client needs to be configured with the
SubjectPublicKeyInfo fingerprint of the DNS resolver.
o The interaction between the DNS client and the DNS server requires
Transport Layer Security (TLS) and Datagram Transport Layer
Security (DTLS) with a ciphersuite offering confidentiality
protection and the guidance given in [RFC7525] must be followed to
avoid attacks on (D)TLS, and;
o Authenticating the DNS server using certificates or raw public
keys is explained in Section 3.2 of [I-D.ietf-dprive-dnsodtls].
2.1. DTLS
With DTLS, the client is immediately informed of the server state
loss with a DTLS Alert, as shown in the diagram below. This costs
one round trip.
client server
| |
|<-----------DPRIVE communications------------->|
| |
| ... |
| |
| (state lost)
| |
1. |-----------DPRIVE query----------------------->|
2. |<----------DTLS Alert--------------------------|
3. |-DLTS ClientHello w/resumption---------------->|
| ... |
Figure 1: Server State Loss, DTLS
An optimization of the above flow is possible, if we consider that
the server is more likely to have lost state if the most recent DNS
query was sent a "long time ago" (exact value of "long time" is
debatable). In that situation, the DNS-over-DTLS client can send a
TLS handshake with TLS resumption -- effectively, it sends the TLS
handshake identical to packet (3) of Figure 1 (avoiding packets 1 and
2). This packet is larger, though, as it contains the TLS session
Wing & Reddy Expires March 19, 2016 [Page 3]
Internet-Draft DPRIVE TLS/DTLS Profile and Message Flows September 2015
resumption information. Thus, it is a trade-off of a larger message
versus a (possible) round trip savings. This message flow is shown
below.
client server
| |
|<----------DPRIVE communications------------------>|
| |
| ... |
| |
| (state lost)
| |
|--DTLS ClientHello w/resumption ------------------>|
|<-DTLS ServerHello, ChangeCipherSpec, Finished-----|
|--DTLS ChangeCipherSpec, Finished, DNS query------>|
|<-DNS response-------------------------------------|
| ... |
Figure 2: Server State Loss, DTLS False Start
2.2. TLS
With TLS, the client is immediately informed of server state loss
with a TCP RST, as shown in the diagram below. This costs one round
trip , and is unavoidable.
client server
| |
|<-----------------DPRIVE communications----------------->|
| |
| ... |
| |
| (state lost)
| |
|-DNS-over-TLS------------------------------------------->|
|<------TCP RST-------------------------------------------|
|--TCP SYN----------------------------------------------->|
|<-TCP SYNACK---------------------------------------------|
|--TCP ACK, TLS ClientHello w/Resumption ---------------->|
|<-TLS ServerHello, ChangeCipherSpec, Finished -----------|
|--TLS ChangeCipherSpec, Finished, DNS query------------->|
|<-DNS response-------------------------------------------|
| |
Figure 3: Server State Loss, TLS
Wing & Reddy Expires March 19, 2016 [Page 4]
Internet-Draft DPRIVE TLS/DTLS Profile and Message Flows September 2015
Open Issue: Does TCP RST cause one second delay on Windows, or was
this just behavior on Windows Vista and XP during session
establishment (see slide 11 of [RST-delay])? Needs testing.
If the client and server TCP stacks both support TCP Fast Open (TFO)
[RFC7413], the TCP 3-way handshake can be done without a round trip,
as shown below. Currently, TFO is supported in Linux 3.7 (TCP client
and server), iOS 9, and OS X 10.11.
client server
| |
|<-------------------DPRIVE communications-------------------->|
| |
| ... |
| |
| (state lost)
| |
|-DNS-over-TLS------------------------------------------------>|
|<------TCP RST------------------------------------------------|
|--TCP SYN, TLS ClientHello w/Resumption --------------------->|
|<-TCP SYNACK, TLS ServerHello, ChangeCipherSpec, Finished-----|
|--TLS ChangeCipherSpec, Finished, DNS query------------------>|
|<-DNS response------------------------------------------------|
Figure 4: Server State Loss, TLS with TCP FastOpen
3. Probing for Server State Loss
In between normal DNS traffic while the communication to the DNS
server is quiescent, the DNS client may want to probe the server to
ensure it has maintained cryptographic state. Such probes can also
keep alive firewall or NAT bindings. This probing reduces the
frequency of needing a new handshake when a DNS query needs to be
resolved, improving the user experience at the cost of bandwidth and
processing time; cellular devices could even send the probes while in
power-save state [I-D.isomaki-rtcweb-mobile].
If the server has lost state, a DTLS (or TLS) handshake needs to be
initiated with the server.
3.1. DTLS
A DTLS heartbeat [RFC6520] verifies the server still has DTLS state
by returning a DTLS message. If the server has lost state, it
returns a DTLS Alert.
Wing & Reddy Expires March 19, 2016 [Page 5]
Internet-Draft DPRIVE TLS/DTLS Profile and Message Flows September 2015
3.2. TLS
TLS runs over TCP, so a simple probe is a 0-length TCP packet (a
"window probe"). This verifies the TCP connection is still working,
which is also sufficient to prove the server has retained TLS state,
because if the server loses TLS state it abandons the TCP connection.
If the server has lost state, a TCP RST is returned immediately.
4. NAT or Firewall Pinhole Closed
A NAT or Firewall, on the path between the DPRIVE client and DPRIVE
server, lose state -- either due to timing out the pinhole,
exhausting its resources (and needing to prematurely close the
pinhole), or crashing. This differs from the server losing state.
4.1. DTLS
client NAT or firewall server
| | |
|<-----------DPRIVE communications------------->|
| | |
| (state loss) |
| | |
|-----------DPRIVE query----------------------->|
| (new state created in NAT/firewall) |
| | |
. |<----------DPRIVE response---------------------|
| ... |
Figure 5: NAT/Firewall State Loss, DTLS
4.2. TLS
With a TCP connection when the NAT or firewall has lost state and
sees a TCP packet without the SYN bit set, there are several possible
reactions by the NAT or firewall:
o send TCP RST, spoofing the source IP address of the original
packet's destination address. This is shown in the following
figure.
o create state. A firewall is unlikely to create state when it sees
an in-progress TCP packet, but some NATs may create state.
However, if the NAT creates state for a different source TCP port
than the previous connection, the server will reject the TCP
packet as shown in Figure 4.
Wing & Reddy Expires March 19, 2016 [Page 6]
Internet-Draft DPRIVE TLS/DTLS Profile and Message Flows September 2015
client NAT or firewall server
| | |
|<-----------DPRIVE communications---------------------------->|
| | |
| (state loss) |
| | |
|----DPRIVE query---->X |
| (no state exists for TCP flow) |
| | |
|<---TCP RST----------| |
| | |
(client does | |
TLS re-establishment with TCP FastOpen) |
| | |
|--TCP SYN, TLS ClientHello w/Resumption --------------------->|
|<-TCP SYNACK, TLS ServerHello, ChangeCipherSpec, Finished-----|
|--TLS ChangeCipherSpec, Finished, DNS query------------------>|
|<-DNS response------------------------------------------------|
| | |
Figure 6: NAT/Firewall State Loss, TLS with TCP FastOpen
client NAT or firewall server
| | |
|<-----------DPRIVE communications-------------->|
| | |
| (state loss) |
| | |
|----DPRIVE query---->X |
| (no state exists for TCP flow) |
| | |
|<---TCP RST----------| |
| | |
(client does normal | |
TLS re-establishment) | |
| | |
|--TCP SYN-------------------------------------->|
|<-TCP SYNACK------------------------------------|
|--TCP ACK, TLS ClientHello w/Resumption ------->|
|<-TLS ServerHello, ChangeCipherSpec, Finished --|
|--TLS ChangeCipherSpec, Finished, DNS query---->|
|<-DNS response----------------------------------|
| | |
Figure 7: NAT/Firewall State Loss, TLS
Wing & Reddy Expires March 19, 2016 [Page 7]
Internet-Draft DPRIVE TLS/DTLS Profile and Message Flows September 2015
5. Fallback to DNS-over-TLS
DNS-over-DTLS mandates the EDNS0 option defined in [RFC6891] to
indicate the maximum DNS response size. This maximum DNS response
size will be smaller than the path MTU, due to DTLS overhead, which
the client needs to consider in its indicated EDNS0 value. For
example, if the client can receive DNS responses of 1024 bytes and is
using the cipher suites from [RFC5246]) and null compression, the
record-layer output can be at most 1317 bytes: 5 bytes of headers,
1024 bytes of DNS data, 256 bytes of padding, and 32 bytes of MAC.
If the DNS sever's response exceeds the EDNS0 value, the DNS server
sets the TC (truncated) bit. On receiving a response with the TC bit
set, the client establishes a DNS-over-TLS connection to the same
server, and sends a new DNS request for the same resource record.
There is concern, especially with DNSSEC responses, that a high
frequency of responses will exceed the normal 512 byte DNS limit
before the TC bit is set. However, EDNS0 and common network MTUs
allow for larger responses.
6. IANA Considerations
None.
7. Acknowledgements
Authors would like to thank Mankin Allison for comments and review.
8. References
8.1. Normative References
[I-D.ietf-dprive-dnsodtls]
Reddy, T., Wing, D., and P. Patil, "DNS over DTLS
(DNSoD)", draft-ietf-dprive-dnsodtls-01 (work in
progress), June 2015.
[I-D.ietf-dprive-start-tls-for-dns]
Zi, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "TLS for DNS: Initiation and Performance
Considerations", draft-ietf-dprive-start-tls-for-dns-01
(work in progress), July 2015.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
Wing & Reddy Expires March 19, 2016 [Page 8]
Internet-Draft DPRIVE TLS/DTLS Profile and Message Flows September 2015
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/rfc7525>.
8.2. Informative References
[I-D.ietf-tls-cached-info]
Santesson, S. and H. Tschofenig, "Transport Layer Security
(TLS) Cached Information Extension", draft-ietf-tls-
cached-info-19 (work in progress), March 2015.
[I-D.ietf-tls-falsestart]
Langley, A., Modadugu, N., and B. Moeller, "Transport
Layer Security (TLS) False Start", draft-ietf-tls-
falsestart-00 (work in progress), May 2015.
[I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-08 (work in progress),
August 2015.
[I-D.isomaki-rtcweb-mobile]
Isomaki, M., "RTCweb Considerations for Mobile Devices",
draft-isomaki-rtcweb-mobile-00 (work in progress), July
2012.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
January 2008, <http://www.rfc-editor.org/info/rfc5077>.
[RFC5966] Bellis, R., "DNS Transport over TCP - Implementation
Requirements", RFC 5966, DOI 10.17487/RFC5966, August
2010, <http://www.rfc-editor.org/info/rfc5966>.
[RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport
Layer Security (TLS) and Datagram Transport Layer Security
(DTLS) Heartbeat Extension", RFC 6520,
DOI 10.17487/RFC6520, February 2012,
<http://www.rfc-editor.org/info/rfc6520>.
Wing & Reddy Expires March 19, 2016 [Page 9]
Internet-Draft DPRIVE TLS/DTLS Profile and Message Flows September 2015
[RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital
Signature Algorithm (DSA) for DNSSEC", RFC 6605,
DOI 10.17487/RFC6605, April 2012,
<http://www.rfc-editor.org/info/rfc6605>.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891,
DOI 10.17487/RFC6891, April 2013,
<http://www.rfc-editor.org/info/rfc6891>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <http://www.rfc-editor.org/info/rfc7250>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<http://www.rfc-editor.org/info/rfc7413>.
[RST-delay]
NTT Labs, "Clear and Present Danger of IPv6 episode 2:
IPv6/IPv4 fallback", February 2007,
<https://www.nanog.org/meetings/nanog39/presentations/
ipv6_katsuyasu.pdf>.
Authors' Addresses
Dan Wing
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, California 95134
USA
Email: dwing@cisco.com
Tirumaleswar Reddy
Cisco Systems, Inc.
Cessna Business Park, Varthur Hobli
Sarjapur Marathalli Outer Ring Road
Bangalore, Karnataka 560103
India
Email: tireddy@cisco.com
Wing & Reddy Expires March 19, 2016 [Page 10]