| DPRIVE Working Group | D. Wing |
| Internet-Draft | T. Reddy |
| Intended status: Informational | Cisco |
| Expires: September 16, 2016 | March 15, 2016 |
DPRIVE TLS/DTLS Message Flows
draft-wing-dprive-profile-and-msg-flows-01
Message flows for DNS-over-TLS and DNS-over-DTLS are discussed and compared.
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 September 16, 2016.
Copyright (c) 2016 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.
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-dns-over-tls].
This document shows message flows for those two documents. Also shown is how TCP Fast Open (TFO) [RFC7413] eliminates a round-trip, which is especially helpful for DNS communication.
This section shows message flows after server state is lost, such as due to routing change (communicating to a different server, unbeknownst to the client) or due to server losing state (crash or software upgrade).
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 this round trip is unavoidable. This is a TCP RST, and is not authenticated. After the RST, a new TCP connection and TLS state are established.
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 1: Server State Loss, TLS
With DTLS, the client is immediately informed of the server state loss with a DTLS Alert, as shown in the diagram below. This DTLS Alert is not authenticated. This message costs one round trip, but can be avoided if the client anticipates this server state loss and consumes additional packet overhead, as discussed below Figure 2.
client server
| |
|<-----------DPRIVE communications------------->|
| |
| ... |
| |
| (state lost)
| |
1. |-----------DPRIVE query----------------------->|
2. |<----------DTLS Alert--------------------------|
3. |-DLTS ClientHello w/resumption---------------->|
| ... |
Figure 2: Server State Loss, DTLS
An optimization of the above flow is possible, if the client believes the server is likely to have lost state, such as if the most recent DPRIVE communications was a long time ago (exact value of "long time" is debatable). In that situation, the client can send a DTLS handshake with TLS resumption -- effectively, it sends the DTLS handshake identical to packet (3) of Figure 2 (avoiding packets 1 and 2). This packet is larger, though, as it contains the TLS session 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 3: Server State Loss, DTLS False Start
Session resumption via identifiers and tickets is obsolete in TLS1.3 [I-D.ietf-tls-tls13]. Both methods are replaced by a pre-shared key (PSK) mode. A PSK is established on a previous connection after the handshake is completed, and can then be presented by the client on the next visit.
client server | | |<-----------------DPRIVE communications-------------------------------->| | | | ... | | | | (state lost) | | |-DNS-over-TLS---------------------------------------------------------->| |<------TCP RST----------------------------------------------------------| |--TCP SYN-------------------------------------------------------------->| |<-TCP SYNACK------------------------------------------------------------| |--TCP ACK, TLS ClientHello+key_share+pre_shared_key-------------------->| |<-TLS ServerHello+pre_shared_key, EncryptedExtensions, Finished --------| |--TLS Finished--------------------------------------------------------->| |<-DNS response----------------------------------------------------------| | |
Figure 4: Session resumption
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 5: Server State Loss, TLS with TCP FastOpen
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.
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.
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.
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.
With DTLS, the NAT or firewall will create a new mapping when it sees the new UDP packet. With a NAT, depending on its load (of other traffic) and its implmentation that mapping might be assigned to the same UDP port and IP address as the previous mapping, a different UDP port, and/or a different source IP address. The situation where the same mapping occurs is shown below.
client NAT or firewall server
| | |
|<-----------DPRIVE communications------------->|
| | |
| (state loss) |
| | |
|-----------DPRIVE query----------------------->|
| (new state created in NAT/firewall) |
| | |
|<----------DPRIVE response---------------------|
| ... |
Figure 6: NAT/Firewall State Loss, DTLS
A different mapping can cause the server to reject the communication (DTLS Alert) cause the server to reject the communication (DTLS Alert) if the server was sensative to the client's source address or source port, consuming a round trip. This is shown below.
client NAT or firewall server
| | |
|<-----------DPRIVE communications------------->|
| | |
| (state loss) |
| | |
|-----------DPRIVE query----------------------->|
| (new state created in NAT/firewall) |
| | |
|<----------DTLS Alert--------------------------|
| | |
|-DLTS ClientHello w/resumption---------------->|
| | |
|<----------DPRIVE response---------------------|
| ... |
Figure 7: NAT/Firewall State Loss, DTLS, changed mapping
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:
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 8: 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 9: NAT/Firewall State Loss, TLS
None.
Authors would like to thank Allison Mankin for comments and review.
| [I-D.ietf-dprive-dns-over-tls] | Zi, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D. and P. Hoffman, "Specification for DNS over TLS", Internet-Draft draft-ietf-dprive-dns-over-tls-07, March 2016. |
| [I-D.ietf-dprive-dnsodtls] | Reddy, T., Wing, D. and P. Patil, "DNS over DTLS (DNSoD)", Internet-Draft draft-ietf-dprive-dnsodtls-04, January 2016. |
| [I-D.ietf-tls-tls13] | Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", Internet-Draft draft-ietf-tls-tls13-11, December 2015. |
| [I-D.isomaki-rtcweb-mobile] | Isomaki, M., "RTCweb Considerations for Mobile Devices", Internet-Draft draft-isomaki-rtcweb-mobile-00, July 2012. |
| [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. |
| [RFC7413] | Cheng, Y., Chu, J., Radhakrishnan, S. and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014. |