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

On Tue, Jul 25, 2017 at 02:47:59PM +1000, Martin Thomson wrote:
> On 22 July 2017 at 04:02, Kazuho Oku <> 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.  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.

In fact I think there are some situations where it can safely be done,
specifically if the request was received as 1-RTT, or if the handshake
was completed in the mean time because it then becomes equivalent.

Probably that we should make a diagram to explain where and when the risk
of replay lies and make it more obvious what the intent of the retry is
(ie: prove that the request was not tampered with by using a safe


Received on Tuesday, 25 July 2017 05:22:41 UTC