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: Willy Tarreau <w@1wt.eu>
Date: Thu, 11 May 2017 15:51:51 +0200
To: Stefan Eissing <stefan.eissing@greenbytes.de>
Cc: 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: <20170511135151.GB13597@1wt.eu>
On Thu, May 11, 2017 at 01:46:10PM +0200, Stefan Eissing wrote:
> >> The PING merely triggers the data transfer in case the client does not
> >> send anything on its own, I assume.
> > 
> > Yes. That is what I have been thinking. Thank you for clarifying that.
> 
> Excellent, very nice thinking, Kazuho! This strategy really solves any
> interop issues for origin servers. Nice.
> 
> In case of proxies/intermediates, the case is different, I think. 
> 
> If a proxy receives 0-RTT data, it can only make direct use of it inside
> upstream 0-RTT data on a new connection. If it sends 0-RTT data on an
> established connection, the server cannot detect the replay weakness.
> 
> A proxy, on forwarding 0-RTT data on an established connection, must first
> verify the client handshake.

It's even worse. Proxies/load balancers have to take routing decisions inline
and immediately. It's not realistic to hold a request pending and want for
some possibly subsequent TLS layer events while you're blocking at L7. I
think we're adding quite a number of layering violations here unfortunately
:-(

In short when you receive this request that you know was transported over
0-RTT somewhere in the chain, you have to give a verdict : pass or reject.
Also very often the TLS decapsulation is handled by a TLS offloader which
is not HTTP-aware. The most HTTP aware ones are able to add a header
before passing the request to the next layer, which is pretty similar to
the load balancer situation. But clearly the origin server can have multiple
layers of intermediaries between it and the client.

Also in practice, 0-RTT will be effective at multiple places :

          0RTT      0RTT     clear/TLS+keep-alive
  client  ----> CDN ----> LB ----> server

In this chain the CDN will not know whether 0RTT is valid or not for the
client, and it will pass the request using 0RTT again to the origin's edge
made of the load balancer which has no clue either about the validity of
0RTT here. Only the origin server will possibly know. But 0RTT will have
been used twice in this diagram. We're in the exact situation where we
want any agent in the chain to be able to say "4xx retry this please"
so that the closest agent to the client does it first and saves a lot on
RTT to fix the problem.

Willy
Received on Thursday, 11 May 2017 13:52:34 UTC

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