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

On 07/25/2017 02:29 AM, Kazuho Oku wrote:
> 2017-07-25 15:54 GMT+09:00 Kazuho Oku <kazuhooku@gmail.com>:
>>
>> 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.

That seems like it would violate the principle that the actual client
generating the request should have control over whether it is retried.

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

I assume that by "without replay-torelance [sic]" you mean a request
that has potentially replay-unsafe consequences/side effects, so the
request must only be acted on over non-replayable transport.

> * 0-RTT request with early-data header: send 4NN

Yes.

> * 0-RTT request with no early-data header: postpone request processing
> until ClientFinished

That seems permissible, but sending 4NN is also fine and requires less
state on the server.

> * 1-RTT request with early-data header: send 4NN

Yes.

> * 1-RTT request with no early-data header: process the request

Yes.

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

This part I do not agree with, in particular the intermediary making the
decision to re-send the request without the early-data header.  I
believe that this decision must be left in the hands of the original
client, and do not think the latency concern justifies deviating from that.

-Ben