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

On 07/25/2017 10:30 AM, Kazuho Oku wrote:
> Hi Benjamin,
>
> Thank you for your response.
>
> 2017-07-25 21:27 GMT+09:00 Benjamin Kaduk <bkaduk@akamai.com>:
>>
>> 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.
> Could you please clarify the reason that an intermediary should not be
> allowed to retry a request (that has once been rejected by 4NN) when
> receiving an 1-RTT confirmation from client, without setting the
> early-data header?
>
> To me, the behavior is identical to a server that postpones a request
> (that was received as 0-RTT data) until it sees a ClientFinished.
> Which is a behavior you state as permissible.
>
>

In the general case, the request can be different when generated for the
retry versus the initial request.  This is quite obvious for the token
binding draft proposal in
https://tools.ietf.org/html/draft-ietf-tokbind-tls13-0rtt-02 but I doubt
that's the only possible case.  Granted, the token binding case is not
especially applicable to the proxy case being discussed here since the
proxy would need to be involved in handling token binding for that to
work.  But I hope it helps to illustrate that the client should retain
control over how the request is retried and that the proxy may not have
all the information necessary to automatically retry.

-Ben