idnits 2.17.1 draft-rescorla-dtls-in-sdp-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 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 284: '...er with the role "client" and MUST use...' RFC 2119 keyword, line 289: '...ptimization, in which case it MUST use...' RFC 2119 keyword, line 293: '... wire. It MAY also choose to sen...' RFC 2119 keyword, line 297: '... The offerer MUST be able to detect ...' RFC 2119 keyword, line 300: '...s, implementations MUST maintain these...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 31, 2016) is 2734 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ChangeCipherSpec' is mentioned on line 516, but not defined -- Looks like a reference, but probably isn't: '1' on line 458 -- Looks like a reference, but probably isn't: '2' on line 461 -- Looks like a reference, but probably isn't: '3' on line 464 -- Looks like a reference, but probably isn't: '4' on line 522 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-14 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4572 (Obsoleted by RFC 8122) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-01) exists of draft-thomson-avtcore-sdp-uks-00 -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTCWEB WG E. Rescorla 3 Internet-Draft RTFM, Inc. 4 Intended status: Informational October 31, 2016 5 Expires: May 4, 2017 7 Piggybacked DTLS Handshakes in SDP 8 draft-rescorla-dtls-in-sdp-01 10 Abstract 12 This document describes a mechanism for embedding DTLS handshake 13 messages in SDP descriptions. This technique allows implementations 14 to shave a full round-trip off of DTLS-SRTP session establishment, 15 while retaining compatibility with ordinary DTLS-SRTP endpoints. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on May 4, 2017. 34 Copyright Notice 36 Copyright (c) 2016 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 53 2.1. DTLS 1.2 . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.2. DTLS 1.3 . . . . . . . . . . . . . . . . . . . . . . . . 5 55 3. Attribute Definition . . . . . . . . . . . . . . . . . . . . 7 56 4. Interactions . . . . . . . . . . . . . . . . . . . . . . . . 7 57 4.1. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 4.2. Forking . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 4.3. RTCWEB Identity . . . . . . . . . . . . . . . . . . . . . 8 60 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 65 8.2. Informative References . . . . . . . . . . . . . . . . . 10 66 8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 Appendix A. Speculative: Server False-Start . . . . . . . . . . 11 68 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 13 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 71 1. Introduction 73 DTLS-SRTP [RFC5763][RFC5763] uses a DTLS [RFC6347] handshake to 74 establish keys which are then used to key SRTP [RFC3711]. The DTLS 75 negotiation is tied to the offer/answer [RFC3264] transaction via an 76 "a=fingerprint" attribute [RFC4572] in the SDP [RFC4566]. The common 77 message flow is shown below for DTLS 1.2. 79 This figure and the rest of this document adopt the following 80 assumptions about network behavior: 82 o ICE [RFC5245] is in use but that both endpoints implement 83 endpoint-independent filtering [RFC5389] so that STUN checks 84 succeed immediately. 86 o Signaling messages take the same time to be delivered as direct 87 messages [this is generally false.] 89 Links to detailed diagrams with a more accurate vertical scale can be 90 found below each diagram. 92 Alice Signaling Service Bob 93 ----------------------------------------------------------- 94 ^ Offer + fingerprint ---------> 95 | Offer + fingerprint --------> ^ 96 | | 97 | <------ Answer + fingerprint | 98 | <-------- Answer + fingerprint | 99 | <------------------------------------------------- STUN-REQ | 100 | STUN-REQ -------------------------------------------------> | 101 | STUN-RESP-------------------------------------------------> | 102 | <--------------------------------------------- ClientHello | 103 | <------------------------------------------------ STUN-RESP | 104 4 | 105 R ServerHello | 106 T ServerKeyExchange | 107 T Certificate 3 108 | CertificateRequest R 109 | ServerHelloDone -----------------------------------------> T 110 | T 111 | ClientKeyExchange | 112 | Certificate | 113 | CertificateVerify | 114 | [ChangeCipherSpec] | 115 | <------------------------------------------------ Finished | 116 | | 117 | [ChangeCipherSpec] | 118 | Finished -------------------------------------------------> | 119 | Media ----------------------------------------------------> v 120 v <------------------------ Media---------------------------- 122 Figure 1: Standard DTLS-SRTP Negotiation 124 Better picture [1] 126 In this flow, the earliest that Alice can start sending media is 127 after receiving Bob's Finished and the earliest Bob can start sending 128 media is upon receiving Alice's Finished, and neither side can send 129 any DTLS messages until they have had a successful STUN check. The 130 result is that in the best case, Alice receives media four round 131 trips after sending the offer and Bob receives media three round 132 trips after receiving Alice's offer. 134 This document describes a technique for improving call setup time by 135 piggybacking the first round of DTLS messages on the signaling 136 messages. This reduces latency by a full round trip for both DTLS 137 1.2 and DTLS 1.3 handshakes, and for DTLS 1.3 [I-D.ietf-tls-tls13] 138 allows the answerer to start sending media immediately upon receiving 139 the offer, or, if ICE is used, upon ICE completion. 141 2. Protocol Overview 143 The basic concept, as shown in Figure 2, is for Alice to send her 144 ClientHello in her Offer and Bob to send the server's first flight 145 (ServerHello...ServerHelloDone for DTLS 1.2) in his Answer. 147 2.1. DTLS 1.2 149 Alice Signaling Service Bob 150 ----------------------------------------------------------- 151 ^ Offer 152 | + fingerprint 153 | + ClientHello ---------> 154 | Offer 155 | + fingerprint 156 | + ClientHello ------------> ^ 157 | | 158 | Answer | 159 | + fingerprint | 160 | + ServerHello | 161 | + ServerKeyExchange | 162 | + Certificate | 163 | + CertificateRequest | 164 | <------------ ServerHelloDone | 165 3 | 166 T Answer 2 167 T + fingerprint R 168 T + ServerHello T 169 | + ServerKeyExchange T 170 | + Certificate | 171 | + CertificateRequest | 172 | <------------ ServerHelloDone | 173 | <------------------------------------------------ STUN-REQ | 174 | STUN-REQ -------------------------------------------------> | 175 | STUN-RESP-------------------------------------------------> | 176 | <------------------------------------------------ STUN-RESP | 177 | ClientKeyExchange | 178 | Certificate | 179 | CertificateVerify | 180 | [ChangeCipherSpec] | 181 | Finished -------------------------------------------------> v 182 | Media ----------------------------------------------------> 183 | [ChangeCipherSpec] 184 | <------------------------------------------------ Finished 185 v <--------------------------------------------------- Media 187 Figure 2: Piggybacked DTLS-SRTP Negotiation (TLS 1.2) 189 Better picture [2] 191 Note that in this flow, the active/passive (DTLS client/server) roles 192 are reversed and Alice becomes the client. Because this is a 193 basically symmetrical transaction, this is not an issue. 195 It should be immediately apparent that this exchange shaves off a 196 full round trip from Bob's perspective (despite actually only shaving 197 a half a round trip from the number of messages). The reason is that 198 Bob does not need to wait for Alice's Finished to send but can 199 piggyback his data on his Finished. 201 This change also shaves off a round trip from Alice's perspective 202 because Alice can now safely perform TLS False Start 203 [I-D.ietf-tls-falsestart] and send traffic prior to receiving Bob's 204 Finished message. When only fingerprints are carried in the 205 handshake, then extensions such as [RFC7301] indicators and DTLS-SRTP 206 negotiation are not protected. However, in this case because those 207 indicators are carried in the hello messages which are now tied to 208 the signaling channel, they are authenticated via the same mechanisms 209 that authenticate the fingerprint. 211 Note: One could argue that under some conditions Bob could do False 212 Start in the ordinary handshake, but it's much harder to analyze and 213 even then it leaves Alice one round trip slower than she would be 214 with this optimization. 216 2.2. DTLS 1.3 218 Figure Figure 3 shows the impact of this optimization on DTLS 1.3. 220 Alice Signaling Service Bob 221 ----------------------------------------------------------- 222 ^ Offer 223 | + fingerprint 224 | + ClientHello ---------> 225 | Offer 226 | + fingerprint 227 | + ClientHello ------------> ^ 228 | | 229 | Answer | 230 | + fingerprint | 231 | + ServerHello | 232 | + CertificateRequest | 233 | + Certificate | 234 | + CertificateVerify | 235 | <------------------- Finished | 236 | Answer | 237 3 + fingerprint | 238 R + ServerHello 2 239 T + CertificateRequest R 240 T + Certificate T 241 | + CertificateVerify T 242 | <------------------- Finished | 243 | <------------------------------------------------ STUN-REQ | 244 | STUN-REQ -------------------------------------------------> | 245 | STUN-RESP-------------------------------------------------> | 246 | <------------------------------------------------ STUN-RESP | 247 | | 248 | ClientKeyExchange | 249 | Certificate | 250 | CertificateVerify | 251 | [ChangeCipherSpec] | 252 | Finished -------------------------------------------------> | 253 | Media ----------------------------------------------------> v 254 | [ChangeCipherSpec] 255 | <------------------------------------------------ Finished 256 v <--------------------------------------------------- Media 258 Figure 3: Piggybacked DTLS-SRTP Negotiation (TLS 1.3) 260 Better picture [3] 262 Alice cannot send any sooner than with DTLS 1.2 because sending at 263 the point when she receives Bob's first message is already optimal. 264 It may be possible for Bob to shave off yet another round trip, 265 however. As described in Appendix A. 267 3. Attribute Definition 269 This document defines a new media-level SDP attribute, "a=dtls- 270 message". This message is used to contain DTLS messages. The syntax 271 of this attribute is: 273 attribute =/ dtls-message-attribute 275 dtls-message-attribute = "dtls-message" ":" role SP value 277 role = "client" / "server" 279 value = 1*(ALPHA / DIGIT / "+" / "/" / "=" ) 280 ; base64 encoded message 282 An offeror which wishes to use the optimization defined in this 283 document shall send his ClientHello in the "a=dtls-message" attribute 284 of its initial offer with the role "client" and MUST use 285 "a=setup:actpass". This allows the peer to either: 287 o Reject the optimization, in which case it ignores the attribute. 289 o Accept the optimization, in which case it MUST use 290 "a=setup:passive" and send its first flight (starting with 291 ServerHello) and using the role "server" in its response. These 292 messages are simply serialized end-to-end as they would be on the 293 wire. It MAY also choose to send its first flight separately in 294 the media channel; DTLS implementations already handle retransmits 295 properly. 297 The offerer MUST be able to detect whether an incoming DTLS message 298 is a ClientHello or a ServerHello and adapt accordingly. 300 In subsequent negotiations, implementations MUST maintain these 301 roles. 303 4. Interactions 305 This optimization has a number of interactions with existing pieces 306 of protocol machinery. 308 4.1. ICE 310 When ICE is in use, there is a race condition between the answerer's 311 ICE checks (at which point it will be able to send the first flight 312 on the media channel) and the answerer's Answer, which contains the 313 first flight. For this reason, we allow implementations to send the 314 first flight on both channels. However, as a practical matter it is 315 reasonably likely that when ICE is in use the Answer will arrive 316 first, for two reasons: 318 o The answerer consumes a full RTT doing a STUN check to verify the 319 path to the offerer (even in the best case where the first STUN 320 check succeeds). Thus, even if the path through the signaling 321 server is twice as expensive as the direct path, there is a 322 reasonable chance that the answer will arrive first. 324 o If the offerer is behind a NAT without endpoint-independent 325 filtering, the answerer's ICE checks will be discarded until the 326 offerer sends its own ICE checks, which it can only do upon 327 receiving the answer. 329 In this case, although a comparison of Figure 1 and Figure 2 would 330 show the ClientHello (in ordinary DTLS) and the ServerHello (when 331 piggybacked) as arriving at the same time, in fact the ServerHello 332 may arrive up to a full RTT first, but the offerer can SEND its 333 second flight immediately upon its STUN check succeeding, which 334 happens first, thus increasing the advantage of this technique. 336 4.2. Forking 338 This technique does not interact very well with forking. Because 339 each ClientHello is only usable for one server, the system must 340 somehow ensure that only one of the forks takes up the piggybacked 341 offers. The easiest approach is for any intermediary which does a 342 fork to strip out the "a=dtls-message" attribute. An alternative 343 would be to add another attribute which could be stripped out (this 344 might interact better with RTCWEB Identity). Note that [RFC4474] 345 protects against any SDP modifications, but I think at this point 346 it's clear that that's not practical. 348 4.3. RTCWEB Identity 350 RTCWEB Identity assertions need to cover these DTLS messages. 352 5. Examples 354 [we need examples.] 356 6. Security Considerations 358 The security implications of this technique are described throughout 359 this document. 361 7. IANA Considerations 363 This specification defines the "dtls-message" SDP attribute per the 364 procedures of Section 8.2.4 of [RFC4566]. The required information 365 for the registration is included here: 367 Contact Name: Eric Rescorla (ekr@rftm.com) 369 Attribute Name: dtls-message 371 Long Form: dtls-message 373 Type of Attribute: session-level 375 Charset Considerations: This attribute is not subject to the charset 376 attribute. 378 Purpose: This attribute carries piggybacked DTLS message. 380 Appropriate Values: This document 382 8. References 384 8.1. Normative References 386 [I-D.ietf-tls-falsestart] 387 Langley, A., Modadugu, N., and B. Moeller, "Transport 388 Layer Security (TLS) False Start", draft-ietf-tls- 389 falsestart-02 (work in progress), May 2016. 391 [I-D.ietf-tls-tls13] 392 Rescorla, E., "The Transport Layer Security (TLS) Protocol 393 Version 1.3", draft-ietf-tls-tls13-14 (work in progress), 394 July 2016. 396 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 397 with Session Description Protocol (SDP)", RFC 3264, 398 DOI 10.17487/RFC3264, June 2002, 399 . 401 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 402 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 403 RFC 3711, DOI 10.17487/RFC3711, March 2004, 404 . 406 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 407 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 408 July 2006, . 410 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 411 Transport Layer Security (TLS) Protocol in the Session 412 Description Protocol (SDP)", RFC 4572, 413 DOI 10.17487/RFC4572, July 2006, 414 . 416 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 417 (ICE): A Protocol for Network Address Translator (NAT) 418 Traversal for Offer/Answer Protocols", RFC 5245, 419 DOI 10.17487/RFC5245, April 2010, 420 . 422 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 423 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 424 DOI 10.17487/RFC5389, October 2008, 425 . 427 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 428 for Establishing a Secure Real-time Transport Protocol 429 (SRTP) Security Context Using Datagram Transport Layer 430 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 431 2010, . 433 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 434 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 435 January 2012, . 437 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 438 "Transport Layer Security (TLS) Application-Layer Protocol 439 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 440 July 2014, . 442 8.2. Informative References 444 [I-D.thomson-avtcore-sdp-uks] 445 Thomson, M. and E. Rescorla, "Unknown Key Share Attacks on 446 uses of Transport Layer Security with the Session 447 Description Protocol (SDP)", draft-thomson-avtcore-sdp- 448 uks-00 (work in progress), October 2016. 450 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 451 Authenticated Identity Management in the Session 452 Initiation Protocol (SIP)", RFC 4474, 453 DOI 10.17487/RFC4474, August 2006, 454 . 456 8.3. URIs 458 [1] https://raw.githubusercontent.com/ekr/dtls-in-sdp/master/normal- 459 12.png 461 [2] https://raw.githubusercontent.com/ekr/dtls-in-sdp/master/ 462 piggybacked-12.png 464 [3] https://raw.githubusercontent.com/ekr/dtls-in-sdp/master/ 465 piggybacked-13.png 467 [4] https://raw.githubusercontent.com/ekr/dtls-in-sdp/master/ 468 piggybacked-13-falsestart.png 470 Appendix A. Speculative: Server False-Start 472 WARNING: THE FOLLOWING SECTION HAS NOT RECEIVED ANY REAL SECURITY 473 REVIEW AND MAY BE A REALLY BAD IDEA. 475 It has been observed that as if Alice uses a fresh DH ephemeral, then 476 Bob knows (because he can trust the signaling service) that Alice's 477 DH ephemeral corresponds to Alice and can therefore encrypt under the 478 joint DH shared secret without waiting for Alice's CertificateVerify, 479 as shown in Figure 4. 481 Alice Signaling Service Bob 482 ----------------------------------------------------------- 483 ^ Offer 484 | + fingerprint 485 | + ClientHello ---------> 486 | Offer 487 | + fingerprint 488 | + ClientHello ------------> ^ 489 | | 490 | Answer | 491 | + fingerprint | 492 | + ServerHello | 493 2 + CertificateRequest | 494 R + Certificate | 495 T + CertificateVerify | 496 T <------------------- Finished | 497 | Answer | 498 | + fingerprint | 499 | + ServerHello 2 500 | + CertificateRequest R 501 | + Certificate T 502 | + CertificateVerify T 503 | <------------------- Finished | 504 | <------------------------------------------------ STUN-REQ | 505 | STUN-REQ -------------------------------------------------> | 506 | STUN-RESP-------------------------------------------------> | 507 v <--------------------------------------------------- Media | 508 <------------------------------------------------ STUN-RESP | 509 | 510 ClientKeyExchange | 511 Certificate | 512 CertificateVerify | 513 [ChangeCipherSpec] | 514 Finished -------------------------------------------------> | 515 Media ----------------------------------------------------> v 516 [ChangeCipherSpec] 517 <------------------------------------------------ Finished 519 Figure 4: Piggybacked DTLS-SRTP Negotiation (TLS 1.3 with false 520 start) 522 Better picture [4] 524 This has demonstrably inferior security properties if Alice is using 525 a long-term key (for key continuity or fingerprint validation), 526 because Bob has not yet verified that Alice controls that key and 527 does not even know if Alice is using a fresh DH ephemeral, if 528 implementations decide to adopt this optimization, they must do 529 something hacky like Send data immediately but generate an error if 530 the handshake, including a signature, does not complete within some 531 reasonable period (a small number of measured round trips) [Just one 532 reason why this is a questionable technique.]. This technique may 533 also complicate dealing with the issues raised in 534 [I-D.thomson-avtcore-sdp-uks]. 536 Appendix B. Acknowledgements 538 Thanks to Cullen Jennings, Martin Thomson, and Justin Uberti for 539 helpful suggestions. 541 Author's Address 543 Eric Rescorla 544 RTFM, Inc. 546 Email: ekr@rtfm.com