Tweak the split between quic-transport and quic-tls drafts

[DavidSchinazi]

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.

[ianswett]

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.

[chris-wood]

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

[MikeBishop]

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.

[ianswett]

+1 to this being editorial and not delaying WGLC

[DavidSchinazi]

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

[larseggert]

Since @DavidSchinazi volunteered to prepare a PR, please let him know when the working copies are stable enough for this shuffling to happen without much pain.

[huitema]

It would be nice i the PR also addressed the issue #4097 -- section 4 including a long description of which frames belongs in what type of packet, which is better addressed by a reference to the transport draft.

[larseggert]

@DavidSchinazi my take is that we're stable enough at this time, if you still have energy to prep a PR.

[DavidSchinazi]

Thanks @larseggert ! I'll need a few weeks before I get started on this but I still have the energy.

[larseggert]

In that case, maybe someone else can get to it sooner - I still have this unfounded optimism that we can be in IETF LC soon...

[DavidSchinazi]

If there's a time pressure I can increase the priority of this over other work. Do we have a deadline here?

[martinthomson]

As you say, WGLC happened. I know that Jana wants to get some editorial work in after that (small language fixups, maybe a tiny bit of shuffling of content). So this really comes down to one question: When do you want QUIC to be published?

Any time we allow for editorial cleanup adds directly to the time it takes to publish. If WGLC passes this time around with no major issues, then we could immediately publish a -31 draft and make a publication request.

Second is the risk that we invalidate the WGLC when we do any significant amount of editorial work. If we plan another round of calls, then this costs little. If we don't (see above), then this carries some risk of restarting the clock.

I guess you could interpret this as "finish this before September 24 or avoid risky changes". I don't know how realistic either one is.

[MikeBishop]

Looking at what would be entailed, my first instinct was to try slotting it into new subsections of Section 12.1. However, that makes the TOC deeper than is ideal and would probably require more editorial fine-tuning to get right. If you want to pursue this, I think the fastest path to coherency is to make a new top-level section at the end of the document on Packet Protection and just adjust the cross-references to be forward-references there.

Then:

• New text on the values supplied by TLS (packet protection keys, header protection keys, ability to generate new keys on demand) in a subsection of TRANS-7
• Move TLS-5.0 into TRANS-(new).0
• Retain TLS-5.1 and TLS-5.2 in TLS
• Split TLS-5.3, moving the "how to apply selected AEAD and key" into TRANS-(new).1
• Move most of TLS-5.4 through TLS-5.6 into subsections of TRANS-(new), leaving only the key derivation in TLS
• TLS-5.7 should mostly move to a subsection of TRANS-13.1, but some TLS specifics would need to be abstracted out
• TLS-5.8 should move under TRANS-(new)
• TLS-7 should move under TRANS-(new), possibly removing specific references to TLS and discussing tampering with the cryptographic handshake generically.

TLS-6 is trickier. The mechanics of how to perform a key update on the wire need to move, probably to the final subsection of TRANS-(new); the mechanics of how to obtain the new key need to remain in TLS. These aren't currently clearly separated, and might require some additional text to abstract them.

[huitema]

The better is the enemy of the good. I wish we did these changes, because I wish there was no redundancy between the TLS and the transport draft. But then, with the current documents, we did manage to get a large number of implementations that all interoperate. There is a case for leave it as it and ship it now!

[larseggert]

Maybe we need a "hold for revision" status for PRs.

[larseggert]

In any case, I'd like to second @martinthomson's suggestion to get this done by Sep 24. I know that's just a few days away, but this seems to be the last issue that requires significant text changes, and so I hope this is doable.

[DavidSchinazi]

OK I'm starting work on this now. I'll have a first draft of a PR soon

[huitema]

@DavidSchinazi I just pushed PR 4136 (#4136) that solves issue 4097, so you don't have to do that.

[DavidSchinazi]

@huitema I already have that in my PR, so happy to land whichever is ready first and rebase the other.

[DavidSchinazi]

OK I have a first draft at #4138. Reviews welcome!

[martinthomson]

Thanks for doing the work David. I think that there is a path toward taking that PR, but it's a long one and the editors feel like it is more important to publish.