Subject: Grease the packet type?

From: Martin Duke <[email-masked]>
Date: Mon, 10 Jan 2022 15:23:39 -0800

This issue hasn't gotten much attention in QUICv2:
https://github.com/quicwg/quic-v2/issues/7

Basically, we could simply reassign the packet type codepoints in v2 to so
that Initials are a codepoint other than 0b00.

For example:
Initial = 0b01
0-RTT = 0b10
Handshake = 0b11
Retry = 0b00

To the extent the purpose of v2 is grease stuff, this seems like a pretty
simple and good thing to do. To the extent it's supposed to exercise
version negotiation, this change is a needless distraction.

Does the WG think this is worthwhile? I hope to issue the next draft with
the provisional version number allocation, so this is the right time to
make this sort of change.

Martin

---

From: David Schinazi <[email-masked]>
Date: Mon, 10 Jan 2022 15:39:39 -0800

I like this. It would be easy to implement for us, and might help a little
bit ossification-wise.

David

---

From: Marten Seemann <[email-masked]>
Date: Tue, 11 Jan 2022 09:44:25 +0400

This is a good idea. Should be easy enough to implement.

On Tue, Jan 11, 2022 at 3:40 AM David Schinazi <[email-masked]>
wrote:

>> Basically, we could simply reassign the packet type codepoints in v2 to
>> so that Initials are a codepoint other than 0b00.
>>
>> For example:
>> Initial = 0b01
>> 0-RTT = 0b10
>> Handshake = 0b11
>> Retry = 0b00
>>

---

From: Ryan Hamilton <[email-masked]>
Date: Tue, 11 Jan 2022 07:07:03 -0800

To make sure I'm clear on the proposal, the idea is basically to make the
long header packet type values different for different versions
(specifically v2)? This means that v1 and v2 will not be wire compatible,
right? I'm slightly loath to open up v2 to wire changes because I fear
it'll turn into a honeypot for other attractive chances and may bog down
the release of v2. But I don't feel strongly and the idea seems nice in
general!

---

From: Martin Duke <[email-masked]>
Date: Tue, 11 Jan 2022 07:30:10 -0800

Hi Ryan!

The honeypot issue is a real one -- I've made it pretty clear that this
draft is not doing functional changes to QUIC unless we discover a
vulnerability or a deadlock condition in v1.

But they would still be "compatible" in the sense of the VN draft -- a v1
Initial packet can be translated to a v2 packet with 100% fidelity, and
vice versa. I'm not sure what you mean by "wire compatible", but as all the
keys are derived differently, we are already well past a v1-only endpoint
being able to read v2.

---

From: Ryan Hamilton <[email-masked]>
Date: Tue, 11 Jan 2022 07:52:01 -0800

> vulnerability or a deadlock condition in v1.

Woo hoo! :) That definitely seems like the right goal.

> keys are derived differently, we are already well past a v1-only endpoint

Fair point! What I meant was that a simple version alias will not quite be
sufficient here. An implement which already supports, say, v1 and draft-29
will need to write new code to handle this new packet type logic. (Of
course, this is not much code). It won't, however, be able to simply add an
entry to an existing data structure which associates salts with versions.

That being said, this is a minor point. As long as we're all focused on
getting v2 out with minimal change then hopefully this won't actually open
up Pandora's box.

Cheers,

Ryan