idnits 2.17.00 (12 Aug 2021) /tmp/idnits36346/draft-huitema-tls-dtls-as-subtransport-00.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 both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 118: '... The keywords MUST, MUST NOT, REQUIR...' RFC 2119 keyword, line 119: '... SHOULD NOT, RECOMMENDED, MAY, and O...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2015) is 2627 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: draft-ietf-tls-tls13 has been published as RFC 8446 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Huitema 3 Internet-Draft Microsoft 4 Intended status: Informational E. Rescorla 5 Expires: September 6, 2015 Mozilla 6 J. Iyengar 7 Google 8 March 5, 2015 10 DTLS as Subtransport protocol 11 draft-huitema-tls-dtls-as-subtransport-00.txt 13 Abstract 15 The developers of "user level" transports will benefit from a 16 standard implementation of authentication and encryption. This can 17 be achieved using DTLS as a sub-transport. Using DTLS enables 18 developers to benefit from the investment in TLS, and removes the 19 burden and the risks of re-creating similar technology. 21 There are several requirements to ensure that DTLS is a suitable sub- 22 transport: zero RTT setup, low overhead, and DOS prevention. The IAB 23 SEMI workshop outlined other potential requirements: start/stop 24 indication, and ability to accept indications from the network. The 25 draft presents guidelines for meeting these requirements in a new 26 version of DTLS. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 6, 2015. 45 Copyright Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 64 2. DTLS as a sub transport . . . . . . . . . . . . . . . . . . . 3 65 3. Efficient retransmissions . . . . . . . . . . . . . . . . . . 4 66 4. Zero-RTT with TLS/1.3 . . . . . . . . . . . . . . . . . . . . 5 67 5. Overhead reduction . . . . . . . . . . . . . . . . . . . . . 5 68 6. DOS resilience . . . . . . . . . . . . . . . . . . . . . . . 6 69 7. Connection-id option . . . . . . . . . . . . . . . . . . . . 7 70 8. Start/stop indication . . . . . . . . . . . . . . . . . . . . 7 71 9. Indication verification . . . . . . . . . . . . . . . . . . . 8 72 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 75 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 13.1. Normative References . . . . . . . . . . . . . . . . . . 10 77 13.2. Informative References . . . . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 80 1. Introduction 82 There is a growing demand to develop "user level" transport, 83 motivated by "innovation" and "deployment." The innovation part is 84 the desire to get better performance than TCP, or especially the 85 combination of TCP and TLS, addressing such issues as zero-RTT setup 86 or head of queue blocking. The deployment part is motivated by 87 observation that platform upgrades are slow, and typically only reach 88 a fraction of the deployed systems. The proposed solution is to 89 execute the transport functions in user space, so the transport 90 innovation can be distributed with application updates. 92 Any transport innovation has to work on top of an encryption layer. 93 This is good security practice, and it also prevent middleboxes from 94 interfering with the transport functions. This interference with TCP 95 is widespread and effectively blocks innovation, making it hard to 96 deploy even something as simple as ECN. Encryption prevents the 97 middle boxes from twiddling bits in the header. For example, 98 Google's QUIC [QUICBLOG]. protocol uses an encryption system that is 99 tightly integrated with the transport layer in order to optimize 100 performance and reduce the protocol's accessibility to middleboxes. 102 QUIC uses a specially designed security layer, but there was a 103 consensus in the IAB SEMI workshop [IABSEMI] that we don't want 104 multiple applications each designing their specific key exchange and 105 encryption algorithms. The natural solution is to base the end-to- 106 end transports on a standard security layer, allowing transport 107 specialists can worry about efficient retransmission, congestion and 108 multiplexing, while security specialists can implement the security 109 layer. 111 The obvious candidate is DTLS [RFC6347], as the general idea of "TLS 112 over UDP" allows us to reuse the TLS experience and the TLS 113 implementations. Of course, we may need to work on a new features to 114 meet transport requirements. 116 1.1. Requirements 118 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 119 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 120 document, are to be interpreted as described in [RFC2026]. 122 2. DTLS as a sub transport 124 Examination of DTLS to the requirements for a subtransport layer 125 reveals some areas for improvement. 127 Efficient retransmissions: Part of the rationale for doing new 128 transports is to explore efficient retransmission strategies, but 129 this conflicts with the existing retransmission procedures that 130 are embedded in standard DTLS. 132 Zero-RTT setup: DTLS/1.2's minimum connection setup requires 1-RTT. 133 One of the major performance targets for new transports is low- 134 latency, motivating a 0-RTT connection setup. 136 Low overhead: DTLS/1.2 record headers include elements like version 137 number, epoch, sequence number or clear text length that cause a 138 fair bit of overhead in a small UDP datagram. Using some form of 139 header compression would reduce that overhead. 141 DOS prevention: TLS over UDP offers a big surface area for DOS 142 attacks, as unauthenticated clients can ask a server to perform 143 expensive crypto or produce large responses. This is especially 144 true if we support 0-RTT. While DTLS has some defenses against 145 DoS attacks, they may need to be strengthened. 147 connection-id: DTLS/1.2 identifies connections using the 5 tuple. 148 Having an independent ID would allow for functionalities similar 149 to "TCP multipath." It would also facilitate the work of load 150 balancers in front of a server farm. 152 Discussions in the IAB SEMI workshop also pointed out that 153 middleboxes interaction would be easier to manage if the UDP 154 transport had some specific properties: 156 Start/stop: Many middleboxes need to assign state to UDP flows. For 157 example, NATs need to assign and maintain port mappings. UDP 158 flows do not have explicit beginning and end markers similar to 159 TCP SYN/FIN/RST flags. In the absence of such flags middleboxes 160 have to resort to timer based management. This in turn forces 161 applications to use periodic "keep alive" traffic, which is 162 inefficient. 164 Indication verification: Middleboxes may wish to send informative 165 messages similar to ICMP, providing for example indications about 166 MTU size or congestion state. Application that receive these 167 messages need to differentiate between legitimate data coming from 168 network elements "on the path" and fake signals coming from 169 attackers. This is easier if the messages coming from the network 170 can copy hard to predict header elements like connection-id or 171 sequence numbers. 173 It is not yet clear whether these features are feasible or 174 deployable, but we document them here as an outcome of the IAB SEMI 175 discussion. 177 3. Efficient retransmissions 179 Protocols like QUIC implement innovative retransmission strategies, 180 combining Forward Error Correction with selective acknowledgements 181 and selective retransmissions. DTLS implements a minimalist 182 retransmission strategy for the messages that are part of the 183 handshake protocol, as explained in section 3.2 of [RFC6347]. This 184 creates a tension between adhering to the standard and efficient 185 retransmission: 187 o One could keep the QUIC retransmission for the handshake packets 188 and switch to an innovative transport for the reminder of the 189 connection. The downside is that using less efficient transport 190 during the handshake risk can cause additional latency, which is 191 contrary to the objective of transport innovation. 193 o One could design an innovative transmission as a layer under the 194 TLS framing, effectively redesign the layering of DTLS. This 195 solves the efficiency issues, but expose the clear-text 196 transmission controls to interference by middle-boxes, which may 197 ultimately prevent innovation. 199 o One could consider a hybrid design that allows clear text 200 innovation for the initial handshake and encrypted innovation for 201 data retransmissions, but no such design is available yet. 203 To put it simply, there is no consensus yet on a good solution to 204 this problem. 206 4. Zero-RTT with TLS/1.3 208 Probably the biggest requirement is to have a 0-RTT connection setup, 209 meaning that the initiator (typically the "client") can start sending 210 protected upper-level data in its initial flight of datagrams. In 211 general, a 0-RTT handshake requires that both the client and server 212 retain state: 214 o The client must retain the server's parameters, including a long- 215 term cryptographic key. 217 o The server must retain enough state to detect replays of the 218 client's initial flight. 220 In DTLS 1.2 and before, the client and server are both assumed to be 221 naive and so the first round-trip is used to establish this state. 222 This is still necessary for situations where the client and server 223 have never talked before and have no out-of-band communications 224 channel, but if both sides are primed, it is possible to define a 225 0-RTT handshake as well. Such a mode will be part of (D)TLS 1.3 and 226 is currently under development in the TLS WG. 228 5. Overhead reduction 230 DTLS is not generally very aggressive about conserving per-packet 231 overhead. The minimum DTLS record adds 13 bytes of header to the 232 packet and the common AES-GCM cipher suites add another 8 bytes or a 233 total of 21 bytes of header overhead (plus the authentication tag, 234 which is required). While these header bytes are not entirely 235 redundant (for instance, the sequence number allows the receiver to 236 deal with reordered packets) they are largely redundant in the common 237 case where the network mostly delivers packets in order essentially 238 every record is application data. 240 For maximum efficiency, it is desirable to have a mechanism for 241 compressing this data. [I-D.modadugu-dtls-short] describes one set 242 of techniques for doing so, though research into the optimal method 243 is still required. 245 6. DOS resilience 247 Our principal DoS concerns are: 249 o Preventing resource over-consumption on the server. 251 o Preventing the server from being used as a traffic amplifier. 253 Because TLS runs over TCP, it inherits TCP's DoS resistance 254 properties: an attacker must first establish a TCP connection before 255 he can talk to the TLS implementation. This generally means 256 demonstrating that he can receive traffic at the IP address he is 257 sending from. This significantly reduces the risk of amplification 258 and allows the server to differentially throttle traffic from clients 259 which appear to be sending bogus handshakes. The result is partial 260 protection against resource consumption attacks, but an attacker can 261 still mount such attacks if they control a large number of IP 262 addresses. 264 Any protocol which runs directly over UDP -- as DTLS does -- not 265 inherit these properties. DTLS already has anti-DoS measures in the 266 form of a cookie exchange which allows the server to force the client 267 to prove reachability at a given address. This is the standard 268 technique for addressing resource consumption attacks with such 269 protocols and can be deployed differentially (i.e., only when under 270 attack) to reduce the latency impact at normal times. Other 271 techniques which have been proposed for (D)TLS include computational 272 puzzles. 274 The DTLS cookie exchange also prevents amplification attacks but 275 because the server does not generally know when it is being used in 276 this fashion, it is harder to know where to set the protection/ 277 latency tradeoff. It is currently unclear how important 278 amplification protection is (DNS already has significant 279 amplification vectors) but if so, possible techniques include longer- 280 term cookies and forcing the client to pad its initial flight, thus 281 reducing the impact of amplification. 283 7. Connection-id option 285 Many UDP applications identify the application connection implicitly 286 from the "five tuple" of source and destination addresses and ports, 287 and payload type. There are however several potential advantages to 288 having an explicit "connection-id:" 290 o Enabling applications to use several ports and path in parallel, 291 for performance or resiliency, 293 o Enabling seamless continuation of an application over a new port 294 if the preceding port becomes unusable. 296 The latter problem, ports becoming unusable, is often caused by NAT 297 traversal. NAT are known to forget UDP mappings if they don't see 298 traffic for some period, or for some other reason such as for example 299 hash table collision. Applications must be ready to quickly 300 reestablish their connectivity. Using an explicit connection-id 301 makes this reestablishment straighforward. 303 The connection-id could be encoded as a header parameter, and its use 304 negotiated during the initial handshake, using techniques similar to 305 the parameters negotiation proposed in [I-D.modadugu-dtls-short]. 307 8. Start/stop indication 309 Middleboxes like NAT or firewall assign some state to the UDP flows, 310 such as for example a port mapping in a NAT or an explicit port 311 opening in a firewall. For TCP flows, middleboxes can examine TCP 312 flags and deduce when they see FIN or RST flags that the connection 313 is getting closed. They can then free the state associated with the 314 TCP flow. There are no such flags in UDP packets. The start of a 315 flow can be deduced implicitly from the arrival of a first packet for 316 that flow, but the end cannot. Middleboxes have to resort to timer 317 based management. The timers have to be short, and this drives 318 applications to send frequent keep-alive packets to make sure that 319 port mappings and port opening persists. An explicit indication 320 would enable more efficient management of resource. 322 TLS and DTLS include an explicit close mechanism, in which the 323 parties use the TLS Alert protocol and exchange "close notify" 324 messages. Sending such an alert message indicates that the sending 325 party is done, and will not send any more messages in the TLS 326 session. When both parties have sent a "close notify" message, the 327 session is effectively terminated. 329 If a middlebox could monitor the transmission of "close notify" 330 messages, it could effectively decide when resource can be disposed. 332 However, the alert protocol is part of the encrypted payload, and the 333 only visible indication in the clear text header is a "Content type" 334 indication set to "Alert", indicating that the encrypted payload 335 contains an Alert message. Closure indication is only one of the 336 usages of the Alert protocol, the other usages being error indication 337 and warning indication. A middlebox that monitors Alert messages 338 will only get an imperfect indication of the connection state: 340 o A closure message indicates that one party has finished sending, 341 and waits until a similar closure message from the other end to 342 terminate the session, 344 o An error message indicates that one party detected an error, will 345 not send any more data, and will not accept any more data from the 346 other party, 348 o A warning message indicates that one party detected an anomaly, 349 but that the session can continue. 351 The middlebox can gain information about the state of a DTLS 352 connection by monitoring the Alert messages, even if that information 353 is imperfect. Alternatively, we could consider adding an explicit 354 FIN bit in a revised clear-text header. 356 We should note here that there is a potential tension between the 357 management of resource and the identification of sessions discussed 358 in Section 7. The use of the context identifier allows sessions to 359 spread over multiple addresses and ports, and also allows multiple 360 sessions to share the same addresses and ports. If such multiplexing 361 is in place, the middleboxes would have to allocate resources per 362 context rather than per address and port tuples, but would have no 363 guarantee to see all the alert messages for a specific session. 365 9. Indication verification 367 Middleboxes could send messages to applications, using ICMP or 368 perhaps simply sending UDP messages using the same five-tuple as the 369 application. Assuming that such messages can be delivered, the 370 application will have to verify that they come from a legitimate 371 source, for example a middlebox on the path providing an indication 372 about acceptable MTU. 374 There is always a risk that such indications will be misused, and 375 that malevolent third parties would try to provide false indications 376 in order to disrupt the application. The application must thus be 377 able to distinguish between legitimate and spurious indication. 379 The middlebox could echo some parameters of the clear text header in 380 order to "prove" that they are on path. Typical parameters would be 381 the context ID or the sequence numbers. For this to be effective, 382 these parameters should be "hard to guess," which implies for example 383 unpredictable assignment of context ID or initial sequence numbers. 384 Of course, such desire for unpredictability conflicts with the desire 385 for low overhead, as compressed headers are inherently easier to 386 predict than long numbers. 388 One question for any indication verification scheme is how much of 389 the connection the middlebox needs to be able to see. For instance, 390 if initial sequence numbers or DTLS handshake nonces are used to 391 demonstrate that the middlebox is on-path, then the middlebox needs 392 to be on-path for the entire connection and maintain connection 393 state. 395 10. Security Considerations 397 This document proposes that user level transports use DTLS as a 398 component, instead of inventing their own transport. We believe that 399 this componentized approach will avoid many of the pitfalls of 400 inventing or implementing special purpose security designs. Instead, 401 applications will benefit from the experience accured in the design 402 and evolution of TLS [RFC5246] and will be able to reuse already 403 developed TLS and DTLS implementations. 405 We note that there is a definitive DOS exposure when running a 406 cryptographic protocol over UDP, and that this exposure is increased 407 when we attempt to enable zero RTT setup. The risk and the 408 corresponding mitigations are described in Section 6. Here again, we 409 believe that it is beneficial to reuse the DOS mitigations developed 410 for DTLS and designed for the zero RTT setup options of TLS/1.3 411 [I-D.ietf-tls-tls13]. 413 Any start/stop mechanism solving the requirement presented in 414 Section 8 opens the door to an attack is similar to but distinct from 415 TCP RST attacks, where injected RST packets terminate connections. 416 An on path attacker could inject bogus packets with a "Stop" 417 indication, to cause connection state to be torn down at middleboxes, 418 potentially causing the connection to be abruptly terminated. The 419 middleboxes will not be able to separate these injected packets from 420 legitimate "Stop" packets sent by the endpoints, because they cannot 421 verify the end-to-end authentication of packets. 423 Participants to the SEMI workshop [IABSEMI] envisage a "path to 424 application" messaging system in which intermediate relays would 425 provide information to the application, such as for example MTU size 426 or congestion notification. Such messages would not benefit from the 427 end to end authentication and encryption provided by DTLS. Allowing 428 such messages exposes the application to denial of service attacks. 429 Some potential mitigations are described in Section 9 431 11. IANA Considerations 433 This draft references [I-D.modadugu-dtls-short], which proposed four 434 new extensions for DTLS. A future version of this draft will very 435 likely propose the registration of similar extensions, using the 436 mechanisms defined in [RFC5246] and [RFC6066]. 438 12. Acknowledgments 440 The inspiration for this draft came from discussions in the IAB SEMI 441 workshop, and from studies of the QUIC protocol. 443 13. References 445 13.1. Normative References 447 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 448 3", BCP 9, RFC 2026, October 1996. 450 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 451 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 453 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 454 Extension Definitions", RFC 6066, January 2011. 456 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 457 Security Version 1.2", RFC 6347, January 2012. 459 13.2. Informative References 461 [I-D.ietf-tls-tls13] 462 Dierks, T. and E. Rescorla, "The Transport Layer Security 463 (TLS) Protocol Version 1.3", draft-ietf-tls-tls13-04 (work 464 in progress), January 2015. 466 [I-D.modadugu-dtls-short] 467 Modadugu, N. and E. Rescorla, "Extensions for Datagram 468 Transport Layer Security (TLS) in Low Bandwidth 469 Environments", draft-modadugu-dtls-short-00 (work in 470 progress), March 2006. 472 [IABSEMI] Kuehlewind, M. and B. Trammell, "IAB Workshop on Stack 473 Evolution in a Middlebox Internet (SEMI)", Jan 2015, 474 . 476 [QUICBLOG] 477 Roskind, J., "Experimenting with QUIC", June 2013, 478 . 481 Authors' Addresses 483 Christian Huitema 484 Microsoft 486 Email: huitema@microsoft.com 488 Eric Rescorla 489 Mozilla 491 Email: ekr@rtfm.com 493 Jana Iyengar 494 Google 496 Email: jri@google.com