Re: Proposal: Run QUIC over DTLS

["Philipp S. Tiesel" <[e-mail]>]

Hi,

> On 14. Mar 2018, at 07:31, Brian Trammell (IETF) <[e-mail]> wrote:
> 
> 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.

Looks like there is a third, easier to implement, option lurking:

Throw away S0 QUIC and replace it with a long header packet type to carry DTLS records.

  +--------------------+
1 |       QUIC         |
  +------------+-------+
2 |  DTLS 1.3  |  PP   |
  | (handshake)| (data)|
  +- - - - - - +       |
3 | semitrans  |       |
  +------------+       |
  |  DTLS rl   |       |
  +------------+       |
  |  QUIC framing      |
  +--------------------+
  |         UDP        |
  +--------------------+


The only disadvantage I see with this approach is that it does not hide re-keying from being spotted on the wire.


AVE!
  Philipp S. Tiesel / phils…