Re: New Version Notification for draft-thomson-http-replay-00.txt

2017-07-25 15:54 GMT+09:00 Kazuho Oku <kazuhooku@gmail.com>:
> 2017-07-25 13:47 GMT+09:00 Martin Thomson <martin.thomson@gmail.com>:
>> On 22 July 2017 at 04:02, Kazuho Oku <kazuhooku@gmail.com> wrote:
>>>
>>> OTOH, if we move the responsibility of setting the `early-data` header to
>>> the client (and therefore require the client to do the resend), the 4xx will
>>> need to go to the client, and then the request will travel though the entire
>>> chain. This means that the client will need to wait for 8 RTTh since it
>>> started sending the TLS handshake.
>>
>>
>> That requirement was already present.
>
> Oh. Thank you for pointing that out. I did not recognize that, but
> rereading the draft, section 4.2 does seem to prohibit such behavior.
>
>> Though if your suggestion is to allow
>> an intermediary to retry a request, that's problematic in the sense that it
>> hides the fact from the user agent.  Sure, a user agent accepts the risk of
>> replay when it sends a request in early data, but that doesn't give an
>> intermediary a license to retry for it.
>>
>> There's probably some way that we can describe rules for retrying at the
>> intermediary.  It does save a round trip between the user agent and
>> intermediary, and there is some potential value in having intermediaries
>> repair things.  But we lose some of the nicer end-to-end properties by doing
>> so.
>
> I think that the following model would be safe:
>
> * consider 4NN as a signal that indicates the intermediary to wait for
> 1-RTT confirmation and retry
> * 1-RTT confirmation can be observed as a logical and of
> ClientFinished and non-existence of the early-data header
>
> I do not see any reason to send 4NN to the initiator of the request
> (i.e. browser), since the peer that the initiator talks to can always
> use the ClientFinished as a confirmation. As I said, transmitting 4NN
> to the initiator can impose additional latency, since contrary to
> ClientFinished a client cannot (re)send a request until it sees the
> response.

To be precise, what I am suggesting here is that the server's action
for processing a request without replay-torelance can be defined as
follows:

* 0-RTT request with early-data header: send 4NN
* 0-RTT request with no early-data header: postpone request processing
until ClientFinished
* 1-RTT request with early-data header: send 4NN
* 1-RTT request with no early-data header: process the request

and that it can be deducted from the rule that when receiving a 0-RTT
request without an early-data header, an intermediary should: forward
the request to the origin by adding an early-data header, and if the
origin refuses to process the request by responding with 4NN, it
should wait (i.e. postpone the processing of the request) for
ClientFinished and resend the request to the origin server (this time
without the early-data header).

> --
> Kazuho Oku



-- 
Kazuho Oku

Received on Tuesday, 25 July 2017 07:30:10 UTC