idnits 2.17.00 (12 Aug 2021) /tmp/idnits43885/draft-wing-dprive-profile-and-msg-flows-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** There are 16 instances of too long lines in the document, the longest one being 13 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 15, 2016) is 2251 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-dprive-dns-over-tls has been published as RFC 7858 == Outdated reference: draft-ietf-dprive-dnsodtls has been published as RFC 8094 == Outdated reference: draft-ietf-tls-tls13 has been published as RFC 8446 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DPRIVE Working Group D. Wing 3 Internet-Draft T. Reddy 4 Intended status: Informational Cisco 5 Expires: September 16, 2016 March 15, 2016 7 DPRIVE TLS/DTLS Message Flows 8 draft-wing-dprive-profile-and-msg-flows-01 10 Abstract 12 Message flows for DNS-over-TLS and DNS-over-DTLS are discussed and 13 compared. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on September 16, 2016. 32 Copyright Notice 34 Copyright (c) 2016 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Server state lost . . . . . . . . . . . . . . . . . . . . . . 2 51 2.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.3. TLS 1.3 . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4. Probing for Server State Loss . . . . . . . . . . . . . . . . 6 56 4.1. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 4.2. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 5. NAT or Firewall Pinhole Closed . . . . . . . . . . . . . . . 6 59 5.1. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 5.2. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 62 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 65 8.2. Informative References . . . . . . . . . . . . . . . . . 10 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 68 1. Introduction 70 The DPRIVE working group has two active documents that provide DNS 71 confidentiality, DNS over DTLS [I-D.ietf-dprive-dnsodtls] and DNS 72 over TLS [I-D.ietf-dprive-dns-over-tls]. 74 This document shows message flows for those two documents. Also 75 shown is how TCP Fast Open (TFO) [RFC7413] eliminates a round-trip, 76 which is especially helpful for DNS communication. 78 2. Server state lost 80 This section shows message flows after server state is lost, such as 81 due to routing change (communicating to a different server, 82 unbeknownst to the client) or due to server losing state (crash or 83 software upgrade). 85 2.1. TLS 87 With TLS, the client is immediately informed of server state loss 88 with a TCP RST, as shown in the diagram below. This costs one round 89 trip, and this round trip is unavoidable. This is a TCP RST, and is 90 not authenticated. After the RST, a new TCP connection and TLS state 91 are established. 93 client server 94 | | 95 |<-----------------DPRIVE communications----------------->| 96 | | 97 | ... | 98 | | 99 | (state lost) 100 | | 101 |-DNS-over-TLS------------------------------------------->| 102 |<------TCP RST-------------------------------------------| 103 |--TCP SYN----------------------------------------------->| 104 |<-TCP SYNACK---------------------------------------------| 105 |--TCP ACK, TLS ClientHello w/Resumption ---------------->| 106 |<-TLS ServerHello, ChangeCipherSpec, Finished -----------| 107 |--TLS ChangeCipherSpec, Finished, DNS query------------->| 108 |<-DNS response-------------------------------------------| 109 | | 111 Figure 1: Server State Loss, TLS 113 2.2. DTLS 115 With DTLS, the client is immediately informed of the server state 116 loss with a DTLS Alert, as shown in the diagram below. This DTLS 117 Alert is not authenticated. This message costs one round trip, but 118 can be avoided if the client anticipates this server state loss and 119 consumes additional packet overhead, as discussed below Figure 2. 121 client server 122 | | 123 |<-----------DPRIVE communications------------->| 124 | | 125 | ... | 126 | | 127 | (state lost) 128 | | 129 1. |-----------DPRIVE query----------------------->| 130 2. |<----------DTLS Alert--------------------------| 131 3. |-DLTS ClientHello w/resumption---------------->| 132 | ... | 134 Figure 2: Server State Loss, DTLS 136 An optimization of the above flow is possible, if the client believes 137 the server is likely to have lost state, such as if the most recent 138 DPRIVE communications was a long time ago (exact value of "long time" 139 is debatable). In that situation, the client can send a DTLS 140 handshake with TLS resumption -- effectively, it sends the DTLS 141 handshake identical to packet (3) of Figure 2 (avoiding packets 1 and 142 2). This packet is larger, though, as it contains the TLS session 143 resumption information. Thus, it is a trade-off of a larger message 144 versus a (possible) round trip savings. This message flow is shown 145 below. 147 client server 148 | | 149 |<----------DPRIVE communications------------------>| 150 | | 151 | ... | 152 | | 153 | (state lost) 154 | | 155 |--DTLS ClientHello w/resumption ------------------>| 156 |<-DTLS ServerHello, ChangeCipherSpec, Finished-----| 157 |--DTLS ChangeCipherSpec, Finished, DNS query------>| 158 |<-DNS response-------------------------------------| 159 | ... | 161 Figure 3: Server State Loss, DTLS False Start 163 2.3. TLS 1.3 165 Session resumption via identifiers and tickets is obsolete in TLS1.3 166 [I-D.ietf-tls-tls13]. Both methods are replaced by a pre-shared key 167 (PSK) mode. A PSK is established on a previous connection after the 168 handshake is completed, and can then be presented by the client on 169 the next visit. 171 client server 172 | | 173 |<-----------------DPRIVE communications-------------------------------->| 174 | | 175 | ... | 176 | | 177 | (state lost) 178 | | 179 |-DNS-over-TLS---------------------------------------------------------->| 180 |<------TCP RST----------------------------------------------------------| 181 |--TCP SYN-------------------------------------------------------------->| 182 |<-TCP SYNACK------------------------------------------------------------| 183 |--TCP ACK, TLS ClientHello+key_share+pre_shared_key-------------------->| 184 |<-TLS ServerHello+pre_shared_key, EncryptedExtensions, Finished --------| 185 |--TLS Finished--------------------------------------------------------->| 186 |<-DNS response----------------------------------------------------------| 187 | | 189 Figure 4: Session resumption 191 3. TCP Fast Open 193 If the client and server TCP stacks both support TCP Fast Open (TFO) 194 [RFC7413], the TCP 3-way handshake can be done without a round trip, 195 as shown below. Currently, TFO is supported in Linux 3.7 (TCP client 196 and server), iOS 9, and OS X 10.11. 198 client server 199 | | 200 |<-------------------DPRIVE communications-------------------->| 201 | | 202 | ... | 203 | | 204 | (state lost) 205 | | 206 |-DNS-over-TLS------------------------------------------------>| 207 |<------TCP RST------------------------------------------------| 208 |--TCP SYN, TLS ClientHello w/Resumption --------------------->| 209 |<-TCP SYNACK, TLS ServerHello, ChangeCipherSpec, Finished-----| 210 |--TLS ChangeCipherSpec, Finished, DNS query------------------>| 211 |<-DNS response------------------------------------------------| 213 Figure 5: Server State Loss, TLS with TCP FastOpen 215 4. Probing for Server State Loss 217 In between normal DNS traffic while the communication to the DNS 218 server is quiescent, the DNS client may want to probe the server to 219 ensure it has maintained cryptographic state. Such probes can also 220 keep alive firewall or NAT bindings. This probing reduces the 221 frequency of needing a new handshake when a DNS query needs to be 222 resolved, improving the user experience at the cost of bandwidth and 223 processing time; cellular devices could even send the probes while in 224 power-save state [I-D.isomaki-rtcweb-mobile]. 226 If the server has lost state, a DTLS (or TLS) handshake needs to be 227 initiated with the server. 229 4.1. DTLS 231 A DTLS heartbeat [RFC6520] verifies the server still has DTLS state 232 by returning a DTLS message. If the server has lost state, it 233 returns a DTLS Alert. 235 4.2. TLS 237 TLS runs over TCP, so a simple probe is a 0-length TCP packet (a 238 "window probe"). This verifies the TCP connection is still working, 239 which is also sufficient to prove the server has retained TLS state, 240 because if the server loses TLS state it abandons the TCP connection. 241 If the server has lost state, a TCP RST is returned immediately. 243 5. NAT or Firewall Pinhole Closed 245 A NAT or Firewall, on the path between the DPRIVE client and DPRIVE 246 server, lose state -- either due to timing out the pinhole, 247 exhausting its resources (and needing to prematurely close the 248 pinhole), or crashing. This differs from the server losing state. 250 5.1. DTLS 252 With DTLS, the NAT or firewall will create a new mapping when it sees 253 the new UDP packet. With a NAT, depending on its load (of other 254 traffic) and its implmentation that mapping might be assigned to the 255 same UDP port and IP address as the previous mapping, a different UDP 256 port, and/or a different source IP address. The situation where the 257 same mapping occurs is shown below. 259 client NAT or firewall server 260 | | | 261 |<-----------DPRIVE communications------------->| 262 | | | 263 | (state loss) | 264 | | | 265 |-----------DPRIVE query----------------------->| 266 | (new state created in NAT/firewall) | 267 | | | 268 |<----------DPRIVE response---------------------| 269 | ... | 271 Figure 6: NAT/Firewall State Loss, DTLS 273 A different mapping can cause the server to reject the communication 274 (DTLS Alert) cause the server to reject the communication (DTLS 275 Alert) if the server was sensative to the client's source address or 276 source port, consuming a round trip. This is shown below. 278 client NAT or firewall server 279 | | | 280 |<-----------DPRIVE communications------------->| 281 | | | 282 | (state loss) | 283 | | | 284 |-----------DPRIVE query----------------------->| 285 | (new state created in NAT/firewall) | 286 | | | 287 |<----------DTLS Alert--------------------------| 288 | | | 289 |-DLTS ClientHello w/resumption---------------->| 290 | | | 291 |<----------DPRIVE response---------------------| 292 | ... | 294 Figure 7: NAT/Firewall State Loss, DTLS, changed mapping 296 5.2. TLS 298 With a TCP connection when the NAT or firewall has lost state and 299 sees a TCP packet without the SYN bit set, there are several possible 300 reactions by the NAT or firewall: 302 o send TCP RST, spoofing the source IP address of the original 303 packet's destination address. This is shown in the following 304 figure. 306 o create state. A firewall is unlikely to create state when it sees 307 an in-progress TCP packet, but some NATs may create state. 308 However, if the NAT creates state for a different source TCP port 309 than the previous connection, the server will reject the TCP 310 packet as shown in Figure 5. 312 client NAT or firewall server 313 | | | 314 |<-----------DPRIVE communications---------------------------->| 315 | | | 316 | (state loss) | 317 | | | 318 |----DPRIVE query---->X | 319 | (no state exists for TCP flow) | 320 | | | 321 |<---TCP RST----------| | 322 | | | 323 (client does | | 324 TLS re-establishment with TCP FastOpen) | 325 | | | 326 |--TCP SYN, TLS ClientHello w/Resumption --------------------->| 327 |<-TCP SYNACK, TLS ServerHello, ChangeCipherSpec, Finished-----| 328 |--TLS ChangeCipherSpec, Finished, DNS query------------------>| 329 |<-DNS response------------------------------------------------| 330 | | | 332 Figure 8: NAT/Firewall State Loss, TLS with TCP FastOpen 333 client NAT or firewall server 334 | | | 335 |<-----------DPRIVE communications-------------->| 336 | | | 337 | (state loss) | 338 | | | 339 |----DPRIVE query---->X | 340 | (no state exists for TCP flow) | 341 | | | 342 |<---TCP RST----------| | 343 | | | 344 (client does normal | | 345 TLS re-establishment) | | 346 | | | 347 |--TCP SYN-------------------------------------->| 348 |<-TCP SYNACK------------------------------------| 349 |--TCP ACK, TLS ClientHello w/Resumption ------->| 350 |<-TLS ServerHello, ChangeCipherSpec, Finished --| 351 |--TLS ChangeCipherSpec, Finished, DNS query---->| 352 |<-DNS response----------------------------------| 353 | | | 355 Figure 9: NAT/Firewall State Loss, TLS 357 6. IANA Considerations 359 None. 361 7. Acknowledgements 363 Authors would like to thank Allison Mankin for comments and review. 365 8. References 367 8.1. Normative References 369 [I-D.ietf-dprive-dns-over-tls] 370 Zi, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 371 and P. Hoffman, "Specification for DNS over TLS", draft- 372 ietf-dprive-dns-over-tls-07 (work in progress), March 373 2016. 375 [I-D.ietf-dprive-dnsodtls] 376 Reddy, T., Wing, D., and P. Patil, "DNS over DTLS 377 (DNSoD)", draft-ietf-dprive-dnsodtls-04 (work in 378 progress), January 2016. 380 8.2. Informative References 382 [I-D.ietf-tls-tls13] 383 Rescorla, E., "The Transport Layer Security (TLS) Protocol 384 Version 1.3", draft-ietf-tls-tls13-11 (work in progress), 385 December 2015. 387 [I-D.isomaki-rtcweb-mobile] 388 Isomaki, M., "RTCweb Considerations for Mobile Devices", 389 draft-isomaki-rtcweb-mobile-00 (work in progress), July 390 2012. 392 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 393 Layer Security (TLS) and Datagram Transport Layer Security 394 (DTLS) Heartbeat Extension", RFC 6520, 395 DOI 10.17487/RFC6520, February 2012, 396 . 398 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 399 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 400 . 402 Authors' Addresses 404 Dan Wing 405 Cisco Systems, Inc. 406 170 West Tasman Drive 407 San Jose, California 95134 408 USA 410 Email: dwing@cisco.com 412 Tirumaleswar Reddy 413 Cisco Systems, Inc. 414 Cessna Business Park, Varthur Hobli 415 Sarjapur Marathalli Outer Ring Road 416 Bangalore, Karnataka 560103 417 India 419 Email: tireddy@cisco.com