Re: Proposal: Run QUIC over DTLS

[Eric Rescorla <[e-mail]>]

Hi folks,

Thanks to everyone who commented. Trying to consolidate my responses
a bit, it seems like things fit into three major buckets:

- Whether we have a stream 0 problem
- Whether a layered architecture is the right thing/solves those
  problems
- Schedule impact

I'd like to focus on the architectural question for the moment. I
think there's broad -- though not universal -- agreement that the
stream 0 thing is not great, but a fair amount of debate about
what the right architecture and architectural principles are.
It's not really productive to talk about schedule impact until
we understand what the right thing is.

In this note (the first of what I expect to be many) I want to focus
on the question of reliability for the cryptographic handshake, namely
that the DTLS handshake provides its own reliability layer which to
some extent duplicates the QUIC one.  I say to some extent because
because it's rather simpler and doesn't provide congestion control,
etc.  A number of people raised concerns about this, for example Ian
Swett:

   From an architectural perspective, I would like transport at the
   bottom of the stack and I only want to run one transport.  Having
   two different transports creates more problems than it solves. TLS
   over TCP is massively successful, and the current TLS mapping is
   the most analogous approach I can come up with.

I'm not sure I agree entirely with this characterization, because it
kind of overloads the word "transport" [0] but I do think this is the
biggest technical weakness in the DTLS proposal (or any proposal which
is layered like this): if you're going to create the cryptographic
association before you want to send transport-level traffic, then you
need to provide transport services at the crypto level.

However, I think this is also the cause of a lot of our problems
with stream 0, namely that we're trying to use transport services at
the same time as we're trying to establish the connection: note that
this isn't the situation with TLS over TCP, because you set up the
entire TCP connection before the first packet is sent (or at least,
with TFO, TCP pretends that that's the case to TLS).  So, you have a
very clean abstraction in which layer N+1 is able to assume that layer
N is ready and count on its services, but that's not the case in QUIC.

In the current QUIC design, we've attempted to address this by making
stream 0 a special snowflake that uses the QUIC transport services but
gets to relax a bunch of the rules (flow control, always encrypted,
arbitrary mapping of writes to frames, etc.) The DTLS design deals
with this by having the handshake be entirely out of band to QUIC,
which of course means it needs to duplicate those services.


I'd like to drill down a bit more on people's concerns are here.
It seems like there are three potential objections:

- It's duplicate code
- The DTLS reliability/handshake machinery is going to be less
  good than the QUIC machinery
- It's going to create new forms of architectural inconvenience

The first point is of course true, though having done the code here,
I don't think it's that big a deal, and of course TLS 1.3 stacks will
in many cases be growing DTLS 1.3 stacks anyway.

The second point is possibly true as a general question, but I'm not
sure it actually matters, given that in the vast majority of cases you
won't have any loss in the DTLS handshake at all. Arguably, however,
the fact that the DTLS machinery only needs to be used in the
handshake is actually an advantage here: the amount of data we want to
send is very small and so we can lean more on the side of trading
bandwidth for fast setup. For instance, AIUI QUIC early retransmit fires
after about 1.25 SRTT, but in DTLS 1.3, you retransmit immediately
upon receiving an ACK for a partial flight. This is probably too
aggressive for a general transport, but it's not unreasonable when
you're likely to have no more then 3ish packets in flight anyway.
Again, I doubt this matters most of the time, but as an architectural
matter, it's not clear this is a disadvantage.

I'm more fuzzy on the third point. The only pieces of architectural
inconvenience I am aware of are listed in the draft, namely:

- Needing access to the DTLS record numbers to make the ACKs
  work.
- The fact that QUIC doesn't get any RTT information from the
  handshake, although as noted we can compensate that by having
  DTLS provide an estimate.

Are there other infelicities I'm missing here?

Thanks,
-Ekr

[0] Arguably, we already have two transports, QUIC and UDP, but nobody
is bothered by that. My argument here would be that from the
perspective of QUIC, DTLS is a lot more like UDP than it is like a
real transport. It's true that there is the handshake machinery, but
as I said above, that's out of band to QUIC and from QUIC's
perspective, you can either send packets, in which case DTLS sends
them out directly (with a predictable overhead) you cannot, in which
case QUIC needs to hold them (note that it's already true that QUIC
has to do this if the TLS negotiation is unfinished). So, I don't
think the more general argument is very persuasive here.



On Mon, Mar 5, 2018 at 3:05 PM, Eric Rescorla <[e-mail]> wrote:

> Hi folks,
>
> Sorry to be the one randomizing things again, but the asymmetric
> conn-id thing went well, so here goes....
>
> TL;DR.
> I'd like to discuss refactoring things to run QUIC over DTLS.
>
> DETAILS
> When we originally designed the interaction between TLS and QUIC,
> there seemed like a lot of advantages to embedding the crypto
> handshake on stream 0, in particular the ability to share a common
> reliability and congestion mechanism. However, as we've gotten further
> along in design and implementation, it's also become clear that it's
> archictecturally kind of crufty and this creates a bunch of problems,
> including:
>
>   * Stream 0 is unencrypted at the beginning of the connection, but
>     encrypted after the handshake completes, and you still need
>     to service it.
>
>   * Retransmission of stream 0 frames from lost packets needs special
>     handling to avoid accidentally encrypting them.
>
>   * Stream 0 is not subject to flow control; it can exceed limits and
>     goes into negative credit after the handshake completes.
>
>   * There are complicated rules about which packets can ACK other
>     packets, as both cleartext and ciphertext ACKs are possible.
>
>   * Very tight coupling between the crypto stack and the transport
>     stack, especially in terms of knowing where you are in the
>     crypto state machine.
>
> I've been looking at an alternative design in which we instead adopt a
> more natural layering of putting QUIC on top of DTLS. The basic
> intuition is that you do a DTLS handshake and just put QUIC frames
> directly in DTLS records (rather than QUIC packets). This
> significantly reduces the degree of entanglement between the two
> components and removes the corner cases above, as well as just
> generally being a more conventional architecture. Of course, no design
> is perfect, but on balance, I think this is a cleaner structure.
>
> I have a draft for this at:
> https://datatracker.ietf.org/doc/draft-rescorla-quic-over-dtls/
>
> And a partial implementation of it in Minq at:
>
> Mint: https://github.com/ekr/mint/tree/dtls_for_quic
> Minq: https://github.com/ekr/minq/tree/quic_over_dtls
>
>
> I can't speak for anyone else's implementation, but at least in my
> case, the result was considerable simplification.
>
> It's natural at this point to say that this is coming late in the
> process after we have a lot invested in the current design, as well as
> to worry that it will delay the process. That's not my intention, and
> as I say in the draft, many of the issues we have struggled over
> (headers especially) can be directly ported into this architecture (or
> perhaps just reused with QUIC-over-DTLS while letting ordinary DTLS do
> its thing) and this change would allow us to sidestep issued we are
> still fighting with, so on balance I believe we can keep the schedule
> impact contained.
>
> We are designing a protocol that will be used long into the future, so
> having the right architecture is especially important. Our goal has
> always been to guide this effort by implementation experience and we
> are learning about the deficiencies of the Stream 0 design as we go
> down our current path. If the primary concern to this proposal is
> schedule we should have an explicit discussion about those relative
> priorities in the context of the pros and cons of the proposal.
>
> The hackathon would be a good opportunity to have a face to face chat
> about this in addition to on-list discussion.
>
> Thanks in advance for taking a look,
> -Ekr
>
>
>
>
>
>
>
>
>
>
>