Internet DRAFT - draft-rescorla-quic-over-dtls
draft-rescorla-quic-over-dtls
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, <https://www.rfc-
editor.org/info/rfc2119>.
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]