On 07/25/2017 07:36 AM, Willy Tarreau wrote: > On Tue, Jul 25, 2017 at 07:27:02AM -0500, Benjamin Kaduk wrote: >> 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. > In fact the client has no idea about the request's semantics nor safety, I think "no idea" is hyperbole, and maybe not helpful. The application server is the only one that has any hope of being authoritative, of course (but could still be "confused about it" for certain types of side channels). > only the application server does. The client may only approximate this > based on the method, the presence or not of a query string, etc... anything > that anyone else in the chain has access to and that is suboptimal. That's > why the 4NN generated by the server provides the best safety here : if there > is a risk that the server experiences a replay, it means it has accepted the > request carrying the Early-Data header, meaning it was replay-safe. Otherwise > the server would only process the only one without Early-Data. > I'm not sure I'm understanding you properly, particularly with respect to "experiences a replay". Please also keep in mind the distinction of terminology between replay and retry that I've been trying to enforce. With respect to my original claim, I am thinking along the lines of https://www.ietf.org/mail-archive/web/tls/current/msg23362.html where a client might have external reasons to defer the retry behavior. (This is not necessarily the only use case, of course.) -Ben
Received on Tuesday, 25 July 2017 13:42:14 UTC