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

I find this pretty convincing. But...

Now we get to the technical hurdles (and I keep forgetting this one,
so I apologize).

If the intermediary is the first, then this design is fine.  However,
if there is more than one intermediary, unless the intermediary in
question is immediately adjacent to the client, it can't be sure that
the Early-Data header field wasn't present because an earlier hop
added it.   Early-Data is permission to forward a request in 0-RTT
also, so you could wait on this hop, but the handshake on the previous
hop might not have completed.

I don't know how to solve for that case without a whole lot more
machinery.  I don't know if it's a problem.  Do people nest CDNs?  The
CDNI working group would seem to suggest that some do, or at least
plan to.

If Early-Data was omitted by the client, that would make it easier in
a sense.  Then an intermediary could tell if it was the first.  But
then we're back to the confusion problem Subodh described.

On 26 July 2017 at 13:44, Willy Tarreau <> wrote:
> On Wed, Jul 26, 2017 at 11:46:13AM +1000, Martin Thomson wrote:
>> 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.
> In fact, while I personally have no interest in having the intermediary
> perform a retry, I understand Kazuho's point of view here. It's a matter
> of the intermediary's role. If we cut this into "systems", we can see
> this :
>        +---------+    0-RTT      +--------+
>        |  client +---~~~~~~~~~---+ server |
>        +---------+               +--------+
> Here a server considering the request unsafe for 0-RTT will wait for
> ClientFinished. It's not particularly defined how the server is
> architected here. It can be a TLS termination followed by a clear
> server, it can be a multi-layer application server with the first
> layer asking a database whether or not such a request is considered
> safe to pass to the next stage or if it must wait for ClientFinished.
> But it could also be a front gateway serving as the only entry point,
> keeping the connection with the client and politely asking the server
> "do you think this request is safe enough to process or do you prefer
> me to wait for ClientFinished ?". We can view our proposal as such a
> mechanism in the end :
>                    +-------------------------+
>                    | +---------+  +--------+ |
>                    | |  edge   |  | origin | |
>              ------+~| gateway |~~| server | |
>                    | +---------+  +--------+ |
>                    +-------------------------+
>                       "server"
>   Edge Gateway (part of the "server" system above) :
>      "Dear server, I've received this request involving Early Data,
>       do you want to process it now or do you prefer me to wait for
>       ClientFinished first ?"
>      (this is notified via "Early-Data: 1")
>   Origin Server :
>      "Oh don't bother, it was safe enough and I processed it, here's
>       the response"
>      (this is notified via 2xx/3xx status code)
>     or :
>      "Well, I can't process it like this, I need the ClientFinished
>       first to ensure it's not subject to a replay attack"
>      (this is notified via the 4NN too early status code)
> In the latter case, it totally makes sense to imagine that the intermediary
> waits for the ClientFinished and passes the request to the server because
> it got a guarantee by the server that this request was not processed and
> that any possible rogue copy of that request hasn't been processed either
> and will not be.
> So while we designed the 4NN principle as an end-to-end invitation to
> retry, offering the guarantee that the request was not processed and
> that it will not be replayed, this same signaling is perfectly usable
> between components. The fact that the client isn't notified of the
> intermediary retrying it is not a problem because if the client has
> sent its request in 0-RTT and has sent its ClientFinished, it's because
> it expected it to be completed. By the way that was the recommended way
> to implement 0-RTT before we discussed this at the workshop ;-)
> However, I'm not willing to open the draft to let intermediaries retry
> in the general case, at least for the reasons Ben mentionned and because
> for me there is a difference between the specific model above where we
> consider the intermediary as part of the server system and many other
> models. I'd rather not see blackboxes decide to do whatever on the
> client's behalf as a way to "accelerate" networks...
> But I think that by using a careful wording we can ensure that implementers
> who consider themselves as part of the server system see what to do in their
> situation. We can possibly put a few MUST NOT rules for specific cases which
> risk to become border-line.
> Regards,
> Willy

Received on Wednesday, 26 July 2017 04:19:53 UTC