idnits 2.17.1 draft-rescorla-quic-over-dtls-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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 2 instances of too long lines in the document, the longest one being 6 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 05, 2018) is 2243 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Frame' is mentioned on line 285, but not defined == Missing Reference: 'B' is mentioned on line 349, but not defined == Missing Reference: 'C' is mentioned on line 349, but not defined == Unused Reference: 'RFC2119' is defined on line 751, but no explicit reference was found in the text == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-10 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-10 == Outdated reference: A later version (-13) exists of draft-ietf-tls-dtls-connection-id-00 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-26 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-26 Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC Working Group E. Rescorla 3 Internet-Draft RTFM, Inc. 4 Intended status: Informational March 05, 2018 5 Expires: September 6, 2018 7 QUIC over DTLS 8 draft-rescorla-quic-over-dtls-00 10 Abstract 12 QUIC in-band cryptographic negotiation on stream 0 creates a number 13 of odd edge cases. This document considers an alternative design in 14 which QUIC transport is run directly over DTLS, thus separating the 15 cryptographic negotiation from the transport piece. 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 September 6, 2018. 34 Copyright Notice 36 Copyright (c) 2018 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. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 4 53 2.1. Reliability . . . . . . . . . . . . . . . . . . . . . . . 6 54 2.1.1. DTLS Reliability and ACKs . . . . . . . . . . . . . . 6 55 2.1.2. RTT Estimation . . . . . . . . . . . . . . . . . . . 6 56 2.1.3. QUIC Reliability and ACKs . . . . . . . . . . . . . . 6 57 2.2. Version Negotiation . . . . . . . . . . . . . . . . . . . 7 58 2.3. Transport Parameters . . . . . . . . . . . . . . . . . . 8 59 2.4. Key Changes and New Session Ticket . . . . . . . . . . . 8 60 2.5. Connection IDs . . . . . . . . . . . . . . . . . . . . . 9 61 3. Required Changes to DTLS . . . . . . . . . . . . . . . . . . 9 62 3.1. Handshake Obfuscation . . . . . . . . . . . . . . . . . . 9 63 3.2. Obfuscation Negotiation Packet . . . . . . . . . . . . . 11 64 3.3. Packet Header Encryption . . . . . . . . . . . . . . . . 11 65 3.4. Stateless Reset . . . . . . . . . . . . . . . . . . . . . 11 66 4. Required Changes to QUIC Documents . . . . . . . . . . . . . 12 67 4.1. TLS Document . . . . . . . . . . . . . . . . . . . . . . 12 68 4.2. Transport Document . . . . . . . . . . . . . . . . . . . 12 69 4.3. Recovery Document . . . . . . . . . . . . . . . . . . . . 13 70 4.4. Invariants Document . . . . . . . . . . . . . . . . . . . 13 71 5. Potential Additional Benefits . . . . . . . . . . . . . . . . 13 72 5.1. Record Coalescence . . . . . . . . . . . . . . . . . . . 13 73 5.2. More Straightforward Demuxing . . . . . . . . . . . . . . 13 74 6. Potential Points of Concern . . . . . . . . . . . . . . . . . 13 75 6.1. Record Size/Overhead . . . . . . . . . . . . . . . . . . 14 76 6.2. Status of DTLS 1.3 Maturity . . . . . . . . . . . . . . . 14 77 6.3. Epoch and ACKs . . . . . . . . . . . . . . . . . . . . . 15 78 6.4. Crypto Layer Agility . . . . . . . . . . . . . . . . . . 15 79 7. WebRTC Binding . . . . . . . . . . . . . . . . . . . . . . . 15 80 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 16 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 83 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 84 10.2. Informative References . . . . . . . . . . . . . . . . . 17 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 87 1. Introduction 89 QUIC [I-D.ietf-quic-transport] [I-D.ietf-quic-tls] as currently 90 designed performs cryptographic negotiation by sending TLS 1.3 91 [I-D.ietf-tls-tls13] traffic directly in stream 0. This design was 92 the result of desiring to have tight coupling between the 93 cryptographic handshake and the transport and has a number of 94 advantages in that it allows the TLS 1.3 flow to take advantage of 95 QUIC's transport services, in particular reliable in-order delivery, 96 RTT estimation, etc. However, it also results in several unpleasant 97 corner cases: 99 o The cryptographic handshake stream is subject to a variety of odd 100 rules, such as: 102 * Stream 0 is unencrypted at the beginning of the connection, but 103 encrypted after the handshake completes. 105 * Stream 0 is not subject to flow control; it can exceed limits 106 and goes into negative credit after the handshake completes. 108 * Retransmission of stream 0 frames from lost packets needs 109 special handling to avoid accidentally encrypting them. 111 * Stream 0 offsets are reset after the server sends a Retry 112 packet. This creates special handling rules for the stream. 114 o The QUIC stack needs tight coupling with the TLS stack to know, 115 for instance, whether the TLS stack sent SH or HRR, or where the 116 boundaries are between flights. See, Issue #1094 for an example 117 of this kind of problem. 119 o There are complicated rules about which packets can ACK other 120 packets, as both cleartext and ciphertext ACKs are possible. 122 o The interaction of the state machine advancing (which makes clear 123 that packets have received) and ACKs is confusing. For instance, 124 it is possible to respond to an Initial packet but not ACK it. 125 The semantics of this are unclear. 127 o There are complicated rules for how to handle 0-RTT (and 128 especially 0-RTT failures). 130 o The stack needs to continue to service stream 0 indefinitely in 131 order to gather NewSessionTicket messages. 133 o QUIC version negotiation isn't authenticated, so it is 134 retroactively authenticated during the TLS handshake. 136 This document considers a design at the other end of the spectrum, 137 which is to layer QUIC transport over DTLS 1.3 [I-D.ietf-tls-dtls13] 138 (with some small pieces of coupling). This design addresses most of 139 the corner cases described above, although it does introduce some new 140 issues which must be considered. 142 2. Design Overview 144 The current QUIC/TLS integration treats TLS as a module which gets a 145 lot of its services from QUIC. I.e., something like this: 147 +-------+-------+ 148 | TLS | App | 149 | | Data | 150 +-----------------+-------+-------+ 151 | Other Frames | Streams | 152 +-----------------+---------------+ 153 | Envelope | 154 +---------------------------------+ 155 | UDP | 156 +---------------------------------+ 158 Figure 1: Current QUIC Architecture 160 This creates a relatively complicated interaction, as shown in the 161 following diagram from [I-D.ietf-quic-tls]. 163 +------------+ +------------+ 164 | |------ Handshake ------>| | 165 | |<-- Validate Address ---| | 166 | |-- OK/Error/Validate -->| | 167 | |<----- Handshake -------| | 168 | QUIC |------ Validate ------->| TLS | 169 | | | | 170 | |<------ 0-RTT OK -------| | 171 | |<------ 1-RTT OK -------| | 172 | |<--- Handshake Done ----| | 173 +------------+ +------------+ 174 | ^ ^ | 175 | Protect | Protected | | 176 v | Packet | | 177 +------------+ / / 178 | QUIC | / / 179 | Packet |-------- Get Secret -------' / 180 | Protection |<-------- Secret -----------' 181 +------------+ 183 Figure 2: QUIC/TLS Interactions 185 In the design proposed by this document, we have a more natural 186 layered structure, similar to that of HTTP2 over TLS. I.e., 187 +-------------------------+ 188 | QUIC | 189 +-------------------------+ 190 | DTLS | 191 +-------------------------+ 192 | UDP | 193 +-------------------------+ 194 | IP | 195 +-------------------------+ 197 Figure 3: QUIC over DTLS architecture 199 Of course, you still need some signaling between QUIC and DTLS, but 200 it's largely the conventional signaling that any application protocol 201 over TLS needs. Specifically: 203 o It's possible to send data (in 0-RTT or 1-RTT) 205 o The handshake is complete 207 o Here are the cryptographic parameters 209 o The record number that corresponds to a given piece of data. 211 The only real special accommodation needed is to carry the QUIC 212 transport parameters, which you already needed in the current design 213 (although it's not shown). You may also want to expose DTLS's RTT 214 estimates to QUIC (see Section 2.1.2) but this is not necessary to 215 have a functional system. 217 Operationally, this is straightforward. You negotiate DTLS and then 218 send QUIC frames over DTLS as type application data, as shown in 219 Figure 4. 221 Client Server 223 CH --------------------------------------------------> 224 <------------------------------------------ SH ... FIN 225 <-------------------------------------- [ QUIC frames] 226 FIN -------------------------------------------------> 227 <------------------ [QUIC frames] -------------------> 229 Figure 4: Simple QUIC over DTLS 231 The payload of each application data DTLS record consist of QUIC 232 frames laid end to end, precisely as in current QUIC packets. 233 Because DTLS application data is always encrypted, this means that 234 the QUIC frames themselves are also encrypted. 236 When 0-RTT is used, things are as you expect, namely that QUIC frames 237 can be sent in the early data, as shown in Figure 5. If 0-RTT is 238 rejected, then the frames can just be treated as lost and 239 retransmitted, though you probably want to do so immediately and some 240 care must not be taken to let this modify your congestion state. 242 Client Server 244 CH --------------------------------------------------> 245 [QUIC frames] ---------------------------------------> 246 <------------------------------------------ SH ... FIN 247 <-------------------------------------- [ QUIC frames] 248 FIN -------------------------------------------------> 249 <------------------ [QUIC frames] -------------------> 251 Figure 5: QUIC over DTLS with 0-RTT 253 2.1. Reliability 255 2.1.1. DTLS Reliability and ACKs 257 In this design, DTLS takes care of its own reliability for the 258 handshake (and for post-handshake messages) via a timeout and 259 retransmission scheme, including ACKs. DTLS ACKs apply only to 260 handshake records and so simply don't apply to QUIC frames at all. 261 DTLS ACKs apply to both encrypted and unencrypted handshake records. 263 2.1.2. RTT Estimation 265 One virtue of the current deisgn is that you get an RTT estimate from 266 the QUIC congestion control machinery for packets that are sent 267 during the handshake phase. Naively you would lose this, but DTLS 268 actually gives you a primitive estimate of this via its own 269 reliability mechanisms and ACKs. So the natural thing to do here is 270 to have the DTLS implementation derive an RTT estimate from the DTLS 271 handshake from the first round trip in each direction and then 272 provide it to the QUIC part of the stack as an initial estimate. 274 2.1.3. QUIC Reliability and ACKs 276 By contrast, QUIC ACKs only apply to application data records (which 277 contain encrypted QUIC frames) and are just sent with whatever the 278 current DTLS epoch is. 280 One subtlety here is what the QUIC ACKs acknowledge, because we no 281 longer have QUIC packets. One way of handling this would be to have 282 packet numbers as a header inside each application data record, 283 i.e.,: 285 [Packet Number] [Frame] [Frame]... [Frame] 287 However, this wastes space, so a better approach is to just refer to 288 the DTLS record number. This is the primary piece of layer violation 289 in this design in that the QUIC stack will need to be aware of: 291 o Which DTLS record number a given frame went out on 293 o Which DTLS record number a given frame came in on 295 This is a tiny bit ugly, but isn't complicated to implement. 297 2.2. Version Negotiation 299 In current QUIC, you negotiate two versions: 301 o The QUIC version by having the client propose a version and then 302 the server corrects it. 304 o The TLS version which is negotiated by having the client propose 305 all its versions and then the server selects one. 307 When we reorder QUIC and DTLS, a different design is appropriate. 308 DTLS currently doesn't encrypt the ClientHello, so obfuscation does 309 not immediately become an issue, and instead we can have both QUIC 310 and DTLS versions negotiated in the customary way, namely: the client 311 proposes two sets of versions: 313 o DTLS versions in "supported_versions" 315 o QUIC versions in "quic_versions" (new) 317 And then the server chooses its preference for both of them. 319 Assuming that we want to continue to have handshake obfuscation, we 320 will need to modify DTLS to allow this (more details about this in 321 Section 3.1), and then we can adopt the current scheme with a small 322 set of modifications. 324 o The records containing the ClientHello and ServerHello contain a 325 DTLS version. This reflects the version of DTLS whose obfuscation 326 constants are in use. 328 o If the server recognizes that version, then it simply decrypts the 329 handshake messages and does DTLS version negotiation mechanism 330 (see Figure 6). 332 o If the server doesn't recognize that version, it sends a VN packet 333 as with current QUIC (we would need to add this to DTLS). The 334 client then re-sends the ClientHello except obfuscated with a 335 different version. Note that you use the same 336 ClientHello.supported_versions and so an attacker cannot impact 337 DTLS version negotiation (see Figure 7). 339 Client Server 341 CH version = A[supported_versions = A, B, C] ---------> 342 <--------------- SH version = B [supported_version = B] 344 Figure 6: Version negotiation with compatible obfuscation 346 Client Server 348 CH version = A[supported_versions = A, B, C] ---------> 349 <--------------------------------- VN versions = [B, C] 350 CH version = B[supported_versions = A, B, C] ---------> 351 <--------------- SH version = B [supported_version = B] 353 Figure 7: Version negotiation with incompatible obfuscation 355 Note that this design is 1-RTT faster than the current design in 356 cases where the server has changed it's preferred version. In 357 current QUIC, that results in a VN, but here the server can just 358 remember the old constants, decrypt the record, and proceed with 359 negotiation as usual. 361 2.3. Transport Parameters 363 The QUIC transport parameters can be negotiated in DTLS extensions as 364 they currently are. 366 2.4. Key Changes and New Session Ticket 368 Because the QUIC frames are carried over DTLS, the DTLS stack 369 naturally reads and writes DTLS records that are not carrying 370 application data (primarily handshake) as well. This means that 371 post-handshake messages such as KeyUpdate and NewSessionTicket just 372 work naturally: the peer sends them and the DTLS stack consumes them, 373 transparently to the QUIC stack. Note that this is an improvement 374 over the current design, in which the QUIC stack needs to continue to 375 pass data back and forth to the TLS stack on stream 0. Key changes 376 just take effect according to the DTLS schedule. 378 2.5. Connection IDs 380 DTLS 1.3 has no native support for connection IDs, but instead has 381 farmed it out to a separate draft [I-D.ietf-tls-dtls-connection-id]. 382 That draft takes a slightly different strategy from QUIC in which 383 both sides provide the connection ID for the peer to use to send to 384 them. However, we are currently considering precisely such a design 385 in QUIC (see https://github.com/quicwg/base-drafts/issues/1089) in 386 which case, much of the design would drop into place. 388 The remainder of this document assumes that we are using asymmetric 389 connection IDs, as that seems like the direction we are going, but 390 this part of DTLS is still under active design and so could 391 presumably be modified to support QUIC's needs. 393 3. Required Changes to DTLS 395 Some modest changes would be needed for DTLS to ensure parity with 396 the current QUIC design. These changes would reuse design work we 397 have already done for QUIC. 399 In addition to the existing DTLS 1.3 capabilities and the connection 400 ID work, the following changes are needed: 402 o Handshake Obfuscation, Section 3.1 404 o Obfuscation Negotiation, Section 3.2 406 o Packet Number Encryption, Section 3.3 408 o Stateless Reset, Section 3.4 410 These would each add a generic capability to DTLS that could be used 411 by other protocols. 413 3.1. Handshake Obfuscation 415 As noted above, DTLS does not presently encrypt the ClientHello and 416 ServerHello messages (the remainder of the messages are in the 417 clear). However, there's an elegant way to handle this, as suggested 418 by Martin Thomson, which is to define the format of DTLSPlaintext as 419 being version specific. Recall the standard DTLSPlaintext: 421 struct { 422 ContentType type; 423 ProtocolVersion version; 424 uint16 epoch = 0 // DTLS field 425 uint48 sequence_number; // DTLS field 426 uint16 length; 427 opaque fragment[DTLSPlaintext.length]; 428 } DTLSPlaintext; 430 We can simply declare that when DTLSPlaintext.version is set to 1.3 431 or above, we instead have: 433 struct { 434 ContentType opaque_type = handshake; // Real CT inside the encryption 435 ProtocolVersion version; 436 opaque dst_conn_id<0..255> 437 opaque src_conn_id<0..255>; 438 uint16 epoch = 0 // DTLS field 439 uint48 sequence_number; // DTLS field 440 uint16 length; 441 opaque encrypted_record[length]; 442 } DTLSHandshakeCiphertext; 444 This format would be used only for the initial handshake and any 445 alerts or acks it generates (i.e., data in epochs 0, 1, and 2). For 446 epoch 0 (what would be plaintext in TLS 1.3), the obfuscation is done 447 essentially as with QUIC, i.e., with a KDF keyed with a per- 448 connection function and the dst CID. For all other epochs, you 449 encrypt just as you would with DTLS 1.3 today. 451 Note the difference here from TLS 1.3 in which these packets get 452 type=handshake, which with the record version tells us that the CID 453 variant is in use. 455 Note that this is essentially the same structure here as I recently 456 proposed for asymmetric CIDs. 458 An advantage of this design is that it has a natural "backward 459 compatible mode" for DTLS where you can use the old format if you 460 don't know what the peer supports (conventional D/TLS behavior) but 461 if you have a minimum version that's 1.3 or above you can get 462 obfuscation. 464 [[OPEN ISSUE: Grease the length bytes.]] 466 3.2. Obfuscation Negotiation Packet 468 In the case that the client chooses an obfuscation scheme that the 469 server does not understand, we need a way for the server to request a 470 different obfuscation scheme. 472 This is analogous to the QUIC Version Negotiation packet, but it only 473 negotiates the choice of obfuscation. Because it is separate from 474 the negotiation of the QUIC version, it can be much lighter weight. 476 We can more or less directly steal the QUIC Version Negotiation 477 scheme. That is, the server sends a list of supported versions in 478 place of the packet payload: 480 struct { 481 ContentType opaque_type = handshake; // Real CT inside the encryption 482 ProtocolVersion version = 0; 483 opaque dst_conn_id<0..255> 484 opaque src_conn_id<0..255>; 485 uint16 epoch = 0 // DTLS field 486 uint48 sequence_number; // DTLS field 487 uint16 length; 488 uint16 supported_versions<2..254>; 489 } DTLSObfuscationNegotiation; 491 Unlike the current design, where authenticating version negotiation 492 is critical, a downgrade attack only causes the ClientHello and 493 ServerHello to be protected with a different obfuscation scheme. 494 Because obfuscation does not affect the integrity of the protocol 495 negotiation there is no need to add separate authentication for this 496 exchange. 498 3.3. Packet Header Encryption 500 DTLS does not encrypt its packet number and also does not presently 501 have sequence number gaps, which makes changing connection IDs for 502 privacy of modest value. There's no reason we couldn't adapt the 503 same techniques we have discussed using for QUIC, when we get those 504 nailed down. Pretty much all the same issues apply to DTLS and QUIC 505 here. 507 3.4. Stateless Reset 509 As noted above, we would need to define stateless reset. The best 510 way to do this is to define a new extension in Encrypted Extensions 511 for this, so that it's usable for non-QUIC purposes. Otherwise the 512 mechanics can be identical to the current QUIC design in 513 Section 7.9.4 of [I-D.ietf-quic-transport]. 515 4. Required Changes to QUIC Documents 517 Obviously, we would require changes to the existing QUIC drafts to 518 make this work. Primarily it's a matter of removal. This section 519 covers the known changes. 521 4.1. TLS Document 523 This document is just removed entirely. We don't need it any more. 524 This removes all or nearly all the crypto from QUIC, and in 525 particular the somewhat complex key schedule, and leaves it in DTLS. 527 4.2. Transport Document 529 Much of this document also goes away. Specifically: 531 o We are folding the entire QUIC header into the DTLS header (and 532 stealing a lot of stuff in the process) so basically all of 533 Section 5 (Packet Types and Formats) away. 535 o We carry frame types directly over DTLS, so Section 6 (Frames and 536 Frame Types) stays, 538 o Essentially all of Section 7 (Life of a Connection) disappears, 539 and is replaced by the DTLS CID and new version negotiation scheme 540 carried in DTLS extensions (see Section 2.2). The connection 541 migration design works without modifications, so that would be 542 retained. Similarly, once the DTLS connection is established, 543 QUIC style connection close should be used, with the exception of 544 stateless reset and (optionally) if the DTLS layer decideas to 545 abort because of too many deprotection failures. The DTLS 546 close_notify was intended as unreliable and is therefore less 547 capable than QUIC's close. 549 o As noted above, ACKs stay essentially the same, but we will need 550 to change the encoding a bit to handle epoch changes, as described 551 in Section 2.1.3 and Section 6.3. 553 o Section 9 (Packetization and Reliability), 10 (Streams), and 11 554 (Flow Control) also stay the same. 556 o We'll want to trim down the error space (Section 12) a little bit 557 because we'll want to use DTLS alerts for a lot of errors. This 558 makes things easier because it avoids the confusion we have now 559 about whether to send a QUIC error or a TLS alert. 561 4.3. Recovery Document 563 Almost no changes, except for the rules about handshake recovery. 565 4.4. Invariants Document 567 We will need to modify the invariants to match the DTLS invariants, 568 but the principles are the same and the header/packet formats are 569 reasonably similar, so this should be straightforward. 571 5. Potential Additional Benefits 573 5.1. Record Coalescence 575 One challenge in QUIC has been that it is not possible to place two 576 QUIC packets in the same UDP datagram. This creates problems 577 whenever you would like to have two packets encrypted under different 578 keys sent together, as with the Initial packet and 0-RTT data, or 579 with 1-RTT data (which is encrypted) and the Finished message (which 580 is not). 582 With DTLS, however, this is straightforward. DTLS has three record 583 header formats: 585 o DTLSPlaintext 587 o DTLSCiphertext 589 o DTLSShortCiphertext 591 The first two of these have built-in length field and can therefore 592 be packed more than one to a UDP datagram. This allows for simple 593 piggybacking of records of different types. Obviously, this header 594 engineering could be done for QUIC, but its not something we have 595 done. 597 5.2. More Straightforward Demuxing 599 We have had extended discussions about how to demux QUIC with other 600 UDP protocols which might be on the same 5-tuple (principally for 601 WebRTC). Because the existing cases already use DTLS, carrying QUIC 602 over DTLS obviously makes this easier. 604 6. Potential Points of Concern 605 6.1. Record Size/Overhead 607 One concern we might have is about record overhead. It's a bit hard 608 to make a straight-up comparison between QUIC and DTLS 1.3 because 609 they make different assumptions about the length of the sequence 610 number field. As noted above, DTLS 1.3 as currently proposed has two 611 different header formats. The longer of the two has a 7 byte header 612 with a 30 bit sequence number and a length field. The shorter is 613 only two bytes with a 12 bit sequence number and no length field. In 614 addition, DTLS 1.3 has a one byte internal content type field that is 615 used to distinguish application data from handshake data and to 616 support padding. 618 DTLS has similar record overheads to QUIC, but with a larger increase 619 in size if a longer sequence number is needed. If that turns out to 620 be a problem, there are alternative designs that could be 621 contemplated. 623 6.2. Status of DTLS 1.3 Maturity 625 DTLS 1.3 is a small delta off of TLS 1.3. In Singapore there were no 626 remaining open issues, and a proposal to go to WGLC once we had more 627 implementation experience, which we are accumulating now, so absent 628 input from QUIC, I would expect DTLS to go to WGLC on London. Note 629 that due to the lower level of inspection of DTLS and the preexisting 630 need for hole-punching (e.g., WebRTC), the last minute middlebox 631 interop issues that delayed TLS 1.3 should not be an issue for DTLS. 633 However, conveniently this status allows us to get the small changes 634 described in Section 3 in before we close the document. The TLS WG 635 is very interested in coordinating with QUIC - and has many of the 636 same key players - so it should be possible to close these quickly 637 and proceed to DTLS 1.3 WGLC. 639 In general, DTLS 1.2 is reasonably widely implemented, though not as 640 widely implemented as TLS. All the major browser stacks already have 641 it to support WebRTC. DTLS 1.3 is less widely supported: NSS has an 642 implementation and I am aware of several in progress implementations. 643 Presumably, stacks will need to update to DTLS 1.3 in order to 644 support WebRTC as well. Having done the DTLS implementations for NSS 645 and Minq, I can report that it's not a huge amount of work once you 646 have TLS 1.3 support. 648 One important note here is that unlike the current design, which is 649 very tightly coupled to TLS 1.3, the design proposed here does not 650 depend on DTLS version. Thus, it is possible to have interop with 651 two stacks as long as they support a common version, including DTLS 652 1.2, though of course 0-RTT will not be available unless you have TLS 653 1.3 655 6.3. Epoch and ACKs 657 DTLS record sequence numbers consist of a 16-bit epoch and 48-bit 658 sequence number pair, with sequence numbers restarting at zero after 659 each epoch change. This would put some stress on the ACK format, but 660 it's easily addressed by having a separate set of ACK blocks for each 661 epoch. 663 6.4. Crypto Layer Agility 665 One concern I've heard raised is how this affects the ability to swap 666 out the crypto layer. There are pluses and minuses here. The 667 architecture described here is a better fit for swapping in a 668 conventional channel security protocol (e.g., IPsec, etc.) because 669 the layering is very conventional. It is also probably better for 670 swapping in a protocol which has totally out of band key management 671 where you just carry a session identifier in the packets. 673 It is is less good for swapping in a simple crypto core (e.g., 674 OPTLS), because those cores don't have their own framing, reliability 675 layers. It's not that onerous to invent one, but you do have to do 676 that. On the other hand, those protocols often also don't have other 677 protocol engineering pieces (e.g., cipher suite and curve 678 negotiation, so they are hard to extend). Another possibility in 679 that case is to move the crypto core into DTLS. For instance we have 680 been looking at adding an OPTLS-style semi-static mode to D/TLS. 681 This has the advantages that you don't need to reinvent the protocol 682 engineering pieces of TLS while giving you crypto core flexibility. 683 See [I-D.putman-tls13-preshared-dh] for an example here. 685 7. WebRTC Binding 687 There has been some initial discussion about doing WebRTC with QUIC. 688 This actually slots in quite naturally with a DTLS design. There are 689 two primary structures for WebRTC with QUIC: 691 o Replace SCTP with QUIC but continue to carry media over RTP 693 o Replace everything with QUIC 695 The former is a trivial change: you just do a DTLS handshake but 696 signal (in ALPN or the SDP) that you are doing QUIC instead of SCTP, 697 and carry QUIC over DTLS as expected, using the same DTLS Exporter to 698 generate the SRTP keys. 700 In the second case, you just carry QUIC over DTLS, with whatever 701 media over QUIC binding we invent, and then don't do a DTLS exporter. 703 8. Implementation Status 705 I have implemented the core of this proposal in Minq based on the in- 706 progress implementation of DTLS 1.3 for Mint. Handshakes succeed and 707 I can exchange data. I have not yet implemented 0-RTT or resumption 708 (though Mint supports both) and I expect them to be straightforward. 709 The one thing that seems like it might be slightly is exposing the 710 DTLS packet numbers to Minq, but that seems like it's just plumbing. 711 The whole effort took me less than 12 hours and resulted in a net 712 shrinkage of Minq by about 10% (700 lines of code) just from code 713 which was obviously unneeded and in the way, without any attempt to 714 do a real scrub. 716 9. Security Considerations 718 No doubt plenty. 720 10. References 722 10.1. Normative References 724 [I-D.ietf-quic-tls] 725 Thomson, M. and S. Turner, "Using Transport Layer Security 726 (TLS) to Secure QUIC", draft-ietf-quic-tls-10 (work in 727 progress), March 2018. 729 [I-D.ietf-quic-transport] 730 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 731 and Secure Transport", draft-ietf-quic-transport-10 (work 732 in progress), March 2018. 734 [I-D.ietf-tls-dtls-connection-id] 735 Rescorla, E., Tschofenig, H., Fossati, T., and T. Gondrom, 736 "The Datagram Transport Layer Security (DTLS) Connection 737 Identifier", draft-ietf-tls-dtls-connection-id-00 (work in 738 progress), December 2017. 740 [I-D.ietf-tls-dtls13] 741 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 742 Datagram Transport Layer Security (DTLS) Protocol Version 743 1.3", draft-ietf-tls-dtls13-26 (work in progress), March 744 2018. 746 [I-D.ietf-tls-tls13] 747 Rescorla, E., "The Transport Layer Security (TLS) Protocol 748 Version 1.3", draft-ietf-tls-tls13-26 (work in progress), 749 March 2018. 751 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 752 Requirement Levels", BCP 14, RFC 2119, 753 DOI 10.17487/RFC2119, March 1997, . 756 10.2. Informative References 758 [I-D.putman-tls13-preshared-dh] 759 Putman, T., "Authenticated Key Agreement using Pre-Shared 760 Asymmetric Keypairs for (Datagram) Transport Layer 761 Security ((D)TLS) Protocol version 1.3", draft-putman- 762 tls13-preshared-dh-00 (work in progress), January 2018. 764 Author's Address 766 Eric Rescorla 767 RTFM, Inc. 769 Email: ekr@rtfm.com