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: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 12 May 2017 09:53:19 +1000
Message-ID: <CABkgnnW1iVa1Ko53qJ_Xjay0rfVC6saA3eAvoGea5u-42hmRKQ@mail.gmail.com>
To: Stefan Eissing <stefan.eissing@greenbytes.de>
Cc: Kazuho Oku <kazuhooku@gmail.com>, Willy Tarreau <w@1wt.eu>, 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>
On 11 May 2017 at 21:37, Stefan Eissing <stefan.eissing@greenbytes.de> wrote:
> Ok, so when the server sees the first non-0-RTT byte from the client, the
> handshake was accepted and the 0-RTT data can be regarded as genuine.

This is basically what Cloudflare have deployed.  They hold some
requests until the handshake finishes.  Some requests are forwarded
(GET, OPTIONS, and HEAD are probably fine), but they are marked as
being potentially replayed.

What Cloudflare's solution misses (for obvious reasons) is a signal
from the origin that the 0-RTT request can be retried.  h2 has that
signal: RST_STREAM+REFUSED_STREAM
<http://httpwg.org/specs/rfc7540.html#REFUSED_STREAM>, but HTTP
doesn't in the general case.

It's almost like 1-RTT in terms of performance, but with the small
optimization you get from being able to use the first RTT to send data
to the gateway.

(As for Willy's concern, maybe consider the request "incomplete" until
the handshake completes, even if it is not.)
Received on Thursday, 11 May 2017 23:53:53 UTC

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