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

2017-05-11 20:46 GMT+09:00 Stefan Eissing <stefan.eissing@greenbytes.de>:
>
>> Am 11.05.2017 um 13:38 schrieb Kazuho Oku <kazuhooku@gmail.com>:
>>
>> 2017-05-11 20:37 GMT+09:00 Stefan Eissing <stefan.eissing@greenbytes.de>:
>>>
>>>> Am 11.05.2017 um 13:35 schrieb Kazuho Oku <kazuhooku@gmail.com>:
>>>>
>>>> 2017-05-11 20:33 GMT+09:00 Stefan Eissing <stefan.eissing@greenbytes.de>:
>>>>>
>>>>>> Am 11.05.2017 um 13:31 schrieb Kazuho Oku <kazuhooku@gmail.com>:
>>>>>>
>>>>>> 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.
>>>>>
>>>>> Hmm, how many RTTs will this proof take?
>>>>
>>>> 1RTT. The latency will be the same as when the client did not use 0-RTT.
>>>> OTOH, the obvious benefit of the proposed approach is less use of
>>>> bandwidth since there is no need for a client to resend the request.
>>>
>>> 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.
>>>
>>> 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.
>
> Does that make sense?

Ah. Thank you for noticing that

I think that you are right in pointing out that the proposed scheme
does not work well if we have HTTP proxies relaying HTTPS requests.

>
>>>>>
>>>>>
>>>>>> 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
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Kazuho Oku
>>>
>>
>>
>>
>> --
>> Kazuho Oku
>



-- 
Kazuho Oku

Received on Thursday, 11 May 2017 12:04:09 UTC