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
Received on Tuesday, 25 July 2017 16:07:19 UTC