QUIC Working Group E. Rescorla Internet-Draft RTFM, Inc. Intended status: Informational March 05, 2018 Expires: September 6, 2018 QUIC over DTLS draft-rescorla-quic-over-dtls-00 Abstract QUIC in-band cryptographic negotiation on stream 0 creates a number of odd edge cases. This document considers an alternative design in which QUIC transport is run directly over DTLS, thus separating the cryptographic negotiation from the transport piece. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 6, 2018. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Rescorla Expires September 6, 2018 [Page 1] Internet-Draft QUIC/DTLS March 2018 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Reliability . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.1. DTLS Reliability and ACKs . . . . . . . . . . . . . . 6 2.1.2. RTT Estimation . . . . . . . . . . . . . . . . . . . 6 2.1.3. QUIC Reliability and ACKs . . . . . . . . . . . . . . 6 2.2. Version Negotiation . . . . . . . . . . . . . . . . . . . 7 2.3. Transport Parameters . . . . . . . . . . . . . . . . . . 8 2.4. Key Changes and New Session Ticket . . . . . . . . . . . 8 2.5. Connection IDs . . . . . . . . . . . . . . . . . . . . . 9 3. Required Changes to DTLS . . . . . . . . . . . . . . . . . . 9 3.1. Handshake Obfuscation . . . . . . . . . . . . . . . . . . 9 3.2. Obfuscation Negotiation Packet . . . . . . . . . . . . . 11 3.3. Packet Header Encryption . . . . . . . . . . . . . . . . 11 3.4. Stateless Reset . . . . . . . . . . . . . . . . . . . . . 11 4. Required Changes to QUIC Documents . . . . . . . . . . . . . 12 4.1. TLS Document . . . . . . . . . . . . . . . . . . . . . . 12 4.2. Transport Document . . . . . . . . . . . . . . . . . . . 12 4.3. Recovery Document . . . . . . . . . . . . . . . . . . . . 13 4.4. Invariants Document . . . . . . . . . . . . . . . . . . . 13 5. Potential Additional Benefits . . . . . . . . . . . . . . . . 13 5.1. Record Coalescence . . . . . . . . . . . . . . . . . . . 13 5.2. More Straightforward Demuxing . . . . . . . . . . . . . . 13 6. Potential Points of Concern . . . . . . . . . . . . . . . . . 13 6.1. Record Size/Overhead . . . . . . . . . . . . . . . . . . 14 6.2. Status of DTLS 1.3 Maturity . . . . . . . . . . . . . . . 14 6.3. Epoch and ACKs . . . . . . . . . . . . . . . . . . . . . 15 6.4. Crypto Layer Agility . . . . . . . . . . . . . . . . . . 15 7. WebRTC Binding . . . . . . . . . . . . . . . . . . . . . . . 15 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction QUIC [I-D.ietf-quic-transport] [I-D.ietf-quic-tls] as currently designed performs cryptographic negotiation by sending TLS 1.3 [I-D.ietf-tls-tls13] traffic directly in stream 0. This design was the result of desiring to have tight coupling between the cryptographic handshake and the transport and has a number of advantages in that it allows the TLS 1.3 flow to take advantage of QUIC's transport services, in particular reliable in-order delivery, Rescorla Expires September 6, 2018 [Page 2] Internet-Draft QUIC/DTLS March 2018 RTT estimation, etc. However, it also results in several unpleasant corner cases: o The cryptographic handshake stream is subject to a variety of odd rules, such as: * Stream 0 is unencrypted at the beginning of the connection, but encrypted after the handshake completes. * Stream 0 is not subject to flow control; it can exceed limits and goes into negative credit after the handshake completes. * Retransmission of stream 0 frames from lost packets needs special handling to avoid accidentally encrypting them. * Stream 0 offsets are reset after the server sends a Retry packet. This creates special handling rules for the stream. o The QUIC stack needs tight coupling with the TLS stack to know, for instance, whether the TLS stack sent SH or HRR, or where the boundaries are between flights. See, Issue #1094 for an example of this kind of problem. o There are complicated rules about which packets can ACK other packets, as both cleartext and ciphertext ACKs are possible. o The interaction of the state machine advancing (which makes clear that packets have received) and ACKs is confusing. For instance, it is possible to respond to an Initial packet but not ACK it. The semantics of this are unclear. o There are complicated rules for how to handle 0-RTT (and especially 0-RTT failures). o The stack needs to continue to service stream 0 indefinitely in order to gather NewSessionTicket messages. o QUIC version negotiation isn't authenticated, so it is retroactively authenticated during the TLS handshake. This document considers a design at the other end of the spectrum, which is to layer QUIC transport over DTLS 1.3 [I-D.ietf-tls-dtls13] (with some small pieces of coupling). This design addresses most of the corner cases described above, although it does introduce some new issues which must be considered. Rescorla Expires September 6, 2018 [Page 3] Internet-Draft QUIC/DTLS March 2018 2. Design Overview The current QUIC/TLS integration treats TLS as a module which gets a lot of its services from QUIC. I.e., something like this: +-------+-------+ | TLS | App | | | Data | +-----------------+-------+-------+ | Other Frames | Streams | +-----------------+---------------+ | Envelope | +---------------------------------+ | UDP | +---------------------------------+ Figure 1: Current QUIC Architecture This creates a relatively complicated interaction, as shown in the following diagram from [I-D.ietf-quic-tls]. +------------+ +------------+ | |------ Handshake ------>| | | |<-- Validate Address ---| | | |-- OK/Error/Validate -->| | | |<----- Handshake -------| | | QUIC |------ Validate ------->| TLS | | | | | | |<------ 0-RTT OK -------| | | |<------ 1-RTT OK -------| | | |<--- Handshake Done ----| | +------------+ +------------+ | ^ ^ | | Protect | Protected | | v | Packet | | +------------+ / / | QUIC | / / | Packet |-------- Get Secret -------' / | Protection |<-------- Secret -----------' +------------+ Figure 2: QUIC/TLS Interactions In the design proposed by this document, we have a more natural layered structure, similar to that of HTTP2 over TLS. I.e., Rescorla Expires September 6, 2018 [Page 4] Internet-Draft QUIC/DTLS March 2018 +-------------------------+ | QUIC | +-------------------------+ | DTLS | +-------------------------+ | UDP | +-------------------------+ | IP | +-------------------------+ Figure 3: QUIC over DTLS architecture Of course, you still need some signaling between QUIC and DTLS, but it's largely the conventional signaling that any application protocol over TLS needs. Specifically: o It's possible to send data (in 0-RTT or 1-RTT) o The handshake is complete o Here are the cryptographic parameters o The record number that corresponds to a given piece of data. The only real special accommodation needed is to carry the QUIC transport parameters, which you already needed in the current design (although it's not shown). You may also want to expose DTLS's RTT estimates to QUIC (see Section 2.1.2) but this is not necessary to have a functional system. Operationally, this is straightforward. You negotiate DTLS and then send QUIC frames over DTLS as type application data, as shown in Figure 4. Client Server CH --------------------------------------------------> <------------------------------------------ SH ... FIN <-------------------------------------- [ QUIC frames] FIN -------------------------------------------------> <------------------ [QUIC frames] -------------------> Figure 4: Simple QUIC over DTLS The payload of each application data DTLS record consist of QUIC frames laid end to end, precisely as in current QUIC packets. Because DTLS application data is always encrypted, this means that the QUIC frames themselves are also encrypted. Rescorla Expires September 6, 2018 [Page 5] Internet-Draft QUIC/DTLS March 2018 When 0-RTT is used, things are as you expect, namely that QUIC frames can be sent in the early data, as shown in Figure 5. If 0-RTT is rejected, then the frames can just be treated as lost and retransmitted, though you probably want to do so immediately and some care must not be taken to let this modify your congestion state. Client Server CH --------------------------------------------------> [QUIC frames] ---------------------------------------> <------------------------------------------ SH ... FIN <-------------------------------------- [ QUIC frames] FIN -------------------------------------------------> <------------------ [QUIC frames] -------------------> Figure 5: QUIC over DTLS with 0-RTT 2.1. Reliability 2.1.1. DTLS Reliability and ACKs In this design, DTLS takes care of its own reliability for the handshake (and for post-handshake messages) via a timeout and retransmission scheme, including ACKs. DTLS ACKs apply only to handshake records and so simply don't apply to QUIC frames at all. DTLS ACKs apply to both encrypted and unencrypted handshake records. 2.1.2. RTT Estimation One virtue of the current deisgn is that you get an RTT estimate from the QUIC congestion control machinery for packets that are sent during the handshake phase. Naively you would lose this, but DTLS actually gives you a primitive estimate of this via its own reliability mechanisms and ACKs. So the natural thing to do here is to have the DTLS implementation derive an RTT estimate from the DTLS handshake from the first round trip in each direction and then provide it to the QUIC part of the stack as an initial estimate. 2.1.3. QUIC Reliability and ACKs By contrast, QUIC ACKs only apply to application data records (which contain encrypted QUIC frames) and are just sent with whatever the current DTLS epoch is. One subtlety here is what the QUIC ACKs acknowledge, because we no longer have QUIC packets. One way of handling this would be to have packet numbers as a header inside each application data record, i.e.,: Rescorla Expires September 6, 2018 [Page 6] Internet-Draft QUIC/DTLS March 2018 [Packet Number] [Frame] [Frame]... [Frame] However, this wastes space, so a better approach is to just refer to the DTLS record number. This is the primary piece of layer violation in this design in that the QUIC stack will need to be aware of: o Which DTLS record number a given frame went out on o Which DTLS record number a given frame came in on This is a tiny bit ugly, but isn't complicated to implement. 2.2. Version Negotiation In current QUIC, you negotiate two versions: o The QUIC version by having the client propose a version and then the server corrects it. o The TLS version which is negotiated by having the client propose all its versions and then the server selects one. When we reorder QUIC and DTLS, a different design is appropriate. DTLS currently doesn't encrypt the ClientHello, so obfuscation does not immediately become an issue, and instead we can have both QUIC and DTLS versions negotiated in the customary way, namely: the client proposes two sets of versions: o DTLS versions in "supported_versions" o QUIC versions in "quic_versions" (new) And then the server chooses its preference for both of them. Assuming that we want to continue to have handshake obfuscation, we will need to modify DTLS to allow this (more details about this in Section 3.1), and then we can adopt the current scheme with a small set of modifications. o The records containing the ClientHello and ServerHello contain a DTLS version. This reflects the version of DTLS whose obfuscation constants are in use. o If the server recognizes that version, then it simply decrypts the handshake messages and does DTLS version negotiation mechanism (see Figure 6). Rescorla Expires September 6, 2018 [Page 7] Internet-Draft QUIC/DTLS March 2018 o If the server doesn't recognize that version, it sends a VN packet as with current QUIC (we would need to add this to DTLS). The client then re-sends the ClientHello except obfuscated with a different version. Note that you use the same ClientHello.supported_versions and so an attacker cannot impact DTLS version negotiation (see Figure 7). Client Server CH version = A[supported_versions = A, B, C] ---------> <--------------- SH version = B [supported_version = B] Figure 6: Version negotiation with compatible obfuscation Client Server CH version = A[supported_versions = A, B, C] ---------> <--------------------------------- VN versions = [B, C] CH version = B[supported_versions = A, B, C] ---------> <--------------- SH version = B [supported_version = B] Figure 7: Version negotiation with incompatible obfuscation Note that this design is 1-RTT faster than the current design in cases where the server has changed it's preferred version. In current QUIC, that results in a VN, but here the server can just remember the old constants, decrypt the record, and proceed with negotiation as usual. 2.3. Transport Parameters The QUIC transport parameters can be negotiated in DTLS extensions as they currently are. 2.4. Key Changes and New Session Ticket Because the QUIC frames are carried over DTLS, the DTLS stack naturally reads and writes DTLS records that are not carrying application data (primarily handshake) as well. This means that post-handshake messages such as KeyUpdate and NewSessionTicket just work naturally: the peer sends them and the DTLS stack consumes them, transparently to the QUIC stack. Note that this is an improvement over the current design, in which the QUIC stack needs to continue to pass data back and forth to the TLS stack on stream 0. Key changes just take effect according to the DTLS schedule. Rescorla Expires September 6, 2018 [Page 8] Internet-Draft QUIC/DTLS March 2018 2.5. Connection IDs DTLS 1.3 has no native support for connection IDs, but instead has farmed it out to a separate draft [I-D.ietf-tls-dtls-connection-id]. That draft takes a slightly different strategy from QUIC in which both sides provide the connection ID for the peer to use to send to them. However, we are currently considering precisely such a design in QUIC (see https://github.com/quicwg/base-drafts/issues/1089) in which case, much of the design would drop into place. The remainder of this document assumes that we are using asymmetric connection IDs, as that seems like the direction we are going, but this part of DTLS is still under active design and so could presumably be modified to support QUIC's needs. 3. Required Changes to DTLS Some modest changes would be needed for DTLS to ensure parity with the current QUIC design. These changes would reuse design work we have already done for QUIC. In addition to the existing DTLS 1.3 capabilities and the connection ID work, the following changes are needed: o Handshake Obfuscation, Section 3.1 o Obfuscation Negotiation, Section 3.2 o Packet Number Encryption, Section 3.3 o Stateless Reset, Section 3.4 These would each add a generic capability to DTLS that could be used by other protocols. 3.1. Handshake Obfuscation As noted above, DTLS does not presently encrypt the ClientHello and ServerHello messages (the remainder of the messages are in the clear). However, there's an elegant way to handle this, as suggested by Martin Thomson, which is to define the format of DTLSPlaintext as being version specific. Recall the standard DTLSPlaintext: Rescorla Expires September 6, 2018 [Page 9] Internet-Draft QUIC/DTLS March 2018 struct { ContentType type; ProtocolVersion version; uint16 epoch = 0 // DTLS field uint48 sequence_number; // DTLS field uint16 length; opaque fragment[DTLSPlaintext.length]; } DTLSPlaintext; We can simply declare that when DTLSPlaintext.version is set to 1.3 or above, we instead have: struct { ContentType opaque_type = handshake; // Real CT inside the encryption ProtocolVersion version; opaque dst_conn_id<0..255> opaque src_conn_id<0..255>; uint16 epoch = 0 // DTLS field uint48 sequence_number; // DTLS field uint16 length; opaque encrypted_record[length]; } DTLSHandshakeCiphertext; This format would be used only for the initial handshake and any alerts or acks it generates (i.e., data in epochs 0, 1, and 2). For epoch 0 (what would be plaintext in TLS 1.3), the obfuscation is done essentially as with QUIC, i.e., with a KDF keyed with a per- connection function and the dst CID. For all other epochs, you encrypt just as you would with DTLS 1.3 today. Note the difference here from TLS 1.3 in which these packets get type=handshake, which with the record version tells us that the CID variant is in use. Note that this is essentially the same structure here as I recently proposed for asymmetric CIDs. An advantage of this design is that it has a natural "backward compatible mode" for DTLS where you can use the old format if you don't know what the peer supports (conventional D/TLS behavior) but if you have a minimum version that's 1.3 or above you can get obfuscation. [[OPEN ISSUE: Grease the length bytes.]] Rescorla Expires September 6, 2018 [Page 10] Internet-Draft QUIC/DTLS March 2018 3.2. Obfuscation Negotiation Packet In the case that the client chooses an obfuscation scheme that the server does not understand, we need a way for the server to request a different obfuscation scheme. This is analogous to the QUIC Version Negotiation packet, but it only negotiates the choice of obfuscation. Because it is separate from the negotiation of the QUIC version, it can be much lighter weight. We can more or less directly steal the QUIC Version Negotiation scheme. That is, the server sends a list of supported versions in place of the packet payload: struct { ContentType opaque_type = handshake; // Real CT inside the encryption ProtocolVersion version = 0; opaque dst_conn_id<0..255> opaque src_conn_id<0..255>; uint16 epoch = 0 // DTLS field uint48 sequence_number; // DTLS field uint16 length; uint16 supported_versions<2..254>; } DTLSObfuscationNegotiation; Unlike the current design, where authenticating version negotiation is critical, a downgrade attack only causes the ClientHello and ServerHello to be protected with a different obfuscation scheme. Because obfuscation does not affect the integrity of the protocol negotiation there is no need to add separate authentication for this exchange. 3.3. Packet Header Encryption DTLS does not encrypt its packet number and also does not presently have sequence number gaps, which makes changing connection IDs for privacy of modest value. There's no reason we couldn't adapt the same techniques we have discussed using for QUIC, when we get those nailed down. Pretty much all the same issues apply to DTLS and QUIC here. 3.4. Stateless Reset As noted above, we would need to define stateless reset. The best way to do this is to define a new extension in Encrypted Extensions for this, so that it's usable for non-QUIC purposes. Otherwise the mechanics can be identical to the current QUIC design in Section 7.9.4 of [I-D.ietf-quic-transport]. Rescorla Expires September 6, 2018 [Page 11] Internet-Draft QUIC/DTLS March 2018 4. Required Changes to QUIC Documents Obviously, we would require changes to the existing QUIC drafts to make this work. Primarily it's a matter of removal. This section covers the known changes. 4.1. TLS Document This document is just removed entirely. We don't need it any more. This removes all or nearly all the crypto from QUIC, and in particular the somewhat complex key schedule, and leaves it in DTLS. 4.2. Transport Document Much of this document also goes away. Specifically: o We are folding the entire QUIC header into the DTLS header (and stealing a lot of stuff in the process) so basically all of Section 5 (Packet Types and Formats) away. o We carry frame types directly over DTLS, so Section 6 (Frames and Frame Types) stays, o Essentially all of Section 7 (Life of a Connection) disappears, and is replaced by the DTLS CID and new version negotiation scheme carried in DTLS extensions (see Section 2.2). The connection migration design works without modifications, so that would be retained. Similarly, once the DTLS connection is established, QUIC style connection close should be used, with the exception of stateless reset and (optionally) if the DTLS layer decideas to abort because of too many deprotection failures. The DTLS close_notify was intended as unreliable and is therefore less capable than QUIC's close. o As noted above, ACKs stay essentially the same, but we will need to change the encoding a bit to handle epoch changes, as described in Section 2.1.3 and Section 6.3. o Section 9 (Packetization and Reliability), 10 (Streams), and 11 (Flow Control) also stay the same. o We'll want to trim down the error space (Section 12) a little bit because we'll want to use DTLS alerts for a lot of errors. This makes things easier because it avoids the confusion we have now about whether to send a QUIC error or a TLS alert. Rescorla Expires September 6, 2018 [Page 12] Internet-Draft QUIC/DTLS March 2018 4.3. Recovery Document Almost no changes, except for the rules about handshake recovery. 4.4. Invariants Document We will need to modify the invariants to match the DTLS invariants, but the principles are the same and the header/packet formats are reasonably similar, so this should be straightforward. 5. Potential Additional Benefits 5.1. Record Coalescence One challenge in QUIC has been that it is not possible to place two QUIC packets in the same UDP datagram. This creates problems whenever you would like to have two packets encrypted under different keys sent together, as with the Initial packet and 0-RTT data, or with 1-RTT data (which is encrypted) and the Finished message (which is not). With DTLS, however, this is straightforward. DTLS has three record header formats: o DTLSPlaintext o DTLSCiphertext o DTLSShortCiphertext The first two of these have built-in length field and can therefore be packed more than one to a UDP datagram. This allows for simple piggybacking of records of different types. Obviously, this header engineering could be done for QUIC, but its not something we have done. 5.2. More Straightforward Demuxing We have had extended discussions about how to demux QUIC with other UDP protocols which might be on the same 5-tuple (principally for WebRTC). Because the existing cases already use DTLS, carrying QUIC over DTLS obviously makes this easier. 6. Potential Points of Concern Rescorla Expires September 6, 2018 [Page 13] Internet-Draft QUIC/DTLS March 2018 6.1. Record Size/Overhead One concern we might have is about record overhead. It's a bit hard to make a straight-up comparison between QUIC and DTLS 1.3 because they make different assumptions about the length of the sequence number field. As noted above, DTLS 1.3 as currently proposed has two different header formats. The longer of the two has a 7 byte header with a 30 bit sequence number and a length field. The shorter is only two bytes with a 12 bit sequence number and no length field. In addition, DTLS 1.3 has a one byte internal content type field that is used to distinguish application data from handshake data and to support padding. DTLS has similar record overheads to QUIC, but with a larger increase in size if a longer sequence number is needed. If that turns out to be a problem, there are alternative designs that could be contemplated. 6.2. Status of DTLS 1.3 Maturity DTLS 1.3 is a small delta off of TLS 1.3. In Singapore there were no remaining open issues, and a proposal to go to WGLC once we had more implementation experience, which we are accumulating now, so absent input from QUIC, I would expect DTLS to go to WGLC on London. Note that due to the lower level of inspection of DTLS and the preexisting need for hole-punching (e.g., WebRTC), the last minute middlebox interop issues that delayed TLS 1.3 should not be an issue for DTLS. However, conveniently this status allows us to get the small changes described in Section 3 in before we close the document. The TLS WG is very interested in coordinating with QUIC - and has many of the same key players - so it should be possible to close these quickly and proceed to DTLS 1.3 WGLC. In general, DTLS 1.2 is reasonably widely implemented, though not as widely implemented as TLS. All the major browser stacks already have it to support WebRTC. DTLS 1.3 is less widely supported: NSS has an implementation and I am aware of several in progress implementations. Presumably, stacks will need to update to DTLS 1.3 in order to support WebRTC as well. Having done the DTLS implementations for NSS and Minq, I can report that it's not a huge amount of work once you have TLS 1.3 support. One important note here is that unlike the current design, which is very tightly coupled to TLS 1.3, the design proposed here does not depend on DTLS version. Thus, it is possible to have interop with two stacks as long as they support a common version, including DTLS Rescorla Expires September 6, 2018 [Page 14] Internet-Draft QUIC/DTLS March 2018 1.2, though of course 0-RTT will not be available unless you have TLS 1.3 6.3. Epoch and ACKs DTLS record sequence numbers consist of a 16-bit epoch and 48-bit sequence number pair, with sequence numbers restarting at zero after each epoch change. This would put some stress on the ACK format, but it's easily addressed by having a separate set of ACK blocks for each epoch. 6.4. Crypto Layer Agility One concern I've heard raised is how this affects the ability to swap out the crypto layer. There are pluses and minuses here. The architecture described here is a better fit for swapping in a conventional channel security protocol (e.g., IPsec, etc.) because the layering is very conventional. It is also probably better for swapping in a protocol which has totally out of band key management where you just carry a session identifier in the packets. It is is less good for swapping in a simple crypto core (e.g., OPTLS), because those cores don't have their own framing, reliability layers. It's not that onerous to invent one, but you do have to do that. On the other hand, those protocols often also don't have other protocol engineering pieces (e.g., cipher suite and curve negotiation, so they are hard to extend). Another possibility in that case is to move the crypto core into DTLS. For instance we have been looking at adding an OPTLS-style semi-static mode to D/TLS. This has the advantages that you don't need to reinvent the protocol engineering pieces of TLS while giving you crypto core flexibility. See [I-D.putman-tls13-preshared-dh] for an example here. 7. WebRTC Binding There has been some initial discussion about doing WebRTC with QUIC. This actually slots in quite naturally with a DTLS design. There are two primary structures for WebRTC with QUIC: o Replace SCTP with QUIC but continue to carry media over RTP o Replace everything with QUIC The former is a trivial change: you just do a DTLS handshake but signal (in ALPN or the SDP) that you are doing QUIC instead of SCTP, and carry QUIC over DTLS as expected, using the same DTLS Exporter to generate the SRTP keys. Rescorla Expires September 6, 2018 [Page 15] Internet-Draft QUIC/DTLS March 2018 In the second case, you just carry QUIC over DTLS, with whatever media over QUIC binding we invent, and then don't do a DTLS exporter. 8. Implementation Status I have implemented the core of this proposal in Minq based on the in- progress implementation of DTLS 1.3 for Mint. Handshakes succeed and I can exchange data. I have not yet implemented 0-RTT or resumption (though Mint supports both) and I expect them to be straightforward. The one thing that seems like it might be slightly is exposing the DTLS packet numbers to Minq, but that seems like it's just plumbing. The whole effort took me less than 12 hours and resulted in a net shrinkage of Minq by about 10% (700 lines of code) just from code which was obviously unneeded and in the way, without any attempt to do a real scrub. 9. Security Considerations No doubt plenty. 10. References 10.1. Normative References [I-D.ietf-quic-tls] Thomson, M. and S. Turner, "Using Transport Layer Security (TLS) to Secure QUIC", draft-ietf-quic-tls-10 (work in progress), March 2018. [I-D.ietf-quic-transport] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", draft-ietf-quic-transport-10 (work in progress), March 2018. [I-D.ietf-tls-dtls-connection-id] Rescorla, E., Tschofenig, H., Fossati, T., and T. Gondrom, "The Datagram Transport Layer Security (DTLS) Connection Identifier", draft-ietf-tls-dtls-connection-id-00 (work in progress), December 2017. [I-D.ietf-tls-dtls13] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", draft-ietf-tls-dtls13-26 (work in progress), March 2018. Rescorla Expires September 6, 2018 [Page 16] Internet-Draft QUIC/DTLS March 2018 [I-D.ietf-tls-tls13] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", draft-ietf-tls-tls13-26 (work in progress), March 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 10.2. Informative References [I-D.putman-tls13-preshared-dh] Putman, T., "Authenticated Key Agreement using Pre-Shared Asymmetric Keypairs for (Datagram) Transport Layer Security ((D)TLS) Protocol version 1.3", draft-putman- tls13-preshared-dh-00 (work in progress), January 2018. Author's Address Eric Rescorla RTFM, Inc. Email: ekr@rtfm.com Rescorla Expires September 6, 2018 [Page 17]