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

[Martin Thomson <[e-mail]>]

I'm inclined to side with Ben on this one.  The principles I've been
using to assess this design is mutual consent.  If the intermediary
retries a request without the knowledge of the client, that violates
that principle.  A retry will look like a completely new request when
it hits the origin and it therefore won't trigger any special defense
mechanisms.  The main reason to let the client do the retry is to
allow it to reassess the risks before retrying.

On 26 July 2017 at 02:06, Benjamin Kaduk <[e-mail]> wrote:
> 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 <[e-mail]>:
>
> 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