Re: Proposal: Run QUIC over DTLS

[Brian Trammell (IETF) <[e-mail]>]

hi ekr,

Thanks for this reframing of the question. An attempt at an answer, inline:

> On 13 Mar 2018, at 17:52, Eric Rescorla <[e-mail]> wrote:
> 
> 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.

Yes, there clearly is a Stream Zero Problem, in that Stream Zero is currently the box into which we are pushing all the complexity related to establishing cryptographic context. To some extent, though, the "layered architecture or not" question is orthogonal to the "DTLS or not" question. The complexity exists, and it needs to go somewhere, if we are to support:

- establishing a cryptographic association over a datagram service
- in the presence of loss, reordering, duplication, and attackers on-path and off
- while minimizing mean association establishment latency, even in less than ideal network conditions
- and using said cryptographic association to protect transport internals
- supporting the selective exposure of additional information about the association for selected in-network functions (at the very least, CID).

In other words, we need three things:

(1) An encrypted transport protocol
(2) A method to establish the cryptographic association for (1)
(3) A transport protocol to provide the reliability guarantees needed by (2)

In QUIC today, (1) is QUIC, (2) is TLS, and (3) is a transport protocol that shares a lot of semantics with QUIC, and co-exists with QUIC's framing, but (and this, I think, is where the confusion comes from and where things go wrong) *isn't really QUIC*. I'll label this "S0-QUIC" (for "Stream Zero") below:

  +--------------------+
1 |       QUIC         |
  +--------------------+
2 |    TLS 1.3 + PP    |
  | (handshake)        |
  +------------+-------+
3 |  S0-QUIC   |       |
  +------------+       |
  |  QUIC wire image   |
  +--------------------+
  |        UDP         |
  +--------------------+

If you look at it this way, QUIC is already a strictly-layered architecture, we just aren't treating it at such because S0-QUIC and QUIC look enough alike that we think they are the same thing. I suspect that treating S0-QUIC and QUIC as distinct, with the caveat that they must share a wire image, while seeking to preserve opportunities for code reuse between them, might make cleaning up Stream Zero conceptually cleaner.

In the DTLS proposal, (1) is QUIC (without its wire image or S0-QUIC) (2) is DTLS, and (3) is the semitransport DTLS uses for its handshake:

  +--------------------+
1 |       QUIC         |
  +--------------------+
2 |     DTLS 1.3       |
  | (handshake)        |
  +- - - - - - +-------+
3 | semitrans  |       |
  +------------+       |
  |  DTLS record layer |
  +--------------------+
  |        UDP         |
  +--------------------+

In this framing of the question, the Stream Zero problem arises because QUIC's (3) is not as cleanly separated from QUIC as it should be, and most of the architectural win from moving to DTLS comes from the fact that the layer separation is already there.

> <snip>

> 
> Are there other infelicities I'm missing here?

By running QUIC over DTLS, we're essentially moving (or alternately, ceding) all the discussion about what the transport's wire image should look like to DTLS. From an architectural standpoint, this might actually be cleaner: there is something elegant about defining DTLS itself as the "path layer" proposed back in PLUS, a common wire image over which many future transports, of which QUIC is the first, can run.

But it's more work to do: everything we've done on QUIC's wire image would have to be replaced with equivalents for DTLS:

- For the connection ID, I note that draft-ietf-tls-dtls-connection-id-00 looks a lot like #1151, so that's nice.

- The low-order 30 bits of the sequence number are exposed in DTLS. If we come to consensus that this is a problem, we could possibly apply an encryption scheme as proposed in #1079 to this, but this would be a larger change to the record format than the connection ID.

- The spin bit (#1046) -- or bits, depending on where we think the overhead / bad-condition-resistence tradeoff falls out -- is transport-independent and could be ported to DTLS without changes to the mechanism, but it would need a place in the DTLS record format, and unlike the QUIC short header, there doesn't appear (on my cursory search) to be an almost-zero-cost place to take it from.

All three could be implemented as negotiated DTLS extensions; I'm not yet sure of my opinion about how good a thing that is.

Cheers,

Brian