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

2017-05-11 17:19 GMT+09:00 Stefan Eissing <stefan.eissing@greenbytes.de>:
>
>> Am 11.05.2017 um 07:33 schrieb Willy Tarreau <w@1wt.eu>:
>>
>> Hi Mark,
>>
>> On Thu, May 11, 2017 at 10:23:12AM +1000, Mark Nottingham wrote:
>>> If an origin doesn't have robust retry/replay protection in place for
>>> non-idempotent requests, it seems operationally simpler and safer for them to
>>> disable 0RT, rather than refusing it on a request-by-request basis. That's
>>> the discussion I think we should have here...
>>
>> That's exactly the situation I'm facing for now with haproxy. A few
>> users have asked us to support 0RTT and by lack of way to 1) decide
>> which requests are really safe, and 2) tell the client it must replay
>> them using 1RTT, for now I refused to enable it. The load balancer
>> and the origin server will have a different view of the acceptability
>> of 0RTT, and all the chain must be able to accept or reject them, and
>> let the client retry.
>
> Even the "origin server" might not be aware what the application's
> committal and guarantee here is.
>
> My thoughts for an implementation is:
>
> - it has to work without the "upper" layer / next hop being aware of it
> - it has to fail in a defined HTTP way. The HTTP request is tagged as
>   possibly replayed, regardless of the actual transport. The answer
>   needs to also work on that transport.
> - The negative answer to a 0-RTT request might come early, might come
>   late. For h2, other streams might have been opened, even answered,
>   in the meantime.
> - The sender selecting 0-RTT should only do so, if it understands the
>   retry answer. (Once that is defined)
> - The sender may well want to select 0-RTT only if it considers the
>   data to be safe for replays *and* it expects the server to come to
>   the same conclusion.
> - So, ideally, sender and receiver have the same notion about what HTTP
>   data is acceptable for 0-RTT.

This is an interesting discussion!

I believe that there is no need for us to require a _client_ to resend
a HTTP request, even in case it sends a HTTP request in 0-RTT and then
turns out that the application running behind tells the "origin
server" that it cannot handle 0-RTT request.

IMO what the origin server should do is buffer the 0-RTT request
(note: in TLS 1.3, a server can cap the size of 0-RTT data), and if
the application refuses to handle the request due to the fact that it
has been sent in 0-RTT, wait until the client proves itself to be a
legitimate client (by sending an 1-RTT data), and then resend the
buffered request to the application.

In HTTP/2, the proof can be obtained by sending a PING frame from the
server after sending ServerFinished message (of TLS 1.3) and waiting
for the response to the PING frame.

So, while I agree that it is beneficial to have an agreement on how
the interaction scheme between the origin server and the application
running behind (possibly as an informational RFC), I do not see a
strong reason that we need to introduce some kind of profile due the
introduction of 0-RTT data in TLS 1.3.

> -Stefan
>
>>
>> I tend to think that a 4xx status code would make sense and would be
>> useful to pass the verdict back to the client. For example we could
>> return "418 not idempotent".
>>
>> Willy
>>
>
>



-- 
Kazuho Oku

Received on Thursday, 11 May 2017 11:31:44 UTC