Subject: Proposal: Run QUIC over DTLS

From: Eric Rescorla <[email-masked]>
Date: Mon, 5 Mar 2018 15:05:50 -0800

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

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 5 Mar 2018 23:58:03 +0000

Hi EKR,

This is a very interesting proposal, especially because I have little experience with DTLS. (I also have little experience with QUIC's use of TLS 1.3 so can't comment too strongly in that regard).

One aspect of the current QUIC design I like is the separation between key exchange and packet protection. Which allows some alternative use cases. So I read your draft and was not sure if DTLS maintains that possibility or not. Section 6.4 seems to touch on this topic but I wasn't sure if you are asserting the flexibility exists nor or could exist with some work. The link to draft-putman-tls13-preshared-dh "Authenticated Key Agreement using Pre-Shared Asymmetric Keypairs" is quite well aligned to to the use case I was thinking of. It would be nice to leverage such work rather than have to reinvent it for QUIC's current design.

Regards
Lucas
________________________________
From: QUIC [[email-masked]] on behalf of Eric Rescorla [[email-masked]]
Sent: 05 March 2018 23:05
To: IETF QUIC WG
Subject: Proposal: Run QUIC over DTLS

Hi folks,

TL;DR.

DETAILS

----------------------------

http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

---------------------

---

From: Ted Hardie <[email-masked]>
Date: Mon, 5 Mar 2018 16:10:39 -0800

Hi Eric,

I haven't read the proposal yet, but one very quick process point:

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

> It's quite late for folks to change their plans if they were not
previously going to the hackathon or had other hacking to do there, so I
believe that it is not appropriate to use this time.   (In addition to a
distraction from the actually coding folks might hope to get done).

Given that this is, after all, a proposed change to both charter and work
plan, so I think it belongs on the list.

regards,

Ted

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 6 Mar 2018 00:21:23 +0000

I agree that this I a change in charter and milestones and should therefore be discussion on-list.

Of course, anyone can meet with anyone on the side, but deliberately trying to take time away from the scheduled hackathon seems to be, well, in a bit of poor taste. ;)

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 5 Mar 2018 16:41:57 -0800

On Mon, Mar 5, 2018 at 3:58 PM, Lucas Pardue <[email-masked]> wrote:

> Hi EKR,
>
> This is a very interesting proposal, especially because I have little
> experience with DTLS. (I also have little experience with QUIC's use of TLS
> 1.3 so can't comment too strongly in that regard).
>
> One aspect of the current QUIC design I like is the separation between key
> exchange and packet protection. Which allows some alternative use cases. So
> I read your draft and was not sure if DTLS maintains that possibility or
> not. Section 6.4 seems to touch on this topic but I wasn't sure if you are
> asserting the flexibility exists nor or could exist with some work. The
> link to draft-putman-tls13-preshared-dh "Authenticated Key Agreement
> using Pre-Shared Asymmetric Keypairs" is quite well aligned to to the use
> case I was thinking of. It would be nice to leverage such work rather than
> have to reinvent it for QUIC's current design.
>

Hi Lucas,

DTLS and TLS have pretty similar designs in this respect (DTLS is primarily
a thin reliability layer on the TLS handshake), and in general TLS has key
exchange and packet protection separated, in much the same way things are
in the current QUIC design, just with a different packet encryption.

TLS is explicitly designed to allow for flexibility in the crypto core, so
I would imagine we're going to see a bunch of innovation there over the
next few years. The putman draft is one example of what people are looking
at, but I'm aware of others as well.

-Ekr

>
> Regards
> Lucas
> ------------------------------
> *From:* QUIC [[email-masked]] on behalf of Eric Rescorla [
> [email-masked]]
> *Sent:* 05 March 2018 23:05
> *To:* IETF QUIC WG
> *Subject:* Proposal: Run QUIC over DTLS
>
> Hi folks,
>
> This e-mail (and any attachments) is confidential and may contain personal
> views which are not the views of the BBC unless specifically stated.
> Do not use, copy or disclose the information in any way nor act in
> reliance on it and notify the sender immediately.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 5 Mar 2018 16:47:08 -0800

> plan, so I think it belongs on the list.

Hi Ted,

I was certainly expecting that we would discuss this on-list and then
at the meeting. Sorry if I made it seem otherwise.

WRT to the hackathon, I wasn't suggesting that we have some kind of
formal side meeting, just that this would be an opportunity to have
some small-group conversations, just as we have done in the past.

-Ekr

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 6 Mar 2018 12:46:16 +1100

Thanks for the proposal, EKR. We'll track this as <https://github.com/quicwg/base-drafts/issues/1165>.

Since we're trying to nail down the invariants in London (or soon afterwards), I'd like to figure out the WG's feelings on this pretty quickly.

I know folks need a chance to read and digest, but it would be extremely helpful if we could have some initial discussion on-list now. Please focus on the technical merit of the proposal, clarifying questions, and statements of support/lack thereof. 

Assuming it's still a topic of interest in two weeks, we'll schedule some time to discuss it in London. EKR, could you please submit a presentation (say, max 20 minutes, plus discussion time afterwards) ASAP?

Cheers,

> On 6 Mar 2018, at 10:05 am, Eric Rescorla <[email-masked]> wrote:
> 
> Hi folks,
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 5 Mar 2018 17:58:46 -0800

On Mon, Mar 5, 2018 at 5:46 PM, Mark Nottingham <[email-masked]> wrote:

> Thanks for the proposal, EKR. We'll track this as <
> https://github.com/quicwg/base-drafts/issues/1165>.
>
> Since we're trying to nail down the invariants in London (or soon
> afterwards), I'd like to figure out the WG's feelings on this pretty
> quickly.
>
> I know folks need a chance to read and digest, but it would be extremely
> helpful if we could have some initial discussion on-list now. Please focus
> on the technical merit of the proposal, clarifying questions, and
> statements of support/lack thereof.
>
> Assuming it's still a topic of interest in two weeks, we'll schedule some
> time to discuss it in London. EKR, could you please submit a presentation
> (say, max 20 minutes, plus discussion time afterwards) ASAP?
>

Willdo. It would be especially helpful to have clarifying questions soonish
so that I can either clarify them on-list, or know to hit them in the preso.

-Ekr

---

From: Ian Swett <[email-masked]>
Date: Tue, 06 Mar 2018 02:56:47 +0000

I do not think this is the right way forward for the QUIC WG(reasons
below), though if there are elements of DTLS worth bringing into the QUIC
handshake or TLS over QUIC mapping, I’m certainly open to them.

>From a working group perspective, the WG is finally reaching what is
feeling like convergence on the most critical issues(ie: Invariants), and
this opens many of those up again.  In particular, I'm worried both about
losing momentum and delaying Google's transition away from GQUIC.

>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.

>From a deployment perspective, having all HTTPS traffic using a single high
quality TLS implementation is very nice.  Unified crypto is definitely a
benefit of switching off QUIC crypto.

>From the perspective of implementation experience, the QUIC WG now has 9
implementations
<https://docs.google.com/spreadsheets/d/1D0tW89vOoaScs3IY9RGC0UesWGAwE6xyLk0l4JtvTVg/edit#gid=207940156>
that achieve interop with the current TLS mapping.  My feeling is that
we're aware of most of the outstanding issues and they are fixable.

>From the Google implementation perspective, the most mature IETF QUIC code
we have is the TLS mapping code, which we now have in deployment quality
code on the client and server side.  We spent more time on this because we
felt the move to TLS 1.3 was one of the few items which had consensus in
the WG, since it was specified in the charter.

Thanks, Ian

On Mon, Mar 5, 2018 at 8:59 PM Eric Rescorla <[email-masked]> wrote:

> Willdo. It would be especially helpful to have clarifying questions
> soonish so that I can either clarify them on-list, or know to hit them in
> the preso.
>
> -Ekr
>
>
>>
>> Cheers,
>>
>>

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 6 Mar 2018 13:32:28 +0900

> I'd like to discuss refactoring things to run QUIC over DTLS.

EKR, Thank you for writing this. This is a very interesting proposal!

I can see the point that the QUIC specification will become more
straightforward if we adopt the DTLS-based approach, while, as an
implementor of TLS 1.3 and QUIC, I do not think that the total cost of
maintaining crypto and transport would change a lot.

One thing that I like about the proposed approach in particular is the
negotiation. As your draft points out, current approach has the
overhead of requiring additional round-trip when the server's
preferred version differs from that of the client.

It makes sense to negotiate the QUIC version using the negotiation
scheme available in (D)TLS.

That said, I feel uneasy about building QUIC **on top of** DTLS.

My understanding is that the intent of the working group is to build a
transport. We have spent maybe about a half of our time discussing
things that need to be implemented below the crypto (e.g., connection
ID, stateless reset, path migration, etc.), while the other half being
above the crypto (e.g., streams and multiplexing).

I think that that reflects the nature of what transport is, and that
the two need to be discussed together. In other words, I am afraid
that moving half of the design to TLSWG while retaining the other half
in QUICWG is likely to lead to the need for much more discussion
(would we holding interims for two workgroups?) as well as making the
decision process more complex.

In my view, that increases the risk of QUIC standardization process
being either delayed or ultimately failing.

Therefore, I am sorry to say that I am negative to the proposal. I
would feel safer if the proposal is adjusted to retain the sandboxing
approach (i.e. define the layers below and above the crypto layers in
QUIC WG while switching to DTLS).

However, I also believe that the issues of the current approach that
have been pointed out by the proposal can be adjusted without
switching to DTLS, and I would prefer doing so unless we unanimously
agree to switch to DTLS.

PS. If we decide to adopt the proposal, I am happy to implement DTLS
in picotls. It would not take a lot of time to do so.

-- 
Kazuho Oku

---

From: Subodh Iyengar <[email-masked]>
Date: Tue, 6 Mar 2018 06:39:47 +0000

While using DTLS is not unworkable, the WG has put a lot of work put into the current header and packet format which shows that controlling the header format has several advantages for the transport to accomplish its goals. That being said, I think the spirit of ekr's proposal has several salient ideas which we could incorporate into the existing QUIC drafts  irrespective of deciding to adopt this draft.

One of the salient ideas is a more clear layering structure. I believe it is possible to implement even QUIC as currently specified with a layered API, even if the current drafts make no assumptions about layering of the protocol.

Even though our implementation, mvfst, is not layered, I can imagine an implementation creating a layering structure to be like

[ QUIC transport layer]

[ QUIC encryption and "record" layer ]

[ UDP ]

The roles of these layers are well defined (note that I have not implemented this yet).

The transport layer

--------------------------

It maintains the transport state and gets signals from the encryption layer on what type of data is appropriate to write, i.e. no data, 0rtt data, or 1rtt data.

Record layer

