Subject: Re: [httpwg/http-extensions] Early data that arrives after the handshake completes (#391)

From: HTTP issue updates <[email-masked]>
Date: Wed, 20 Sep 2017 12:40:41 -0700

But can this *really* happen ? I mean, my understanding is that the handshake happens in response to a Hello message which also conveys early data. Can we have early data outside of a hello message, or may we receive a handshake response before a hello message ?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/391#issuecomment-330958927

---

From: HTTP issue updates <[email-masked]>
Date: Sun, 24 Sep 2017 23:46:58 -0700

With reordering of packets in QUIC, you can get a packet that was sent before the handshake completes after the handshake completes.  The order of sending might be "ClientHello, 0-RTT1, 0-RTT2, Client Finished", but the server can get "ClientHello, 0-RTT2, Client Finished, 0-RTT1".  Early data is sent in separate packets (this is a hard rule right now, but we might change the format so that the packets can be sent together in future).

This is unlike TCP fast open where you only get to send the "early data" in the SYN segment.  You can send an awful lot of early data if you want.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/391#issuecomment-331791149

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 25 Sep 2017 20:28:46 -0700

OK thanks for the explanation. I tend to think that such behaviours are
out of the *current* scope of the draft but will fall into it as QUIC
progresses. Maybe all of this can be summarized (for now) as "In case a
TLS implementation supports receiving early data after the handshake
completes, such early data has to be silently discarded". That covers
this case for QUIC and any possible TLS implementation specificity or
even bug.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/391#issuecomment-332076107

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 26 Sep 2017 06:18:58 +0000 (UTC)

I think that we might add "... discarded unless the data can be unambiguously identified as being early data" or something like that.  After all, it's not replayed data if the handshake completes, so I don't want to prohibit its use.  The main problem is that it's hard to properly identify and handle.

FWIW, we debated this for our DTLS 1.3 implementation and chose to discard. That is the easiest answer.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/391#issuecomment-332097653

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 26 Sep 2017 06:29:38 +0000 (UTC)

I'd still be tempted to simply discard for now, just to avoid the problems
of confusing the client with an out-of-order handshake that may make it
think the "late" early data were lost while in the end they are considered.
I'd rather avoid a client sending a request again as regular data and seeing
the server concatenate it with the late arrived early data for example. I
really think it's something we can improve later as the out-of-order use
cases become more obvious. It would also offer us a safety belt allowing
more fancy stuff in QUIC, otherwise we could end up saying "nah don't do
this or that, it could cause trouble with early data". The rule might then
be relaxed. It will not affect TCP-based implementations anyway.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/391#issuecomment-332099500

---

From: HTTP issue updates <[email-masked]>
Date: Thu, 28 Sep 2017 15:40:40 -0700

Closed #391 via #407.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/391#event-1270740406