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

[Benjamin Kaduk <[e-mail]>]

On 07/25/2017 08:30 PM, Kazuho Oku wrote:
> 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.

The client may be the only one that has all the information needed to
construct a proper 1-RTT 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.
>
>

I think your use of the phrase "gain replay resistance" is confusing and
perhaps misleading.  Anything sent via 0-RTT is potentially subject to
replay, and nothing can change that.  What happens at receipt of
ClientFinished is an indication that *this particular instance* being
received by the server is not a replay.  But the same data could be
replayed to, and potentially accepted at, other servers as well.

-Ben