-------------------
The record layer would decide to encrypt the bytes with the appropriate keys.

The record layer would also send packets for handshake data. Since the transport and the record layer would share the same packet number space it would be appropriate to give ownership of packet number counting to the record layer. Before the transport layer constructs a packet it would ask the record layer to assign it a packet number to use for its state accounting.

Receiving a packet

---------------------------
The handshake layer decrypts the packet and hands the transport layer a packet number and the decrypted frame data. If the handshake layer has any handshake packets outstanding it would go into a mode where it would read all acks from all packets to make a decision on whether its handshake data needs to be retransmitted. The handshake layer would only be responsible for transmission of stream 0 data.

This allows acks for non handshake data to be used to re-transmit handshake data even though they are in different "layers". If the transport layer assumes that any gaps of data were transmitted by the handshake layer, it would also allow acks for handshake packets to be used for loss recovery of data packets as well by the transport layer.

I could see the current draft adopt a more layered editorial structure, or it might be simpler to have a separate draft that describes the layering design of QUIC. I would be happy to work with ekr on this if this needs a separate draft. The spec could incorporate some features to address the issues ekr brought up. 3 changes that might bring us closer are:

  *   We could move crypto out of stream 0 and giving it it's own frame type. This separates the "channel" of communication of crypto data from "streams" which the transport has to maintain state for. In several implementations, including ours, crypto streams are treated special for everything anyway. The only resemblance to a stream is in the state needed.
  *   Multiple QUIC packets in 1 UDP packet. There is already an open issue for this.
  *   Getting rid of regular packet gaps so that multiple layers can use gaps to decide which layer handled the data. I believe we are on a path to doing this anyway.

I'm not sure how to resolve the issue on version negotiation though.

Subodh

________________________________
IFrom: QUIC <[email-masked]> on behalf of Kazuho Oku <[email-masked]>
Sent: Monday, March 5, 2018 8:32:28 PM
To: Eric Rescorla
Cc: IETF QUIC WG
Subject: Re: Proposal: Run QUIC over DTLS

> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Drescorla-2Dquic-2Dover-2Ddtls_&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=wmlFadUY1Jjjb0308-LqYpvNMl8SR01vRZd6V_CwVVA&s=jI8gErodUXMcWnUPIRvyAO-NCsnN779ZOxJukgJzqXg&e=
draft-rescorla-quic-over-dtls-00 - QUIC over DTLS <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Drescorla-2Dquic-2Dover-2Ddtls_&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=wmlFadUY1Jjjb0308-LqYpvNMl8SR01vRZd6V_CwVVA&s=jI8gErodUXMcWnUPIRvyAO-NCsnN779ZOxJukgJzqXg&e=>
urldefense.proofpoint.com
QUIC over DTLS (Internet-Draft, 2018)

