Subject: [quicwg/base-drafts] Tweak the split between quic-transport and quic-tls drafts (#3717)

From: David Schinazi <[email-masked]>
Date: Wed, 03 Jun 2020 17:38:24 -0700

Now that the drafts are not changing as much as they used to, it might be the right time to consider editorial efforts such as revisiting the current split between quic-transport and quic-tls. Let's imagine that once the RFCs ship, someone wants to build a version of QUIC with a custom handshake/key exchange protocol - they want to deviate as little as possible from QUICv1, but just want to swap TLS out for something else. Ideally, they would write a new draft that replaces quic-tls, and not change quic-transport at all. And in order to implement this, readers would not need to read quic-tls.

More specifically, I think we could accomplish this by moving the following sections from quic-tls to quic-transport:
* 5  Packet Protection (except 5.1 Packet Protection Keys)
* 6  Key Update (the interaction with the TLS key schedule would stay in quic-tls but the mechanisms to avoid deadlocks when discarding keys would move to quic-transport)
* 7  Security of Initial Messages

What do folks think? I could write up a PR to help make this happen but I'd like to get a sense of whether there's interest first.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3717

---

From: ianswett <[email-masked]>
Date: Thu, 04 Jun 2020 12:04:43 -0700

I like this direction.  Even if no one ever makes a non-TLS version, I think the document clarity could improve with a change like this.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3717#issuecomment-639057914

---

From: Christopher Wood <[email-masked]>
Date: Thu, 04 Jun 2020 12:46:02 -0700

Heavy +1 -- one of the goals of nQUIC [1] was to exercise the separation between these two drafts. At the time, there was more coupling than desired. Things are in much better shape now. 

[1] https://eprint.iacr.org/2019/028.pdf

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3717#issuecomment-639077155

---

From: Mike Bishop <[email-masked]>
Date: Fri, 05 Jun 2020 09:05:06 -0700

I'm supportive of that direction.  There was, at one point, an attempt to document the properties that would have to be provided by a generic handshake protocol.  The decision to make the transport-spec version-specific and make versions handshake-protocol-specific means we don't *need* that text, but an equivalent section noting specifically what features are delegated to and expected of TLS would still be useful.

However, I will say that I don't think this rearrangement needs to or should delay the drafts or WGLC.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3717#issuecomment-639597578

---

From: ianswett <[email-masked]>
Date: Mon, 08 Jun 2020 12:15:58 -0700

+1 to this being editorial and not delaying WGLC

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3717#issuecomment-640819832

---

From: David Schinazi <[email-masked]>
Date: Mon, 08 Jun 2020 12:23:15 -0700

To clarify, my intention was indeed for this to be editorial and to not have it delay any part of the process whatsoever.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3717#issuecomment-640826096