W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2017

Re: HTTP profile for TLS 1.3 0-RTT early data?

From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Fri, 12 May 2017 10:21:16 +0200
Cc: Willy Tarreau <w@1wt.eu>, Kazuho Oku <kazuhooku@gmail.com>, Mark Nottingham <mnot@mnot.net>, Erik Nygren <erik@nygren.org>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, "Ponec, Miroslav" <mponec@akamai.com>, "Kaduk, Ben" <bkaduk@akamai.com>
Message-Id: <A7D15E43-AA9C-4C4B-85B8-C296E3D1FBF4@greenbytes.de>
To: Martin Thomson <martin.thomson@gmail.com>

> Am 12.05.2017 um 07:38 schrieb Martin Thomson <martin.thomson@gmail.com>:
> 
> On 12 May 2017 at 15:28, Willy Tarreau <w@1wt.eu> wrote:
>> And we're back to the original point : if we do this for all requests,
>> we're just doing 1-RTT 100% of the time in the end.
> 
> Two reasons why it isn't, or might not be:
> 
> 1.The suggestion was that you would identify a subset of requests that
> get passed on.  That might be GET, HEAD and OPTIONS if you want to be
> conservative.

I am more and more thinking that we need no safe-set definition. It seems
that clients and servers will have specific ideas about what to send and
what to accept in early data.

What a client wants to send early, might not be what the server is willing
to process right away. Servers can always chose to not enable early data at 
all, or, in case of doubt about the data, wait for the handshake to complete.

At least in h2 it seems to be clear how to do that, is there a way for 
http/1.1 to do the same? Is there maybe a generic TLS1.3 way to do that?

If we can define a way for TLS receivers to wait for the handshake, then
there is no need to expect failure from early data, except servers not
following this strategy or being reconfigured between sessions.

Or?

-Stefan




> 2. The data has arrived in less than 1-RTT.  That you don't act on it
> later doesn't mean that you haven't at least saved on the time it
> takes to move those bytes.  The downside being that your handshake
> completion now sits behind a longer line of bytes that are all subject
> to loss and therefore head of line blocking.
Received on Friday, 12 May 2017 08:21:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:03 UTC