> Mint: https://github.com/ekr/mint/tree/dtls_for_quic
[https://avatars0.githubusercontent.com/u/1111457?s=400&v=4]<https://github.com/ekr/mint/tree/dtls_for_quic>

ekr/mint<https://github.com/ekr/mint/tree/dtls_for_quic>
github.com
mint - A Minimal TLS 1.3 Implementation in Go

--
Kazuho Oku

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 6 Mar 2018 07:47:51 +0000

To be honest, I have been wondering why the QUIC group started with TLS 1.3 instead of DTLS 1.3 all along.
For me this makes sense.

Ciao
Hannes

From: QUIC [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: 06 March 2018 00:06
To: IETF QUIC WG
Subject: Proposal: Run QUIC over DTLS

Hi folks,

TL;DR.

DETAILS

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Tue, 6 Mar 2018 00:49:29 -0800

This is an interesting proposal.

- It clearly points out that the current crypto handshake does not map as
cleanly as it could be - also noting the recent discussion on list about
truncating stream 0 early.

- It makes it much simpler to layer QUIC over other transports. For
example, a low-end device on a very secure line, such as an ABS breaking
system, could send QUIC without crypto framing to a central core, but still
use all of the QUIC semantics.

- It could simplify/accelerate use of QUIC in web browsers.

- It is a hammer allowing applications to deploy DTLS without only using
QUIC. Sometimes QUIC may be need a lot of spec work to map a concept - for
example IoT MQTT over QUIC is not clear cut, but it is easy to use DTLS.
Having to use both DTLS and QUIC in app may be a bit much if they are not
fundamentally the same.

That said, I agree with Ian and others - there are a bit too many moving
parts and dependencies. It is very nice to have a single self-contained
construct. Already the need to depend on TLS adds a lot of complexity (even
if it can be hidden by third party libraries).

I would suggest how to reconsider a much cleaner crypto mapping inside QUIC
based on these findings as Ian, Kazuhu, and Sudbodh also touches upon.

Even if this fails due to timeline - it may be worthwhile goal for v2.

If QUIC invariants were tied to DTLS it might not be possible to move out
of that tie-in - even for custom or special purpose versions of QUIC - i.e.
too much friction.

Kind Regards,
Mikkel Fahnøe Jørgensen

On 6 March 2018 at 08.48.09, Hannes Tschofenig ([email-masked])
wrote:

To be honest, I have been wondering why the QUIC group started with TLS 1.3
instead of DTLS 1.3 all along.

For me this makes sense.

Ciao

Hannes

*From:* QUIC [mailto:[email-masked]] *On Behalf Of *Eric Rescorla
*Sent:* 06 March 2018 00:06
*To:* IETF QUIC WG
*Subject:* Proposal: Run QUIC over DTLS

Hi folks,

TL;DR.

DETAILS

including:

    to service it.

    crypto state machine.

impact contained.

-Ekr

IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you.

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 6 Mar 2018 18:29:28 +0900

2018-03-06 15:39 GMT+09:00 Subodh Iyengar <[email-masked]>:

> While using DTLS is not unworkable, the WG has put a lot of work put into
> the current header and packet format which shows that controlling the
> header format has several advantages for the transport to accomplish its
> goals. That being said, I think the spirit of ekr's proposal has several
> salient ideas which we could incorporate into the existing QUIC drafts
> irrespective of deciding to adopt this draft.
>
> One of the salient ideas is a more clear layering structure. I believe it
> is possible to implement even QUIC as currently specified with a layered
> API, even if the current drafts make no assumptions about layering of the
> protocol.
>
>
> Even though our implementation, mvfst, is not layered, I can imagine an
> implementation creating a layering structure to be like
>
>
> [ QUIC transport layer]
>
> It maintains the transport state and gets signals from the encryption
> layer on what type of data is appropriate to write, i.e. no data, 0rtt
> data, or 1rtt data.
>
>
> Record layer
>
> -------------------
> The record layer would also send packets for handshake data. Since the
> transport and the record layer would share the same packet number space it
> would be appropriate to give ownership of packet number counting to the
> record layer. Before the transport layer constructs a packet it would ask
> the record layer to assign it a packet number to use for its state
> accounting.
>
> Receiving a packet
>
> The handshake layer decrypts the packet and hands the transport layer a
> packet number and the decrypted frame data. If the handshake layer has any
> handshake packets outstanding it would go into a mode where it would read
> all acks from all packets to make a decision on whether its handshake data
> needs to be retransmitted. The handshake layer would only be responsible
> for transmission of stream 0 data.
>
>
> This allows acks for non handshake data to be used to re-transmit
> handshake data even though they are in different "layers". If the transport
> layer assumes that any gaps of data were transmitted by the handshake
> layer, it would also allow acks for handshake packets to be used for loss
> recovery of data packets as well by the transport layer.
>
> I could see the current draft adopt a more layered editorial structure, or
> it might be simpler to have a separate draft that describes the layering
> design of QUIC. I would be happy to work with ekr on this if this needs a
> separate draft. The spec could incorporate some features to address the
> issues ekr brought up. 3 changes that might bring us closer are:
>
>
>
>    - We could move crypto out of stream 0 and giving it it's own frame
>    type. This separates the "channel" of communication of crypto data
>    from "streams" which the transport has to maintain state for. In
>    several implementations, including ours, crypto streams are treated special
>    for everything anyway. The only resemblance to a stream is in the state
>    needed.
>    - Multiple QUIC packets in 1 UDP packet. There is already an open
>    issue for this.
>    - Getting rid of regular packet gaps so that multiple layers can use
>    gaps to decide which layer handled the data. I believe we are on a path to
>    doing this anyway.
>
>

Honestly speaking, I do not understand why people are interested in doing
QUIC v2 soon.

If we want to extend QUIC v1, we can add new extensions to TLS to negotiate
additional features.

Regarding preventing ossification, I think that can be (and should be)
achieved through greasing and obfuscation.

If my assumptions listed here are correct, requiring additional round-trip
is a non-issue. Assuming that a non-compatible change will come only once a
decade, we can just do happy eyeballs with QUIC version N and version N+1.

> *IFrom:* QUIC <[email-masked]> on behalf of Kazuho Oku <
> [email-masked]>
> *Sent:* Monday, March 5, 2018 8:32:28 PM
> *To:* Eric Rescorla
> *Cc:* IETF QUIC WG
> *Subject:* Re: Proposal: Run QUIC over DTLS
>
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__
> datatracker.ietf.org_doc_draft-2Drescorla-2Dquic-
> 2Dover-2Ddtls_&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=
> h3Ju9EBS7mHtwg-wAyN7fQ&m=wmlFadUY1Jjjb0308-LqYpvNMl8SR01vRZd6V_CwVVA&s=
> jI8gErodUXMcWnUPIRvyAO-NCsnN779ZOxJukgJzqXg&e=
> draft-rescorla-quic-over-dtls-00 - QUIC over DTLS
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Drescorla-2Dquic-2Dover-2Ddtls_&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=wmlFadUY1Jjjb0308-LqYpvNMl8SR01vRZd6V_CwVVA&s=jI8gErodUXMcWnUPIRvyAO-NCsnN779ZOxJukgJzqXg&e=>
> <https://github.com/ekr/mint/tree/dtls_for_quic>
> ekr/mint <https://github.com/ekr/mint/tree/dtls_for_quic>
> github.com

-- 
Kazuho Oku

---

From: Marten Seemann <[email-masked]>
Date: Tue, 06 Mar 2018 10:10:09 +0000

Thanks for writing this up. This is really interesting to think through.

Thinking about the crypto layer, I'm beginning to wonder if the decision to
move QUIC to TLS 1.3 was the right one in the first place. For quic-go, I
first implemented QUIC crypto from scratch and later integrated an existing
TLS 1.3 library. Implementing QUIC crypto was a lot easier, and the
resulting code is so much cleaner than dealing with the strong coupling
between QUIC and TLS. I'm not sure if moving to DTLS will significantly
reduce the overall coupling, although certainly the coupling points will be
very different.
If the working group is considering a change in the crypto layer at this
point, maybe we should keep QUIC crypto in mind as a third option.

On Tue, Mar 6, 2018 at 4:29 PM Kazuho Oku <[email-masked]> wrote:

>> I could see the current draft adopt a more layered editorial structure,
>> or it might be simpler to have a separate draft that describes the layering
> If we want to extend QUIC v1, we can add new extensions to TLS to
> negotiate additional features.
>

---

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 6 Mar 2018 12:29:49 +0100

Hi Ekr, hi all,

I agree that it is architecturally not great to use stream 0 for the crypto handshake and send data unencrypted over this stream. However, layering the crypto above (old school TLS) or below (DTLS) is architecturally also not great and rather a hack given that encryption was not build in from the beginning in the transports we have. Security should be a function on each layer and not something own above or below. The problem here is that the crypto handshake itself needs a transport for its negotiation. So I think separating the handshake/control protocol from the actually record protection is the key point here. TLS already nicely has this separation but then we try to squeeze it on the same transport again. This is also some we discus in TAPS and I have a draft on:

https://datatracker.ietf.org/doc/draft-kuehlewind-taps-crypto-sep/

While I’m in principle supportive with the goal of taking the handshake out of the quic and thereby design quic as a fully encrypted protocol, the one think that I really don’t like about your proposal is that later on also all quic communication needs to run on top of DTLS; that seems unnecessary overhead and also adds a second complete unnecessary reliability layer below the actual transport.

So I guess the alternative, and architectural more clean approach from my point of view, would be to run the crypto handshake completely separate and potentially in parallel to the quic connection, either using DTLS or even TLS over TCP, and then provide the respective keys to the quic crypto engine that than handles the actual record protection. 

However, I don’t think this is something that should be addressed in the current state of the quic design process as we really should focus on the goal to get a first version out quickly. However, my intent was from the beginning to make such a solution possible. QUIC does nicely separate the crypto engine from the rest, such that is should be possible to import keys from an „external“ source. The parts that are less clear separated are the handshake (and other control messages to maintain the crypto engine), especially one would need a separate mechanism to negotiate the transport parameter.

As a side, another nice thing when separating the crypto handshake completely for the HTTP2 use case is also that you in many case already have a TCP/TLS connection to discover the HTTP2 (and quic) support and it would be really nice to reuse these credentials directly to start with quic 0-RTT :-)

Mirja

> Am 06.03.2018 um 00:05 schrieb Eric Rescorla <[email-masked]>:
> 
> Hi folks,
>

---

From: "Lubashev, Igor" <[email-masked]>
Date: Tue, 6 Mar 2018 12:54:39 +0000

If it requires an extra rtt to do version negotiation, it is likely that extensions will be created by other means. If we improve version negotiation to look more like one in Ekr's draft (no extra rtt), standard extensions are more likely to come in via new versions.

- Igor

-----Original Message-----
From: Kazuho Oku [[email-masked]]
Received: Tuesday, 06 Mar 2018, 4:29AM
To: Subodh Iyengar [[email-masked]]
CC: Eric Rescorla [[email-masked]]; IETF QUIC WG [[email-masked]]
Subject: Re: Proposal: Run QUIC over DTLS

2018-03-06 15:39 GMT+09:00 Subodh Iyengar <[email-masked]<mailto:[email-masked]>>:

[ QUIC transport layer]

[ UDP ]

The transport layer

Record layer

-------------------

Receiving a packet

Honestly speaking, I do not understand why people are interested in doing QUIC v2 soon.

If we want to extend QUIC v1, we can add new extensions to TLS to negotiate additional features.

Regarding preventing ossification, I think that can be (and should be) achieved through greasing and obfuscation.

If my assumptions listed here are correct, requiring additional round-trip is a non-issue. Assuming that a non-compatible change will come only once a decade, we can just do happy eyeballs with QUIC version N and version N+1.

Subodh

________________________________
IFrom: QUIC <[email-masked]<mailto:[email-masked]>> on behalf of Kazuho Oku <[email-masked]<mailto:[email-masked]>>
Sent: Monday, March 5, 2018 8:32:28 PM
To: Eric Rescorla
Cc: IETF QUIC WG
Subject: Re: Proposal: Run QUIC over DTLS

draft-rescorla-quic-over-dtls-00 - QUIC over DTLS <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Drescorla-2Dquic-2Dover-2Ddtls_&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=wmlFadUY1Jjjb0308-LqYpvNMl8SR01vRZd6V_CwVVA&s=jI8gErodUXMcWnUPIRvyAO-NCsnN779ZOxJukgJzqXg&e=>
urldefense.proofpoint.com<http://urldefense.proofpoint.com>
QUIC over DTLS (Internet-Draft, 2018)

> Mint: https://github.com/ekr/mint/tree/dtls_for_quic<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ekr_mint_tree_dtls-5Ffor-5Fquic&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=b6jd5-68l8KIOjjP3VLQl0n4-nG_AK0nHdgYjq7czeo&s=OsJIuftBk94j2kJ0LIntv4z5Bk50ElGLuqHOGaaMEO0&e=>
[https://avatars0.githubusercontent.com/u/1111457?s=400&v=4]<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ekr_mint_tree_dtls-5Ffor-5Fquic&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=b6jd5-68l8KIOjjP3VLQl0n4-nG_AK0nHdgYjq7czeo&s=OsJIuftBk94j2kJ0LIntv4z5Bk50ElGLuqHOGaaMEO0&e=>

ekr/mint<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ekr_mint_tree_dtls-5Ffor-5Fquic&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=b6jd5-68l8KIOjjP3VLQl0n4-nG_AK0nHdgYjq7czeo&s=OsJIuftBk94j2kJ0LIntv4z5Bk50ElGLuqHOGaaMEO0&e=>
github.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__github.com&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=b6jd5-68l8KIOjjP3VLQl0n4-nG_AK0nHdgYjq7czeo&s=pgQZdr9HiFSR57L7q08NFfOjV-4_s-sI_vyL3IEiFFQ&e=>
mint - A Minimal TLS 1.3 Implementation in Go

> Minq: https://github.com/ekr/minq/tree/quic_over_dtls<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ekr_minq_tree_quic-5Fover-5Fdtls&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=b6jd5-68l8KIOjjP3VLQl0n4-nG_AK0nHdgYjq7czeo&s=yL_l3GbAGI_L_5y9edwYPjxyiQy31uQ49rLJybFD1dw&e=>
>
>

--
Kazuho Oku

--
Kazuho Oku

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 6 Mar 2018 13:47:00 +0000

Hi,

From: Eric Rescorla [mailto:[email-masked]]
Sent: 06 March 2018 00:42
To: Lucas Pardue <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>
Subject: Re: Proposal: Run QUIC over DTLS

On Mon, Mar 5, 2018 at 3:58 PM, Lucas Pardue <[email-masked]<mailto:[email-masked]>> wrote:
Hi EKR,

Hi Lucas,

DTLS and TLS have pretty similar designs in this respect (DTLS is primarily a thin reliability layer on the TLS handshake), and in general TLS has key exchange and packet protection separated, in much the same way things are in the current QUIC design, just with a different packet encryption.

TLS is explicitly designed to allow for flexibility in the crypto core, so I would imagine we're going to see a bunch of innovation there over the next few years. The putman draft is one example of what people are looking at, but I'm aware of others as well.

-Ekr

Thanks for the clarification!

Lucas

http://www.bbc.co.uk

---------------------

---

From: Patrick McManus <[email-masked]>
Date: Tue, 6 Mar 2018 09:56:46 -0500

Hi All,

I'm thinking about this question as "Is Stream 0 a Design Flaw?".. The DTLS
part is largely putting a solution to that problem out front and isn't
really the determining question to me. Its a flashy distraction.

The nominal value of Stream 0 is more or less a replacement for TCP to run
a well known and trusted (and therefore to some degree opaque) TLS over - a
reliable in-order congestion controlled stream.

It turns out not to do that very well.

   1. Acknowledgements are heavily intertwined with handshake state - both
   in sending and receiving. This results in duplicating acks both in
   protected and unprotected contexts and implementations dropping
   acknowledgments that they need after keying material has been established.
   The interactions with loss are very bad.
   2. The acknowledgment problem is also going to rear its head when we
   make use of the key phase bit, which again.
   3. which brings me to the 'opaque' things that happen on stream 0 when
   we just reuse the tls stack there. They aren't opaque.
      1. key phases - you better be aware of these
      2. session tickets - you better annotate these with source validation
      information
      3. retry - you better not send these in stream 0
      4. tls alert - you better change your state machine and generate a
      quic level frame here too
   4. there are more..

There isn't much disagreement that this stream 0 behavior is ugly. however
as a WG I think we're subtly taking on the mindset that these are
established roadblocks we need to work around (i.e. a middlebox mentality).
We're designing a protocol we expect to have for a long time and we agreed
initially that what was in -00 was not to be given undue weight simply
because it in was in -00.

so the question to me is - can we fix stream 0 in a way that is a
significant net positive to the protocol? I think the draft makes a pretty
decent case for that.

-P

On Tue, Mar 6, 2018 at 7:54 AM, Lubashev, Igor <
ilubashe=[email-masked]> wrote:

> If it requires an extra rtt to do version negotiation, it is likely that
> extensions will be created by other means. If we improve version
> negotiation to look more like one in Ekr's draft (no extra rtt), standard
> extensions are more likely to come in via new versions.
>
> - Igor
>
>
> *From:* Kazuho Oku [[email-masked]]
> *Received:* Tuesday, 06 Mar 2018, 4:29AM
> *To:* Subodh Iyengar [[email-masked]]
> *CC:* Eric Rescorla [[email-masked]]; IETF QUIC WG [[email-masked]]
>> > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatra
>> cker.ietf.org_doc_draft-2Drescorla-2Dquic-2Dover-
>> 2Ddtls_&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-
>> wAyN7fQ&m=wmlFadUY1Jjjb0308-LqYpvNMl8SR01vRZd6V_CwVVA&s=jI8g
>> ErodUXMcWnUPIRvyAO-NCsnN779ZOxJukgJzqXg&e=
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ekr_mint_tree_dtls-5Ffor-5Fquic&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=b6jd5-68l8KIOjjP3VLQl0n4-nG_AK0nHdgYjq7czeo&s=OsJIuftBk94j2kJ0LIntv4z5Bk50ElGLuqHOGaaMEO0&e=>
>>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ekr_mint_tree_dtls-5Ffor-5Fquic&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=b6jd5-68l8KIOjjP3VLQl0n4-nG_AK0nHdgYjq7czeo&s=OsJIuftBk94j2kJ0LIntv4z5Bk50ElGLuqHOGaaMEO0&e=>
>> ekr/mint
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ekr_mint_tree_dtls-5Ffor-5Fquic&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=b6jd5-68l8KIOjjP3VLQl0n4-nG_AK0nHdgYjq7czeo&s=OsJIuftBk94j2kJ0LIntv4z5Bk50ElGLuqHOGaaMEO0&e=>
>> github.com
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__github.com&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=b6jd5-68l8KIOjjP3VLQl0n4-nG_AK0nHdgYjq7czeo&s=pgQZdr9HiFSR57L7q08NFfOjV-4_s-sI_vyL3IEiFFQ&e=>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ekr_minq_tree_quic-5Fover-5Fdtls&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=b6jd5-68l8KIOjjP3VLQl0n4-nG_AK0nHdgYjq7czeo&s=yL_l3GbAGI_L_5y9edwYPjxyiQy31uQ49rLJybFD1dw&e=>
>> >
>> >

---

From: Patrick McManus <[email-masked]>
Date: Tue, 6 Mar 2018 09:56:46 -0500

Hi All,

-P

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 6 Mar 2018 07:12:39 -0800

FWIW it is possible to move the style of version negotiation from my draft
directly into the current draft if we so wanted. It's just that it's
necessary if QUIC is at the bottom of the stack and so is a nice extra win.

Specifically, we would have the version in the long header In Initial refer
not to the QUIC version we want to negotiate but rather to the version
whose obfuscation method we are using (probably the client's minimum). The
CH would then have an extension which contained the QUIC versions we
support (as in TLS.supported_versions) and then the SH would contain both
selected versions. We could have the remaining obfuscated long header
packets could use *either* obfuscation version. The encrypted long header
packets would of course use the negotiated versions.

A few notes:

- The CH always comes in one packet so that you don't have to worry about
it being immediately available to the server
- The SH may be broken up but as noted above, the obfuscation version isn't
part of the negotiation.

As with my draft, this would give you 1-RTT negotiation if the client
obfuscated with a version the server knew and 2-RTT if the client
obfuscated with a version the server didn't know, as opposed to always
having 2-RTT

If people think they like this idea, I'd be happy to write it up a separate
PR.

-Ekr

On Tue, Mar 6, 2018 at 4:54 AM, Lubashev, Igor <[email-masked]> wrote:

>> cker.ietf.org_doc_draft-2Drescorla-2Dquic-2Dover-2Ddtls_&d=
>> DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=
>> wmlFadUY1Jjjb0308-LqYpvNMl8SR01vRZd6V_CwVVA&s=jI8gErodUXMcWn
>> UPIRvyAO-NCsnN779ZOxJukgJzqXg&e=

---

From: Christian Huitema <[email-masked]>
Date: Tue, 6 Mar 2018 07:45:41 -0800

On 3/6/2018 7:12 AM, Eric Rescorla wrote:
> FWIW it is possible to move the style of version negotiation from my
> draft directly into the current draft if we so wanted. It's just that
> it's necessary if QUIC is at the bottom of the stack and so is a nice
> extra win.
>
> Specifically, we would have the version in the long header In Initial
> refer not to the QUIC version we want to negotiate but rather to the
> version whose obfuscation method we are using (probably the client's
> minimum). The CH would then have an extension which contained the QUIC
> versions we support (as in TLS.supported_versions) and then the SH
> would contain both selected versions. We could have the remaining
> obfuscated long header packets could use *either* obfuscation version.
> The encrypted long header packets would of course use the negotiated
> versions.
>
> A few notes:
>
> - The CH always comes in one packet so that you don't have to worry
> about it being immediately available to the server
> - The SH may be broken up but as noted above, the obfuscation version
> isn't part of the negotiation.
>
> If people think they like this idea, I'd be happy to write it up a
> separate PR.
>
Seems like a good idea, yes. Waiting to see the PR!

-- Christian Huitema

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 6 Mar 2018 15:59:20 +0000

Hi,

my main concern here is not specific to this proposal, but about introducing significant changes to the invariants and the wire format eight months before we are supposed to ship RFCs.

My guess is that it'd take a few months of implementation and interop time to get back to where we are now, and that that delay will surely render our November milestones infeasible.

A secondary concern is that we'd run the risk of jeopardizing implementer goodwill. People have invested in their implementation roadmaps, and if we reassembling the pieces on the board - even with the best intentions - that is really not something we should be doing lightly.

In other words, we should very carefully think about whether the benefits here are worth the delays and resulting risks.

Lars

---

From: Roberto Peon <[email-masked]>
Date: Tue, 6 Mar 2018 17:29:07 +0000

We’ve been using stream-0 as short-hand for things-which-relate-to-the-connection.

Putting connection-level data on a stream complicates the spec (and arguably the code, though not enough to really care, I suspect). I think we achieve better clarity at little to no cost by treating these transport-level control data as something 100% decoupled from the application-layer data, i.e. not a stream.

While I believe it can be done properly (and transport on DTLS is a much better approach than was TLS on TCP) I’m afraid of layering in implementations. We know from experience that such layerings often promote system complexity/degrade performance when such layering causes a loss of control/visibility. For instance, TLS layered poorly with HTTP/TCP, since the various semantic layers were not aligned—a loss of a byte (in another packet) from a separate HTTP request would HoL block another one, etc.

-=R

From: QUIC <[email-masked]> on behalf of Patrick McManus <[email-masked]>
Date: Tuesday, March 6, 2018 at 6:57 AM
To: "Lubashev, Igor" <ilubashe=[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Subodh Iyengar <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Proposal: Run QUIC over DTLS

Hi All,

I'm thinking about this question as "Is Stream 0 a Design Flaw?".. The DTLS part is largely putting a solution to that problem out front and isn't really the determining question to me. Its a flashy distraction.

The nominal value of Stream 0 is more or less a replacement for TCP to run a well known and trusted (and therefore to some degree opaque) TLS over - a reliable in-order congestion controlled stream.

  1.  Acknowledgements are heavily intertwined with handshake state - both in sending and receiving. This results in duplicating acks both in protected and unprotected contexts and implementations dropping acknowledgments that they need after keying material has been established. The interactions with loss are very bad.
  2.  The acknowledgment problem is also going to rear its head when we make use of the key phase bit, which again.
  3.  which brings me to the 'opaque' things that happen on stream 0 when we just reuse the tls stack there. They aren't opaque.

     *   key phases - you better be aware of these
     *   session tickets - you better annotate these with source validation information
     *   retry - you better not send these in stream 0
     *   tls alert - you better change your state machine and generate a quic level frame here too

  1.  there are more..
There isn't much disagreement that this stream 0 behavior is ugly. however as a WG I think we're subtly taking on the mindset that these are established roadblocks we need to work around (i.e. a middlebox mentality). We're designing a protocol we expect to have for a long time and we agreed initially that what was in -00 was not to be given undue weight simply because it in was in -00.

so the question to me is - can we fix stream 0 in a way that is a significant net positive to the protocol? I think the draft makes a pretty decent case for that.

-P

On Tue, Mar 6, 2018 at 7:54 AM, Lubashev, Igor <ilubashe=[email-masked]<mailto:ilubashe=[email-masked]>> wrote:
If it requires an extra rtt to do version negotiation, it is likely that extensions will be created by other means. If we improve version negotiation to look more like one in Ekr's draft (no extra rtt), standard extensions are more likely to come in via new versions.

- Igor

-----Original Message-----
From: Kazuho Oku [[email-masked]<mailto:[email-masked]>]
Received: Tuesday, 06 Mar 2018, 4:29AM
To: Subodh Iyengar [[email-masked]<mailto:[email-masked]>]
CC: Eric Rescorla [[email-masked]<mailto:[email-masked]>]; IETF QUIC WG [[email-masked]<mailto:[email-masked]>]
Subject: Re: Proposal: Run QUIC over DTLS

[ QUIC transport layer]

[ UDP ]

The transport layer

Record layer

-------------------

Receiving a packet

Subodh

> Mint: https://github.com/ekr/mint/tree/dtls_for_quic<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ekr_mint_tree_dtls-5Ffor-5Fquic&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDP…
[Image removed by sender.]

--
Kazuho Oku

--
Kazuho Oku

---

From: Roberto Peon <[email-masked]>
Date: Tue, 6 Mar 2018 17:29:07 +0000

-=R

Hi All,

  1.  there are more..

-P

- Igor

-----Original Message-----
From: Kazuho Oku [[email-masked]<mailto:[email-masked]>]
Received: Tuesday, 06 Mar 2018, 4:29AM
To: Subodh Iyengar [[email-masked]<mailto:[email-masked]>]
CC: Eric Rescorla [[email-masked]<mailto:[email-masked]>]; IETF QUIC WG [[email-masked]<mailto:[email-masked]>]
Subject: Re: Proposal: Run QUIC over DTLS

[ QUIC transport layer]

[ UDP ]

The transport layer

Record layer

-------------------

Receiving a packet

Subodh

--
Kazuho Oku

--
Kazuho Oku

---

From: Mike Bishop <[email-masked]>
Date: Tue, 6 Mar 2018 17:32:33 +0000

My concern with this specific idea, as with the broader DTLS draft, is that you’re making some very fundamental assumptions about things we’ve tried hard to keep flexible.  That is, you’re ossifying the protocol.  While our plans to rev versions more quickly means that v1 doesn’t have to be perfect, we’re going to be living with the invariants a long time, so they should be as general as possible.  TLS isn’t part of the invariants, and what you’re proposing makes TLS an invariant.

On the contrary, we decided relatively early on that the version negotiated implied the crypto handshake to be used, which would be TLS for v1.  If QUIC runs on top of DTLS, or negotiates versions via TLS extension, that’s no longer true.  If (D)TLS is a required component to do version negotiation, you’re kind of backed into a corner.  I know that TLS itself is designed for crypto agility, and perhaps you’re correct that we’ll never need a handshake protocol that isn’t TLS, but I don’t want to make that assumption.

With the existing QUIC version negotiation and packet protection model, these concerns are well-separated and I think that’s a valuable feature.

From: QUIC [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Tuesday, March 6, 2018 7:13 AM
To: Lubashev, Igor <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Proposal: Run QUIC over DTLS

FWIW it is possible to move the style of version negotiation from my draft directly into the current draft if we so wanted. It's just that it's necessary if QUIC is at the bottom of the stack and so is a nice extra win.

Specifically, we would have the version in the long header In Initial refer not to the QUIC version we want to negotiate but rather to the version whose obfuscation method we are using (probably the client's minimum). The CH would then have an extension which contained the QUIC versions we support (as in TLS.supported_versions) and then the SH would contain both selected versions. We could have the remaining obfuscated long header packets could use *either* obfuscation version. The encrypted long header packets would of course use the negotiated versions.

A few notes:

- The CH always comes in one packet so that you don't have to worry about it being immediately available to the server
- The SH may be broken up but as noted above, the obfuscation version isn't part of the negotiation.

As with my draft, this would give you 1-RTT negotiation if the client obfuscated with a version the server knew and 2-RTT if the client obfuscated with a version the server didn't know, as opposed to always having 2-RTT

If people think they like this idea, I'd be happy to write it up a separate PR.

-Ekr

On Tue, Mar 6, 2018 at 4:54 AM, Lubashev, Igor <[email-masked]<mailto:[email-masked]>> wrote:
If it requires an extra rtt to do version negotiation, it is likely that extensions will be created by other means. If we improve version negotiation to look more like one in Ekr's draft (no extra rtt), standard extensions are more likely to come in via new versions.

- Igor

-----Original Message-----
From: Kazuho Oku [[email-masked]<mailto:[email-masked]>]
Received: Tuesday, 06 Mar 2018, 4:29AM
To: Subodh Iyengar [[email-masked]<mailto:[email-masked]>]
CC: Eric Rescorla [[email-masked]<mailto:[email-masked]>]; IETF QUIC WG [[email-masked]<mailto:[email-masked]>]
Subject: Re: Proposal: Run QUIC over DTLS

[ QUIC transport layer]

[ UDP ]

The transport layer

Record layer

-------------------

Receiving a packet

Subodh

ekr/mint<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ekr_mint_tree_dtls-5Ffor-5Fquic&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=b6jd5-68l8KIOjjP3VLQl0n4-nG_AK0nHdgYjq7czeo&s=OsJIuftBk94j2kJ0LIntv4z5Bk50ElGLuqHOGaaMEO0&e=>
github.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ekr_mint_tree_dtls-5Ffor-5Fquic&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=b6jd5-68l8KIOjjP3VLQl0n4-nG_AK0nHdgYjq7czeo&s=OsJIuftBk94j2kJ0LIntv4z5Bk50ElGLuqHOGaaMEO0&e=>
mint - A Minimal TLS 1.3 Implementation in Go<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ekr_mint_tree_dtls-5Ffor-5Fquic&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=b6jd5-68l8KIOjjP3VLQl0n4-nG_AK0nHdgYjq7czeo&s=OsJIuftBk94j2kJ0LIntv4z5Bk50ElGLuqHOGaaMEO0&e=>

--
Kazuho Oku<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ekr_mint_tree_dtls-5Ffor-5Fquic&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=b6jd5-68l8KIOjjP3VLQl0n4-nG_AK0nHdgYjq7czeo&s=OsJIuftBk94j2kJ0LIntv4z5Bk50ElGLuqHOGaaMEO0&e=>

<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ekr_mint_tree_dtls-5Ffor-5Fquic&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=b6jd5-68l8KIOjjP3VLQl0n4-nG_AK0nHdgYjq7czeo&s=OsJIuftBk94j2kJ0LIntv4z5Bk50ElGLuqHOGaaMEO0&e=>
 <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ekr_mint_tree_dtls-5Ffor-5Fquic&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=b6jd5-68l8KIOjjP3VLQl0n4-nG_AK0nHdgYjq7czeo&s=OsJIuftBk94j2kJ0LIntv4z5Bk50ElGLuqHOGaaMEO0&e=>
-- <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ekr_mint_tree_dtls-5Ffor-5Fquic&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=b6jd5-68l8KIOjjP3VLQl0n4-nG_AK0nHdgYjq7czeo&s=OsJIuftBk94j2kJ0LIntv4z5Bk50ElGLuqHOGaaMEO0&e=>
Kazuho Oku<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ekr_mint_tree_dtls-5Ffor-5Fquic&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=b6jd5-68l8KIOjjP3VLQl0n4-nG_AK0nHdgYjq7czeo&s=OsJIuftBk94j2kJ0LIntv4z5Bk50ElGLuqHOGaaMEO0&e=>
 <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ekr_mint_tree_dtls-5Ffor-5Fquic&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=b6jd5-68l8KIOjjP3VLQl0n4-nG_AK0nHdgYjq7czeo&s=OsJIuftBk94j2kJ0LIntv4z5Bk50ElGLuqHOGaaMEO0&e=>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 6 Mar 2018 09:45:36 -0800

On Tue, Mar 6, 2018 at 9:32 AM, Mike Bishop <[email-masked]> wrote:

> My concern with this specific idea, as with the broader DTLS draft, is
> that you’re making some very fundamental assumptions about things we’ve
> tried hard to keep flexible.  That is, you’re ossifying the protocol.
> While our plans to rev versions more quickly means that v1 doesn’t have to
> be perfect, we’re going to be living with the invariants a *long* time,
> so they should be as general as possible.  TLS isn’t part of the
> invariants, and what you’re proposing makes TLS an invariant.
>
>
>
> On the contrary, we decided relatively early on that the version
> negotiated implied the crypto handshake to be used, which would be TLS for
> v1.  If QUIC runs on top of DTLS, or negotiates versions via TLS extension,
> that’s no longer true.  If (D)TLS is a required component to do version
> negotiation, you’re kind of backed into a corner.  I know that TLS itself
> is designed for crypto agility, and perhaps you’re correct that we’ll never
> need a handshake protocol that isn’t TLS, but I don’t want to make that
> assumption.
>

Hi Mike,

Thanks for your note. A few points in no particular order.

There are a couple of questions about the invariants here. I think this
would make the DTLS record wire image (or whatever we ended up using) an
invariant, but I think it would be possible to use the VN-style version
negotiation to switch off of DTLS if we had to, the same way as we would if
we wanted to with TLS. I do agree that the new replacement would need its
own version negotiation mechanism to confirm that

-Ekr

>
> With the existing QUIC version negotiation and packet protection model,
> these concerns are well-separated and I think that’s a valuable feature.
>
>
>
> *Sent:* Tuesday, March 6, 2018 7:13 AM
> *To:* Lubashev, Igor <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; [email-masked]
>
> versions we support (as in TLS.supported_versions) and then the SH would
> contain both selected versions. We could have the remaining obfuscated long
> header packets could use *either* obfuscation version. The encrypted long
> header packets would of course use the negotiated versions.
>
>
>
> A few notes:
>
>
>
>    type. This separates the "channel" of communication of crypto data from
>    "streams" which the transport has to maintain state for. In several
>    implementations, including ours, crypto streams are treated special for
>    everything anyway. The only resemblance to a stream is in the state needed.
> *github.com*
> > Minq: *https://github.com/ekr/minq/tree/quic_over_dtls*
> >
> >

---

From: Christian Huitema <[email-masked]>
Date: Tue, 6 Mar 2018 10:00:15 -0800

On 3/6/2018 6:56 AM, Patrick McManus wrote:

>
> I'm thinking about this question as "Is Stream 0 a Design Flaw?".. The
> DTLS part is largely putting a solution to that problem out front and
> isn't really the determining question to me. Its a flashy distraction.
>
> The nominal value of Stream 0 is more or less a replacement for TCP to
> run a well known and trusted (and therefore to some degree opaque) TLS
> over - a reliable in-order congestion controlled stream.

It certainly was thought from the start as a compromise. But there is a
big reason behind it: avoid creating a new key negotiation protocol from
scratch; avoid running two TLS-like stacks in parallel, on for TCP, one
for QUIC. There is beauty in having exactly the same code run in both
cases. Think attack surface, ease of patching, etc.

There is also beauty in *not* having a layered architecture, for the
reasons that Kazuho and Mirja mentioned. It is great to see transport
functions like acknowledgement or flow control fully contained in the
Quic transport. Quic is about transport innovation, and that pretty much
requires direct access to the network API. In practice, layered
implementation hide that API, so the transport developers have to
constantly negotiate with the intermediate layer developers. This direct
access to the network interface is a big gain for Quic.

>  1. Acknowledgements are heavily intertwined with handshake state -
>     both in sending and receiving. This results in duplicating acks
>     both in protected and unprotected contexts and implementations
>     dropping acknowledgments that they need after keying material has
>     been established. The interactions with loss are very bad.
>
Yes. That comes out regularly as a source of bugs in the interops. On
the other hand, most implementations have fixed that by now, and the new
applications have plenty of reference code to test with.

>  1. The acknowledgment problem is also going to rear its head when we
>  2. which brings me to the 'opaque' things that happen on stream 0
>     when we just reuse the tls stack there. They aren't opaque.
>      2. session tickets - you better annotate these with source
>         validation information
>      4. tls alert - you better change your state machine and generate
>         a quic level frame here too
>  3. there are more..
>
> There isn't much disagreement that this stream 0 behavior is ugly.
> however as a WG I think we're subtly taking on the mindset that these
> are established roadblocks we need to work around (i.e. a middlebox
> mentality). We're designing a protocol we expect to have for a long
> time and we agreed initially that what was in -00 was not to be given
> undue weight simply because it in was in -00.
>
> significant net positive to the protocol? I think the draft makes a
> pretty decent case for that.

The opaque things that you mention correspond to state changes in TLS. I
am not sure that accessing those correspond to a "middlebox" mentality.
In fact, as we were learning about these problems, I have been working
with Kazuho to get the appropriate API exposed in Picotls. Such as API
to export the 0-RTT secrets when ready, expose change of state after
handshake message, or provide access to session tickets. The TLS Mapping
draft presents some of that, but not quite all of it. For example, there
is not much in that draft about the interaction between TLS-HRR and QUIC
Handshake/Stateless Retry. I must say it is partly my fault -- I have
worked a lot on the transport draft, not so much on the TLS mapping.

But let's come back to the string of bytes model of stream 0. One
downside of it is that it obscures the state transitions. For example,
the sequence of stream zero bytes could well contain the server's second
flight and some other message, such as a dummy change_cipher_spec record
in compatibility mode. Since the transport only sees a stream of bytes,
it has to submit a blob of bytes to TLS, and find out that a transition
is happening in the middle of the blob.

The other downside, as you note, is the interaction with
acknowledgements. For example, the Server Hello is an implicit
acknowledgement of the Client Hello. The Client's Finished is an
implicit acknowledgement of the Server's second flight. But this is
hidden from the transport machinery. So yes, maybe we should think of an
alternative framing for TLS messages. But let's not throw out the baby
with the bath water...

-- Christian Huitema

---

From: Victor Vasiliev <[email-masked]>
Date: Tue, 6 Mar 2018 13:21:44 -0500

> I'd like to discuss refactoring things to run QUIC over DTLS.

Hi Ekr,

Thanks for sending out the proposal!

I appreciate the idea of using DTLS, but I'm afraid it just makes things
worse.  Comments inline.

DETAILS
>     encrypted after the handshake completes, and you still need

I am not sure where the complexity comes from?  If anything, not closing
the stream seems easier than closing it.

>     handling to avoid accidentally encrypting them.

Agreed, you have to handle retransmission of encrypted and handshake data
differently.

>     goes into negative credit after the handshake completes.

Again, we can close stream 0 -- I am not entirely sure what's the cost
you're concerned about here, though.

>     packets, as both cleartext and ciphertext ACKs are possible.

I can see the complexity here, but I don't think there are that many issues
with it -- if anything, this sounds like a reason to simplify the ACK rules.

>     stack, especially in terms of knowing where you are in the

I'm slightly confused here -- by crypto stack, you mean TLS or the crypto
framing state machine?

> case, the result was considerable simplification.

I think this is actually making layering worse than in current
situation.  See this diagram:
http://web.mit.edu/vasilvv/www/quic-tls-layerings.png

The proposed tradeoff is that we get rid of the complexity of having to
deal with both encrypted and unencrypted packets, but as a result we
have to implement two transport stacks -- one inside the TLS library and
one inside the QUIC library.  Having one transport stack is painful
enough.  In practice, DTLS handshake transport mechanisms are always
less polished than commonly used transport stacks.

The layering will still be ugly and leaky, just in different ways -- for
example, you'd have to export the RTT information from your DTLS stack
to your QUIC stack.

It might be interesting to play around with idea of whether we can
actually make unencrypted and encrypted part behave as "two connections
in one" -- i.e.  a cleaner way to reuse the QUIC transport logic while
avoiding painful cross-interactions between them.

> still fighting with, so on balance I believe we can keep the schedule

Agreed that we should discuss the merits of the proposal before talking
about the schedule.  That said.  If this miraculously solves all of our
problems, we should definitely go for it; if this kinda-sorta solves
some of the problems we've already worked through while introducing a
whole host of new yet-untackled problems, I am much more skeptical.

> priorities in the context of the pros and cons of the proposal.

Is there that much of implementation and deployment experience with DTLS
1.3?

---

From: Subodh Iyengar <[email-masked]>
Date: Tue, 6 Mar 2018 18:30:14 +0000

Roberto:
 > I think we achieve better clarity at little to no cost by treating these transport-level control data as something 100% decoupled from the application-layer data, i.e. not a stream.

Calling the crypto stream a stream 0 makes implementors naturally assume that the protocol is messy and intertwined, however that is not true in practice. Practically as we've implemented iQUIC, we've realized that crypto streams are special and dealt with as special cases in an implementation and they don't need to be stream 0. Calling the crypto stream as just another reliably delivered frame in the transport with a very similar structure to streams would be one way to signal to implementors that this is a fundamentally different thing to a stream and make the layering structure align better with implementations.

I think the problem of matching the state of the crypto stream and the packetization format will exist in any crypto core layer, DTLS or TLS encryption if we are not willing to give up
1. flexibility of future versions as Mike put it.
 2. The ability for load balancers and implementations to have a cheap way to check the beginning of the connection

 The implementation complexity is a solvable problem, but I think the question here I have is does the editorial representation of the protocol in terms of layering match up with the practical layering of implementations, which I believe is not the case. A few minor changes to the drafts and the protocol might make it match up better.

Subodh

________________________________
From: QUIC <[email-masked]> on behalf of Victor Vasiliev <vasilvv=[email-masked]>
Sent: Tuesday, March 6, 2018 10:21:44 AM
To: Eric Rescorla
Cc: IETF QUIC WG
Subject: Re: Proposal: Run QUIC over DTLS

On Mon, Mar 5, 2018 at 6:05 PM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
Hi folks,

TL;DR.

Hi Ekr,

I appreciate the idea of using DTLS, but I'm afraid it just makes things worse.  Comments inline.

DETAILS

I am not sure where the complexity comes from?  If anything, not closing the stream seems easier than closing it.

Agreed, you have to handle retransmission of encrypted and handshake data differently.

Again, we can close stream 0 -- I am not entirely sure what's the cost you're concerned about here, though.

I can see the complexity here, but I don't think there are that many issues with it -- if anything, this sounds like a reason to simplify the ACK rules.

I'm slightly confused here -- by crypto stack, you mean TLS or the crypto framing state machine?

I have a draft for this at:
https://datatracker.ietf.org/doc/draft-rescorla-quic-over-dtls/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Drescorla-2Dquic-2Dover-2Ddtls_&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=qTLb7WZOpBzztfssU3e2xdlU4nd_bhinyVlMWJV5Dws&s=Df7smC7xTfm6UnDMoyScL37nx8Dki8ZMWF86rSonZcs&e=>

I think this is actually making layering worse than in current
situation.  See this diagram:
http://web.mit.edu/vasilvv/www/quic-tls-layerings.png<https://urldefense.proofpoint.com/v2/url?u=http-3A__web.mit.edu_vasilvv_www_quic-2Dtls-2Dlayerings.png&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=qTLb7WZOpBzztfssU3e2xdlU4nd_bhinyVlMWJV5Dws&s=zkhogiamsiPqdH1JYMiRpB3tpWCa3qy9o61Pb6gmLek&e=>

Is there that much of implementation and deployment experience with DTLS 1.3?

---

From: Subodh Iyengar <[email-masked]>
Date: Tue, 6 Mar 2018 18:30:14 +0000

Subodh

TL;DR.

Hi Ekr,

DETAILS

---

From: Ted Hardie <[email-masked]>
Date: Tue, 6 Mar 2018 15:25:54 -0800

Howdy,

I've now had a chance to read the document, and I think you have identified
a legitimate pain point with the treatment of stream 0.  At the very, least
renaming it so that the differences between its behavior and other streams
are less surprising seems warranted.  Like Christian, I would also be
interested in seeing the PR you sketch out below.

I think, however, that the proposal to re-layer on top of DTLS should be
dropped.  I am even, frankly, reluctant to see a presentation of it at IETF
101, since I suspect the 20 minutes will eat a good bit more mental time
than that.

I have two basic reasons for that, similar to those put forward by others.
The first is that this will require additional time and coordination.  DTLS
has some modest changes to do, and there are some not-at-all modest changes
to both specification and code required on the QUIC side.  Though your
proposal is complete enough to give a good idea of what to expect, there is
enough to nail down (like carrying the transport parameters) that it will
take multiple cycles of discussion and testing to go from here back to
where we are in terms of implementations interoperating.  While your
proposal may well reduce implementation complexity, I didn't see any
user-impacting feature that was gained (and if I missed it, my apologies).
"Done" is a user-impacting feature.  Without a balancing user-impacting
feature, the delay for relayering doesn't seem to be at the right place in
the hierarchy of concerns.

The second reason relates to WebRTC.  As you note, there is interest on the
WebRTC side in adopting QUIC and relayering would make the current version
of the data channel (SCTP over DTLS) easy to run side-by-side with a later
QUIC over DTLS.  While I agree, I think the appetite for change in WebRTC
is a bit larger and that it includes potentially running the media over a
version of QUIC that supports partial reliability and multipath.  I
believe, as a result, that having a full-on effort that tackles WebRTC over
QUIC may result in some trade-off choices that we will not make correctly
if we tackle only the data channel parallel now.  If we try to do it all
together (Transport, HTTP and WebRTC), I suspect the delay will simply push
this into a downward spiral of attention and effort.

My last reason is not so basic, because it is a concern about
ossification.  You noted in your message to the list:

    We are designing a protocol that will be used long into the future, so
    having the right architecture is especially important.

While we hope that the protocol will be useful long into the future, we are
also trying to demonstrate that building a new transport on top of UDP can
be done and deployed widely.  That should open up the possibility of
deploying more as time goes on.  If we get caught up trying to make this
version perfect because we believe it is our last chance, we may find
ourselves with the deployment timeline of v6 instead of gQUIC.

I do appreciate your making the effort to consider this in a different
layering and your presenting the results to the working group.  I think the
effort will improve the handshake and the treatment of stream 0, but I
personally believe it should do so within the framework we have already
laid out.

thanks,

Ted

---

From: Martin Duke <[email-masked]>
Date: Tue, 6 Mar 2018 15:44:59 -0800

I like the QUIC-over-DTLS architecture, and if it had come out a year ago,
I might have been a supporter. However, I think the idea that we could
possibly stay on schedule with this change is a fantasy.

1. For all its problems, the QUIC handshake is one thing that pretty much
all the implementations have working. We've overcome the design inelegance,
and would now have to redo the handshake without really reducing
implementation time going forward, with the possible exception of not
needing to handle key phase.

2. DTLS 1.3 is apparently less mature, as a standard, than TLS1.3, and even
less so if we're about to go add a bunch of requirements.

3. In our case, the DTLS 1.3 implementation is much earlier in its roadmap
than TLS1.3, which is being driven by TCP use cases. I can't even guess
when I would have a conforming DTLS implementation, and I suspect I'm not
the only one. It's great that picotls is willing to move fast, but many of
us have other constraints.

4. Personally, I take a somewhat dim view of the mucking around we've done
with the public header since GQUIC in the name of privacy. However, the
group as a whole clearly wants to have that discussion, and
administratively it will be hard for the same participants to have these
arguments in TLSWG instead.

I'm not married to any particular schedule for QUIC, so if the benefits are
worth the schedule delay that's OK with me. But we should acknowledge the
schedule delay will be significant.

On Tue, Mar 6, 2018 at 3:25 PM, Ted Hardie <[email-masked]> wrote:

> Howdy,
>
> I've now had a chance to read the document, and I think you have
> identified a legitimate pain point with the treatment of stream 0.  At the
> very, least renaming it so that the differences between its behavior and
> other streams are less surprising seems warranted.  Like Christian, I would
> also be interested in seeing the PR you sketch out below.
>
> I have two basic reasons for that, similar to those put forward by
> others.  The first is that this will require additional time and
> coordination.  DTLS has some modest changes to do, and there are some
> not-at-all modest changes to both specification and code required on the
> QUIC side.  Though your proposal is complete enough to give a good idea of
> what to expect, there is enough to nail down (like carrying the transport
> parameters) that it will take multiple cycles of discussion and testing to
> go from here back to where we are in terms of implementations
> interoperating.  While your proposal may well reduce implementation
> complexity, I didn't see any user-impacting feature that was gained (and if
> I missed it, my apologies).  "Done" is a user-impacting feature.  Without a
> balancing user-impacting feature, the delay for relayering doesn't seem to
> be at the right place in the hierarchy of concerns.
>
> The second reason relates to WebRTC.  As you note, there is interest on
> the WebRTC side in adopting QUIC and relayering would make the current
> version of the data channel (SCTP over DTLS) easy to run side-by-side with
> a later QUIC over DTLS.  While I agree, I think the appetite for change in
> WebRTC is a bit larger and that it includes potentially running the media
> over a version of QUIC that supports partial reliability and multipath.  I
> While we hope that the protocol will be useful long into the future, we
> are also trying to demonstrate that building a new transport on top of UDP
> can be done and deployed widely.  That should open up the possibility of
>> draft directly into the current draft if we so wanted. It's just that it's

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 6 Mar 2018 22:14:25 -0600

I am apparently even slower than Ted at reading the document and the
discussion so far, but I largely agree with his conclusions (and there
is of course a lot of overlap with other opinions expressed thus far).

The draft does do a good job of pointing out some flaws in the current
setup, especially relating to "stream 0", but also the version
negotiation roughness (which, to be fair, we've mentioned occasionally
already).

While we do retain the ability to change the DTLS header format (well,
we think we do) in ways that TLS has ossified, as others have pointed
out, we don't actually have as much data about that as we do for QUIC,
and I also think part of the appeal of QUIC to me is that we would not
be starting from something with as much baggage as (D)TLS and could
really shake things up.  Likewise for QUIC-as-transport vs.
DTLS-as-transport, this feels like a step backwards in terms of innovation.

These are definitely interesting ideas to think about, and I expect the
issues raised here to improve the work we end up with, but I'm worried
that redoing the layering like this would make it nearly impossible to
meet our timeline goals.

-Ben

On 03/06/2018 05:25 PM, Ted Hardie wrote:
> identified a legitimate pain point with the treatment of stream 0.  At
> the very, least renaming it so that the differences between its
> behavior and other streams are less surprising seems warranted.  Like
> Christian, I would also be interested in seeing the PR you sketch out
> below.
>
> I think, however, that the proposal to re-layer on top of DTLS should
> be dropped.  I am even, frankly, reluctant to see a presentation of it
> at IETF 101, since I suspect the 20 minutes will eat a good bit more
> mental time than that. 
>
> not-at-all modest changes to both specification and code required on
> the QUIC side.  Though your proposal is complete enough to give a good
> idea of what to expect, there is enough to nail down (like carrying
> the transport parameters) that it will take multiple cycles of
> discussion and testing to go from here back to where we are in terms
> of implementations interoperating.  While your proposal may well
> reduce implementation complexity, I didn't see any user-impacting
> feature that was gained (and if I missed it, my apologies).  "Done" is
> a user-impacting feature.  Without a balancing user-impacting feature,
> the delay for relayering doesn't seem to be at the right place in the
> hierarchy of concerns.
>
> The second reason relates to WebRTC.  As you note, there is interest
> on the WebRTC side in adopting QUIC and relayering would make the
> current version of the data channel (SCTP over DTLS) easy to run
> side-by-side with a later QUIC over DTLS.  While I agree, I think the
> appetite for change in WebRTC is a bit larger and that it includes
> potentially running the media over a version of QUIC that supports
> partial reliability and multipath.  I believe, as a result, that
> having a full-on effort that tackles WebRTC over QUIC may result in
> some trade-off choices that we will not make correctly if we tackle
> only the data channel parallel now.  If we try to do it all together
> (Transport, HTTP and WebRTC), I suspect the delay will simply push
> While we hope that the protocol will be useful long into the future,
> we are also trying to demonstrate that building a new transport on top
> of UDP can be done and deployed widely.  That should open up the
> possibility of deploying more as time goes on.  If we get caught up
> trying to make this version perfect because we believe it is our last
> chance, we may find ourselves with the deployment timeline of v6
> instead of gQUIC.
>
> layering and your presenting the results to the working group.  I
> think the effort will improve the handshake and the treatment of
> stream 0, but I personally believe it should do so within the
> framework we have already laid out.
>
> thanks,
>
> Ted
>
> On Tue, Mar 6, 2018 at 7:12 AM, Eric Rescorla <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     FWIW it is possible to move the style of version negotiation from
>     my draft directly into the current draft if we so wanted. It's
>     just that it's necessary if QUIC is at the bottom of the stack and
>     so is a nice extra win.
>
>     Specifically, we would have the version in the long header In
>     Initial refer not to the QUIC version we want to negotiate but
>     rather to the version whose obfuscation method we are using
>     (probably the client's minimum). The CH would then have an
>     extension which contained the QUIC versions we support (as in
>     TLS.supported_versions) and then the SH would contain both
>     selected versions. We could have the remaining obfuscated long
>     header packets could use *either* obfuscation version. The
>     encrypted long header packets would of course use the negotiated
>     versions.
>
>     A few notes:
>
>     - The CH always comes in one packet so that you don't have to
>     worry about it being immediately available to the server
>     As with my draft, this would give you 1-RTT negotiation if the
>     client obfuscated with a version the server knew and 2-RTT if the
>     client obfuscated with a version the server didn't know, as
>     opposed to always having 2-RTT
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 6 Mar 2018 23:35:09 -0500

It seems to me that it would be a good plan to use DTLS framing after the
initial handshake is complete.

Right now it seems that QUIC has got rather complicated and factoring out
the crypto part from the transport part seems like it would aid clarity.

Simplifying the design is always worth it in my view.

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Wed, 7 Mar 2018 12:53:29 +0100

tl;dr: what Ted said, plus what Lars said.

Relayering QUIC on top of DTLS seems to me to be an interesting version 2 exercise. At this point, it's definitely worth investigating how QUIC invariants and VN can be made compatible with an "upgrade" during VN to a QUIC layered over DTLS, but I think it's too late to make this change for V1.

Cheers,

Brian

> On 7 Mar 2018, at 00:25, Ted Hardie <[email-masked]> wrote:
> 
> Howdy,
> 
> I've now had a chance to read the document, and I think you have identified a legitimate pain point with the treatment of stream 0.  At the very, least renaming it so that the differences between its behavior and other streams are less surprising seems warranted.  Like Christian, I would also be interested in seeing the PR you sketch out below.
> 
> I think, however, that the proposal to re-layer on top of DTLS should be dropped.  I am even, frankly, reluctant to see a presentation of it at IETF 101, since I suspect the 20 minutes will eat a good bit more mental time than that.
> 
> I have two basic reasons for that, similar to those put forward by others.  The first is that this will require additional time and coordination.  DTLS has some modest changes to do, and there are some not-at-all modest changes to both specification and code required on the QUIC side.  Though your proposal is complete enough to give a good idea of what to expect, there is enough to nail down (like carrying the transport parameters) that it will take multiple cycles of discussion and testing to go from here back to where we are in terms of implementations interoperating.  While your proposal may well reduce implementation complexity, I didn't see any user-impacting feature that was gained (and if I missed it, my apologies).  "Done" is a user-impacting feature.  Without a balancing user-impacting feature, the delay for relayering doesn't seem to be at the right place in the hierarchy of concerns.
> 
> The second reason relates to WebRTC.  As you note, there is interest on the WebRTC side in adopting QUIC and relayering would make the current version of the data channel (SCTP over DTLS) easy to run side-by-side with a later QUIC over DTLS.  While I agree, I think the appetite for change in WebRTC is a bit larger and that it includes potentially running the media over a version of QUIC that supports partial reliability and multipath.  I believe, as a result, that having a full-on effort that tackles WebRTC over QUIC may result in some trade-off choices that we will not make correctly if we tackle only the data channel parallel now.  If we try to do it all together (Transport, HTTP and WebRTC), I suspect the delay will simply push this into a downward spiral of attention and effort.
> 
> My last reason is not so basic, because it is a concern about ossification.  You noted in your message to the list:
> 
> While we hope that the protocol will be useful long into the future, we are also trying to demonstrate that building a new transport on top of UDP can be done and deployed widely.  That should open up the possibility of deploying more as time goes on.  If we get caught up trying to make this version perfect because we believe it is our last chance, we may find ourselves with the deployment timeline of v6 instead of gQUIC.
> 
> I do appreciate your making the effort to consider this in a different layering and your presenting the results to the working group.  I think the effort will improve the handshake and the treatment of stream 0, but I personally believe it should do so within the framework we have already laid out.
> 
> thanks,
> 
> Ted
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 7 Mar 2018 12:35:58 +0000

This is an interesting case where the group needs to decide whether it wants to publish something quicker or go for an architecturally cleaner design. I has often been argued that the IETF tries to aim for the best possible quality rather than trying to meet deadlines. In fact that has been expressed in the past as a criticism towards other organizations, like the 3GPP, who were very tough when it comes to deadlines.

It will be interesting to see how this plays out in the end. In any case, it will definitely be an interesting case to cite in the future.

Ciao
Hannes

From: QUIC [mailto:[email-masked]] On Behalf Of Benjamin Kaduk
Sent: 07 March 2018 05:14
To: Eric Rescorla
Cc: [email-masked]
Subject: Re: Proposal: Run QUIC over DTLS

I am apparently even slower than Ted at reading the document and the discussion so far, but I largely agree with his conclusions (and there is of course a lot of overlap with other opinions expressed thus far).

The draft does do a good job of pointing out some flaws in the current setup, especially relating to "stream 0", but also the version negotiation roughness (which, to be fair, we've mentioned occasionally already).

While we do retain the ability to change the DTLS header format (well, we think we do) in ways that TLS has ossified, as others have pointed out, we don't actually have as much data about that as we do for QUIC, and I also think part of the appeal of QUIC to me is that we would not be starting from something with as much baggage as (D)TLS and could really shake things up.  Likewise for QUIC-as-transport vs. DTLS-as-transport, this feels like a step backwards in terms of innovation.

These are definitely interesting ideas to think about, and I expect the issues raised here to improve the work we end up with, but I'm worried that redoing the layering like this would make it nearly impossible to meet our timeline goals.

-Ben

On Tue, Mar 6, 2018 at 7:12 AM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
FWIW it is possible to move the style of version negotiation from my draft directly into the current draft if we so wanted. It's just that it's necessary if QUIC is at the bottom of the stack and so is a nice extra win.

A few notes:

-Ekr

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 7 Mar 2018 12:35:58 +0000

Ciao
Hannes

-Ben

A few notes:

-Ekr

---

From: Christopher Wood <[email-masked]>
Date: Wed, 7 Mar 2018 12:50:30 -0500

> Relayering QUIC on top of DTLS seems to me to be an interesting version 2 exercise. At this point, it's definitely worth investigating how QUIC invariants and VN can be made compatible with an "upg…

Yes, it may be too late. However, if we can experiment early without
risk of impacting the current trajectory or London hackathon plans, I
would like to do so.

Best,
Chris

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Wed, 7 Mar 2018 18:52:26 +0100

> On 7 Mar 2018, at 18:50, Christopher Wood <[email-masked]> wrote:
> 

...plus what Chris said.

cheers,

Brian

---

From: Leif Hedstrom <[email-masked]>
Date: Wed, 7 Mar 2018 10:21:28 -0800

> On Mar 6, 2018, at 3:44 PM, Martin Duke <[email-masked]> wrote:
> 
> I like the QUIC-over-DTLS architecture, and if it had come out a year ago, I might have been a supporter. However, I think the idea that we could possibly stay on schedule with this change is a fantasy.
> 
> 1. For all its problems, the QUIC handshake is one thing that pretty much all the implementations have working. We've overcome the design inelegance, and would now have to redo the handshake without really reducing implementation time going forward, with the possible exception of not needing to handle key phase.
> 
> 2. DTLS 1.3 is apparently less mature, as a standard, than TLS1.3, and even less so if we're about to go add a bunch of requirements.

This was my initial reaction as well. TLS v1.3 being such a moving target for the last ~12 months has been one of the biggest challenges to QUIC interop / development. I don’t know what state the various TLS implementations are for DTLS v1.3, but I’d be concerned that we start that circus up all over again.

I think assessing the state of DTLS v1.3 specifications and implementations is critical before making a technical decision. [I’m saying this with very little knowledge of the DTLS v1.3 world :-].

Cheers,

— Leif

---

From: Gabriel Montenegro <[email-masked]>
Date: Fri, 9 Mar 2018 17:24:13 +0000

Folks,

Thanks Ekr for the proposal, it is interesting and it would have been different to see it, say, a year ago.

But now, I wouldn’t want to layer over DTLS. I discussed this with people involved in the QUIC effort at Microsoft and they came to similar conclusions

I agree with others that this is too late in the process, and would not want to throw away all the interop efforts and progress with the bathwater, which would represent a significant slip in the schedule, as would the fact that dTLS 1.3 is not as mature as TLS 1.3.

The point about having only one transport is important, as is the point about not augmenting the invariants with a given handshake flavor.

My preferred approach would be to—at most—take some ideas and incorporate into the current QUIC framework, so I’m  looking forward to the version negotiation modeled after the QUIC-over-dtls proposal.

Another interesting result of this discussion is Subodh’s suggestion to clarify the interfaces between subsystems (“layering structure”): QUIC transport and packetization vs crypto on stream 0 vs UDP. 

Thanks,

Gabriel

> From: QUIC <[email-masked]> On Behalf Of Leif Hedstrom
> Sent: 7 March, 2018 10:21
> To: Martin Duke <[email-masked]>
> Cc: Ted Hardie <[email-masked]>; [email-masked]; Eric Rescorla
> <[email-masked]>
> > I like the QUIC-over-DTLS architecture, and if it had come out a year ago, I
> might have been a supporter. However, I think the idea that we could possibly
> stay on schedule with this change is a fantasy.
> >
> > 1. For all its problems, the QUIC handshake is one thing that pretty much all
> the implementations have working. We've overcome the design inelegance,
> implementation time going forward, with the possible exception of not needing
> to handle key phase.
> >
> This was my initial reaction as well. TLS v1.3 being such a moving target for the
> last ~12 months has been one of the biggest challenges to QUIC interop /
> development. I don’t know what state the various TLS implementations are for
> DTLS v1.3, but I’d be concerned that we start that circus up all over again.
> 
> I think assessing the state of DTLS v1.3 specifications and implementations is
> critical before making a technical decision. [I’m saying this with very little
> knowledge of the DTLS v1.3 world :-].
> 
> Cheers,
> 
> — Leif

---

From: Christian Huitema <[email-masked]>
Date: Fri, 9 Mar 2018 09:42:36 -0800

> Another interesting result of this discussion is Subodh’s suggestion to clarify the interfaces between subsystems (“layering structure”): QUIC transport and packetization vs crypto on stream 0 vs U…

In fact, the current QUIC design is a good example of the evolution in
protocol architecture from "layering" to "functional decomposition". The
layering approach, as popularized by the OSI model, consider the system
as a set of filters layered on top of each other. It is a powerful
approach, but it has limitations. The biggest limitation is tied to the
design principle: each layer obscures the view of the other layers; to
mitigate that, the layer API needs a set of pass-through functions, such
as for example passing a setsockopt to TCP across TLS.

In contrast, functional decomposition looks at big functions such as
reliability, forward error correction, real time delivery, and arranges
the protocol as an assembly of these functions. This is very much the
direction pointed to by TAPS. In the case of QUIC, the relation with TLS
is an example of such functional decomposition, treating TLS as a black
box that negotiates keys.

We can certainly agree that the stream zero approach is not ideal. It
may very well be that a set of TLS oriented frame types would be much
cleaner. But in my mind a strict layering approach on top of DTLS would
not be architecturally cleaner. I believe that it would be a step backward.

-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Fri, 9 Mar 2018 09:42:36 -0800

-- Christian Huitema

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 13 Mar 2018 09:52:47 -0700

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.

---

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 13 Mar 2018 19:30:20 +0100

Hi Mark,

coming back to this initial mail, I believe that it is clear that people 
are interested in the problem(s) that this proposal is addressing but 
not the actually solution as there is a strong feeling that it is too 
late for such a fundamental change in the process.

I just looked at the draft agenda and it (still) say "QUIC over DTLS 
Proposal". Is there a plan to change this and level this up to a more 
higher level discussion on the problems or do people still want to use 
the time to discuss this concrete proposal?

Mirja

---

From: Ted Hardie <[email-masked]>
Date: Tue, 13 Mar 2018 12:20:11 -0700

Hi Eric,

As it stands, you've identified a pain point, and you've made a proposal
to  rebase a key part of the architecture on the basis of that pain.

Folks agree with you that it is a pain point, but all of the feedback
you're getting that this isn't worth the schedule slip is, fundamentally,
also feedback on how bad the pain is.  The message I read (and, to be fair,
participated in sending) from this thread is "not bad enough for this".
It's clearly bad enough that Christian, I, and I'm sure others would like
you to create a PR to incorporate what improvements from your proposal can
fit into the current structure.   If that's the conversation you want to
have, I'm happy to jump in.

But I don't think we can ignore the signal that the current state of
affairs actually works and that changing away from it so completely isn't
worth the (new) pain.  I think we will lose both momentum and expertise if
we start over to this extent at this juncture, and I'd rather we did not.
I'm particularly worried that the uncertainty around this could kill the
productivity of the hackathon and London meeting, and that we won't recover
until the next interim, if then.

Not talking about that as we analyze this seems to me to be the wrong
choice.

regards,

Ted
/no hats

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 13 Mar 2018 15:50:48 -0700

Hi Ted,

I appreciate your concern with the schedule, and I do recognize that
there are people who think that this is too late to discuss, but I
also heard people who thought it was worth exploring, which is what
I'm asking for at the moment.

Even if I were to concede that that were not the case -- which I don't
-- it's not possible to have a discussion about what we can do to
address these issues without understanding the architectural
principles we are trying to follow, which requires actually discussing
the points I raised above.

-Ekr

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Tue, 13 Mar 2018 16:01:10 -0700

below

On 13 March 2018 at 17.53.40, Eric Rescorla ([email-masked]) wrote:

real transport.

Actually, I am bothered. I think it is fine and necessary to use UDP, but I
really would like to see

the protocol be defined as independent of the lower layers as possible.
Endpoint chosen CID’s is

a move in that direction, but tuple specific routing is not, and preferred
IP in transport is also not

(useful as it may be). Incidentally, moving some concerns to a lower layer
can help with that iff that

part can be opted out or replaced easily, but not if it means added
dependencies that are impossible

or impractical to evade.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 13 Mar 2018 16:03:11 -0700

> the points I raised above.

It appears that I wasn't clear; sorry.  I am fine with continuing to
discuss the architectural points, but I don't want to do so by putting
aside discussion of the schedule.  Your note said that you felt it wasn't
productive to discuss the schedule impact while discussing the
architectural issues, and it was that point I disagree with it.

As I said earlier on, I don't want QUIC to be the last turn of the crank
for producing new transport protocols, and determining what lessons we
ought to learn for the next turn is always valuable, even if we choose to
make more modest changes in this effort.

I hope this clarifies my intent,

regards,

Ted

---

From: Brian Trammell (IETF) <[email-masked]>
Date: Wed, 14 Mar 2018 07:31:58 +0100

hi ekr,

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

> On 13 Mar 2018, at 17:52, Eric Rescorla <[email-masked]> wrote:
> 
> Hi folks,
> 

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

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Wed, 14 Mar 2018 09:53:12 +0100

Hi,

> On 14. Mar 2018, at 07:31, Brian Trammell (IETF) <[email-masked]> wrote:
> 
> hi ekr,
> 

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…

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 14 Mar 2018 10:32:07 +0000

At this point, I think we will still benefit from having some face-to-face time devoted to this these issues, even if many people feel we shouldn't take the DTLS proposal wholesale. 

Having said that, the recent re-statement of the issues as 1) stream 0 and 2) the layering question seems most appropriate. EKR, can you make sure your presentation focuses on them, with DTLS as one possible solution? I'll adjust the title in the agenda accordingly.

Cheers,

> On 13 Mar 2018, at 6:30 pm, Mirja Kühlewind <[email-masked]> wrote:
> 
> Hi Mark,
> 
> coming back to this initial mail, I believe that it is clear that people are interested in the problem(s) that this proposal is addressing but not the actually solution as there is a strong feeling that it is too late for such a fundamental change in the process.
> 
> I just looked at the draft agenda and it (still) say "QUIC over DTLS Proposal". Is there a plan to change this and level this up to a more higher level discussion on the problems or do people still want to use the time to discuss this concrete proposal?
> 
> Mirja
> 
> 
> <mirja_kuehlewind.vcf>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 14 Mar 2018 06:46:18 -0700

On Wed, Mar 14, 2018 at 3:32 AM, Mark Nottingham <[email-masked]> wrote:

> At this point, I think we will still benefit from having some face-to-face
> time devoted to this these issues, even if many people feel we shouldn't
> take the DTLS proposal wholesale.
>
> Having said that, the recent re-statement of the issues as 1) stream 0 and
> 2) the layering question seems most appropriate. EKR, can you make sure
> your presentation focuses on them, with DTLS as one possible solution? I'll
> adjust the title in the agenda accordingly.
>

Willdo. This is consistent with how I was intending to present this.

Thanks,
-Ekr

> are interested in the problem(s) that this proposal is addressing but not
> the actually solution as there is a strong feeling that it is too late for
> such a fundamental change in the process.
> >
> higher level discussion on the problems or do people still want to use the
> time to discuss this concrete proposal?
> >
> > Mirja
> >
> >
> >> I know folks need a chance to read and digest, but it would be
> extremely helpful if we could have some initial discussion on-list now.
> Please focus on the technical merit of the proposal, clarifying questions,
> and statements of support/lack thereof.
> >> Assuming it's still a topic of interest in two weeks, we'll schedule
> some time to discuss it in London. EKR, could you please submit a
> presentation (say, max 20 minutes, plus discussion time afterwards) ASAP?
> >> Cheers,