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

[Kazuho Oku <[e-mail]>]

Hi Benjamin,

2017-07-26 1:06 GMT+09:00 Benjamin Kaduk <[e-mail]>:
> 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.

Thank you for the example.

I can understand that the request transmitted in 0-RTT and 1-RTT can
be different. However I do not understand why the fact leads to a
conclusion that the client should be the one to resend the request.

My understanding is that in Token Binding either a secret derived from
early_exporter_master_secret or exporter_master_secret is used. It is
true that there is no replay resistance when the server receives 0-RTT
data with Token Binding. However, replay resistance is gained at the
moment the server receives (and successfully validates) a
ClientFinished. By using ClientFinished as a confirmation, there is no
need to request the client to resend the request, even if Token
Binding was used.

I believe that all data that are protected using early secrets gain
replay resistance at the moment the TLS handshake completes. Hence no
need to require the client to resend data.

>
> -Ben



-- 
Kazuho Oku