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

2017-07-25 13:47 GMT+09:00 Martin Thomson <martin.thomson@gmail.com>:
> On 22 July 2017 at 04:02, Kazuho Oku <kazuhooku@gmail.com> wrote:
>>
>> OTOH, if we move the responsibility of setting the `early-data` header to
>> the client (and therefore require the client to do the resend), the 4xx will
>> need to go to the client, and then the request will travel though the entire
>> chain. This means that the client will need to wait for 8 RTTh since it
>> started sending the TLS handshake.
>
>
> That requirement was already present.

Oh. Thank you for pointing that out. I did not recognize that, but
rereading the draft, section 4.2 does seem to prohibit such behavior.

> Though if your suggestion is to allow
> an intermediary to retry a request, that's problematic in the sense that it
> hides the fact from the user agent.  Sure, a user agent accepts the risk of
> replay when it sends a request in early data, but that doesn't give an
> intermediary a license to retry for it.
>
> There's probably some way that we can describe rules for retrying at the
> intermediary.  It does save a round trip between the user agent and
> intermediary, and there is some potential value in having intermediaries
> repair things.  But we lose some of the nicer end-to-end properties by doing
> so.

I think that the following model would be safe:

* consider 4NN as a signal that indicates the intermediary to wait for
1-RTT confirmation and retry
* 1-RTT confirmation can be observed as a logical and of
ClientFinished and non-existence of the early-data header

I do not see any reason to send 4NN to the initiator of the request
(i.e. browser), since the peer that the initiator talks to can always
use the ClientFinished as a confirmation. As I said, transmitting 4NN
to the initiator can impose additional latency, since contrary to
ClientFinished a client cannot (re)send a request until it sees the
response.

-- 
Kazuho Oku

Received on Tuesday, 25 July 2017 06:55:13 UTC