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

2017-05-11 22:51 GMT+09:00 Willy Tarreau <w@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.

It is true that TLS 1.3 introduces two class of data: 0-RTT and 1-RTT.
Applications need to distinguish between the two if they are willing
to handle 0-RTT data.

I believe that 0-RTT data is a nice feature of TLS 1.3, and would not
like to see its use constrained by how some deployments are designed.

That said, I would argue that TLS offloaders are already sending
metadata (e.g., the cipher suite being used) to the backend server,
and that it could possibly be extended so that the applications
running behind the offloaders can distinguish between 0-RTT and 1-RTT
data.

One simple method (but likely to be effective way) of sending such
metadata would be to advertise a small 0-RTT window (e.g., one or two
MTUs) from the TLS offloader, and if client uses 0-RTT data, postpone
establishing the connection from the TLS offloader to the backend
until the offloader receives all the 0-RTT data (actually, I believe
that there is high chance that you would be receiving 0-RTT data while
doing Diffie-Hellman operations to resume the connection). Once all
the 0-RTT data are received, the offloader will connect to the
backend, send a chunk of metadata including the selected cipher suite
_and_ the amount of 0-RTT application data that would follow the
metadata.

> 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.

My view is that this is an issue behind origin and that it should be
handled as such, instead creating a profile that requires a user-agent
to resend a HTTP request. I am not against defining how servers
running behind the origin should resend the requests (for better
interoperability).

> Willy



-- 
Kazuho Oku

Received on Thursday, 11 May 2017 14:28:21 UTC