Subject: [quicwg/base-drafts] Long header variants for 1-RTT protected packets (#848)

From: Martin Thomson <[email-masked]>
Date: Mon, 09 Oct 2017 22:08:55 -0700

These should be removed for (at least) two reasons:

Firstly, there should only be one way to do anything, if possible.  This makes it possible to encode the same information two ways.

Perhaps more substantially, because it would make WebRTC easier.  In discussions about using QUIC for WebRTC, we found that there were several options for multiplexing designs that are feasible with QUIC.  One of the most difficult parts of that was ensuring that once the handshake was complete, QUIC packets could be distinguished easily from other packets.  

During the handshake, I think that people are prepared to rely on checksums, and other things, but in the steady state demultiplexing on the first octet would be ideal.   

Right now, the two 1-RTT protected long header encodings collide with RTP and need more sophisticated handling to correctly identify.  Some tweaking of the type field might avoid that, but it could preclude greasing and effectively constrain what we can do with QUIC.  It would be easier to rely on the packets using the short header.  The short header only potentially collides with DTLS (which would not be used in this case) and STUN (which are infrequent enough that they can use the STUN hash or magic number to identify correctly - something Google already do).

@pthatcherg or @aboba can expand on the reasons, or explain some of their alternative designs.

-- 
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/848

---

From: MikkelFJ <[email-masked]>
Date: Tue, 10 Oct 2017 01:34:30 -0700

I has always bothered me that the choice of short/long headers was arbitrary.

-- 
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/848#issuecomment-335401289

---

From: Colin Perkins <[email-masked]>
Date: Tue, 10 Oct 2017 12:25:54 +0000 (UTC)

This is also issue #426 

-- 
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/848#issuecomment-335455520

---

From: ianswett <[email-masked]>
Date: Tue, 10 Oct 2017 12:30:18 +0000 (UTC)

Sounds good, I can't come up with a reason to keep them.

-- 
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/848#issuecomment-335456550

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Oct 2017 23:32:01 +0000 (UTC)

This might help with #426, but maybe not completely.  Short headers still potentially conflict with ZRTP, for example.  I'd keep #426 open even if we resolve 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/848#issuecomment-335637870

---

From: ianswett <[email-masked]>
Date: Tue, 10 Oct 2017 17:06:44 -0700

If we really care about conflicting with WebRTC during the handshake, we have enough long header codepoints to avoid those codepoints in QUIC.  I'd prefer not to avoid codepoints post-handshake, however, since that eliminates the possibility of post-handshake type byte greasing.

-- 
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/848#issuecomment-335643148

---

From: janaiyengar <[email-masked]>
Date: Thu, 12 Oct 2017 20:37:54 +0000 (UTC)

There is a good reason for this to exist: out-of-band key negotiation. I'll remind folks that transport negotiation is distinct from the TLS handshake -- we've taken pains to try and keep TLS separate from QUIC -- and you might have 1-RTT keys available when you are starting your transport connection.

On demuxing WebRTC and QUIC packets, that is a separate conversation. I outlined a couple of ideas in #426 and we could have that conversation separately, although we did agree in Paris that we'd add a framing layer if necessary later and closed the issue. 

-- 
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/848#issuecomment-336258862

---

From: Martin Thomson <[email-masked]>
Date: Thu, 12 Oct 2017 15:43:46 -0700

Why can't the client use the Initial packet for its first packet in that case?  That would ensure that the server can generate a Version Negotiation packet if it needs to.

It's very hard to know what your design is - you seem to assume a particular design, but since we aren't discussing it in any detail, I don't know whether you actually *need* these long-form packets.

-- 
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/848#issuecomment-336298978

---

From: Martin Thomson <[email-masked]>
Date: Thu, 12 Oct 2017 23:03:31 +0000 (UTC)

Oh, I forgot to add: If you really need these, then your out-of-band key negotiation variant of QUIC is welcome to define them.  (Again, assuming that you have a different version number so that this is possible.)

-- 
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/848#issuecomment-336304244

---

From: Martin Thomson <[email-masked]>
Date: Fri, 13 Oct 2017 04:18:32 -0700

Closed #848 via #857.

-- 
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/848#event-1292078436

---

From: janaiyengar <[email-masked]>
Date: Fri, 13 Oct 2017 21:04:29 +0000 (UTC)

Reopened #848.

-- 
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/848#event-1293029952

---

From: janaiyengar <[email-masked]>
Date: Fri, 13 Oct 2017 21:09:37 +0000 (UTC)

Having thought about this some more, it's actually ok to do this. It's not "my variant" of QUIC, it's a general use case that uses out-of-band key exchange. I've tried to explain this in the past. But since  0-RTT and 1-RTT keys can be the same, any such use of QUIC can treat 0-RTT and 1-RTT packets differently except use the same keys for both kinds. Which makes it ok to remove 1-RTT long headers.

Separately, please, please, don't rush to close out design issues in a rush. This was under discussion, and really should have been discussed more before closing.

-- 
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/848#issuecomment-336568100

---

From: janaiyengar <[email-masked]>
Date: Fri, 13 Oct 2017 21:20:57 +0000 (UTC)

We also have a merge-imminent label for exactly things like this. I wasn't expecting the merge to happen without the discussion finishing so I'm quite surprised to see this happen.

-- 
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/848#issuecomment-336570435

---

From: janaiyengar <[email-masked]>
Date: Thu, 26 Oct 2017 12:29:26 -0700

Closed #848.

-- 
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/848#event-1312670078