MIME-Version: 1.0
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 5 Mar 2018 15:05:50 -0800
Message-ID: <CABcZeBO9g5vnPK2aGYEUOYOkT-898Gc0-d4T=kDvxuE2Yg6kMQ@mail.gmail.com>
Subject: Proposal: Run QUIC over DTLS
To: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c114ed05f53b80566b2601c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/I4lMWsVNpBvldNDVgPQDE4pS6tY>
Precedence: list

--94eb2c114ed05f53b80566b2601c
Content-Type: text/plain; charset="UTF-8"

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

--94eb2c114ed05f53b80566b2601c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi folks,</div><div><br></div><div>Sorry to be the on=
e randomizing things again, but the asymmetric</div><div>conn-id thing went=
 well, so here goes....</div><div><br></div><div>TL;DR.</div><div>I&#39;d l=
ike to discuss refactoring things to run QUIC over DTLS.</div><div><br></di=
v><div>DETAILS</div><div>When we originally designed the interaction betwee=
n TLS and QUIC,</div><div>there seemed like a lot of advantages to embeddin=
g the crypto</div><div>handshake on stream 0, in particular the ability to =
share a common</div><div>reliability and congestion mechanism. However, as =
we&#39;ve gotten further</div><div>along in design and implementation, it&#=
39;s also become clear that it&#39;s</div><div>archictecturally kind of cru=
fty and this creates a bunch of problems,</div><div>including:</div><div><b=
r></div><div>=C2=A0 * Stream 0 is unencrypted at the beginning of the conne=
ction, but</div><div>=C2=A0 =C2=A0 encrypted after the handshake completes,=
 and you still need</div><div>=C2=A0 =C2=A0 to service it.=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0</div><div><br></div><div>=C2=A0 * Ret=
ransmission of stream 0 frames from lost packets needs special</div><div>=
=C2=A0 =C2=A0 handling to avoid accidentally encrypting them.</div><div><br=
></div><div>=C2=A0 * Stream 0 is not subject to flow control; it can exceed=
 limits and</div><div>=C2=A0 =C2=A0 goes into negative credit after the han=
dshake completes.</div><div><br></div><div>=C2=A0 * There are complicated r=
ules about which packets can ACK other</div><div>=C2=A0 =C2=A0 packets, as =
both cleartext and ciphertext ACKs are possible.</div><div><br></div><div>=
=C2=A0 * Very tight coupling between the crypto stack and the transport</di=
v><div>=C2=A0 =C2=A0 stack, especially in terms of knowing where you are in=
 the</div><div>=C2=A0 =C2=A0 crypto state machine.</div><div><br></div><div=
>I&#39;ve been looking at an alternative design in which we instead adopt a=
</div><div>more natural layering of putting QUIC on top of DTLS. The basic<=
/div><div>intuition is that you do a DTLS handshake and just put QUIC frame=
s</div><div>directly in DTLS records (rather than QUIC packets). This</div>=
<div>significantly reduces the degree of entanglement between the two</div>=
<div>components and removes the corner cases above, as well as just</div><d=
iv>generally being a more conventional architecture. Of course, no design</=
div><div>is perfect, but on balance, I think this is a cleaner structure.</=
div><div><br></div><div>I have a draft for this at:</div><div><a href=3D"ht=
tps://datatracker.ietf.org/doc/draft-rescorla-quic-over-dtls/">https://data=
tracker.ietf.org/doc/draft-rescorla-quic-over-dtls/</a></div><div><br></div=
><div>And a partial implementation of it in Minq at:</div><div><br></div><d=
iv>Mint: <a href=3D"https://github.com/ekr/mint/tree/dtls_for_quic">https:/=
/github.com/ekr/mint/tree/dtls_for_quic</a></div><div>Minq: <a href=3D"http=
s://github.com/ekr/minq/tree/quic_over_dtls">https://github.com/ekr/minq/tr=
ee/quic_over_dtls</a></div><div><br></div><div><br></div><div>I can&#39;t s=
peak for anyone else&#39;s implementation, but at least in my</div><div>cas=
e, the result was considerable simplification.</div><div><br></div><div>It&=
#39;s natural at this point to say that this is coming late in the</div><di=
v>process after we have a lot invested in the current design, as well as</d=
iv><div>to worry that it will delay the process. That&#39;s not my intentio=
n, and</div><div>as I say in the draft, many of the issues we have struggle=
d over</div><div>(headers especially) can be directly ported into this arch=
itecture (or</div><div>perhaps just reused with QUIC-over-DTLS while lettin=
g ordinary DTLS do</div><div>its thing) and this change would allow us to s=
idestep issued we are</div><div>still fighting with, so on balance I believ=
e we can keep the schedule</div><div>impact contained.</div><div><br></div>=
<div>We are designing a protocol that will be used long into the future, so=
</div><div>having the right architecture is especially important. Our goal =
has</div><div>always been to guide this effort by implementation experience=
 and we</div><div>are learning about the deficiencies of the Stream 0 desig=
n as we go</div><div>down our current path. If the primary concern to this =
proposal is</div><div>schedule we should have an explicit discussion about =
those relative</div><div>priorities in the context of the pros and cons of =
the proposal.</div><div><br></div><div>The hackathon would be a good opport=
unity to have a face to face chat</div><div>about this in addition to on-li=
st discussion.</div><div><br></div><div>Thanks in advance for taking a look=
,</div><div>-Ekr</div><div><br></div><div><br></div><div><br></div><div><br=
></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br=
></div><div><br></div></div>

--94eb2c114ed05f53b80566b2601c--