Subject: Re: [quicwg/base-drafts] handshake and 0rtt data in a single packet (#630)

From: ianswett <[email-masked]>
Date: Thu, 09 Nov 2017 06:09:46 +0000 (UTC)

Coming back around on this, I think we end up needing something like option 4 for a simple reason.  We need the ability to ack the cleartext data and not ack the 0RTT data if 0RTT fails.  So they need different packet numbers, even if they're in the same UDP packet.  At that point, sticking together two QUIC 'packets' in a single UDP packet would seem the obvious approach.

-- 
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/630#issuecomment-343056871

---

From: MikkelFJ <[email-masked]>
Date: Thu, 09 Nov 2017 08:03:37 +0000 (UTC)

I could see multiple long headers in one Packet, but allowing for multiple packets in one MTU affects a lot of machinery.

-- 
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/630#issuecomment-343076522

---

From: ianswett <[email-masked]>
Date: Thu, 09 Nov 2017 21:01:48 +0000 (UTC)

To build on that idea, avoid adding anything new(ie: a length) to the unencrypted public header, and make these packets look as much as possible like other QUIC packets, I propose we:
  * Add 4 frame types which indicate the remaining content is packet_number+1 for the same connection and the encryption level.  The header would be omitted.

In many cases this would mean encryption inside encryption, but I don't think that's a big problem in practice.

Admittedly, getting a framer to frame one of these is a bit of hassle, but it seems potentially useful for the HTTP case, since you may be able to send a request and/or header compression info along with the CHLO.  The CHLO is padded and head of line blocking for the entire connection, so this would be a strict performance win.

-- 
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/630#issuecomment-343290129

---

From: Martin Thomson <[email-masked]>
Date: Thu, 09 Nov 2017 21:16:53 +0000 (UTC)

Encryption in encryption is a non-starter (for all the reasons we've discussed relating to the analysis of TLS, key usage, etc...).

-- 
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/630#issuecomment-343294199

---

From: ianswett <[email-masked]>
Date: Thu, 09 Nov 2017 21:48:18 +0000 (UTC)

To clarify, encrypting something with 0RTT keys inside the handshake AES-GCM is not safe?  Any background about why, or is this a case of what's easy to prove?

-- 
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/630#issuecomment-343302395

---

From: Martin Thomson <[email-masked]>
Date: Thu, 09 Nov 2017 22:15:27 +0000 (UTC)

The analysis of TLS (some analysis, not all), rely on strict separation of proofs.  That means that the handshake is assessed independent of the record layer.  One condition of that proof is that the keys that the handshake produces are never used to protect the handshake.  Otherwise, the proofs get entangled as a result of needing to show that the record layer doesn't abuse the keys in ways that would compromise the record layer.

Actually, maybe this is OK in the sense that the AES-GCM isn't really encryption, or related to the handshake at all.

But the point remains, it's easier to add a length to the long header and pack multiple records in the same datagram (oops, those are DTLS terms, see DTLS for an example of how this works) than to do double encryption.

-- 
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/630#issuecomment-343309522

---

From: ianswett <[email-masked]>
Date: Thu, 09 Nov 2017 23:55:14 +0000 (UTC)

If we restrict this to embedding packets within the handshake packets encryption, this must be safe.  Because any observer could just apply the same encryption themselves.

And I'd be happy restricting it to handshake packets.  I'd even be happy just adding one frame type for 0RTT within handshake packets, unless someone comes up with a compelling use case for the others.  

I do think this is a better approach than adding a length, because adding a length introduces the possibility of bugs(ie: read length bytes into memory, attempt to 'de-frame' out of bounds memory, badness ensues) and it makes the 'header' larger and slightly more complex.

-- 
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/630#issuecomment-343330861