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

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 03:44:46 UTC