RE: Retry safety of HTTP requests

@Mike Bishop there are some proposals for 0-RTT to include the client timestamp in the client nonce to limit the retryability of 0-RTT which are still being discussed on the TLS mailing lists. This is still an open question.

> If we’re talking about a pattern of DELETE, PUT, GET, the fact that every separate action is idempotent doesn’t save us from a replay of the DELETE after the PUT

That's an excellent point, and probably something the application can only determine to be safe. Ideally if an application determines an action to be safe (with a new flag) then it should be safe to retry the same request 5 months from now, although browsers should do a best effort not to do that and TLS 1.3 should also limit the time of 0-RTT to something reasonable.

Subodh

________________________________
From: Mike Bishop [Michael.Bishop@microsoft.com]
Sent: Tuesday, March 22, 2016 7:21 PM
To: Martin Thomson; Mark Nottingham
Cc: Subodh Iyengar; ietf-http-wg@w3.org
Subject: RE: Retry safety of HTTP requests


Idempotency is useful against short-time replay, like just resending until you get a response.  However, 0-RTT would permit replay seconds, minutes, or more later, no?



If we’re talking about a pattern of DELETE, PUT, GET, the fact that every separate action is idempotent doesn’t save us from a replay of the DELETE after the PUT.  I’d probably start with “safe only”, possibly expanded to idempotent-with-preconditions.



Sent from my Windows 10 phone



From: Martin Thomson<mailto:martin.thomson@gmail.com>
Sent: Tuesday, March 22, 2016 6:07 PM
To: Mark Nottingham<mailto:mnot@mnot.net>
Cc: Subodh Iyengar<mailto:subodh@fb.com>; ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>
Subject: Re: Retry safety of HTTP requests



On 23 March 2016 at 11:33, Mark Nottingham <mnot@mnot.net> wrote:
> Another possibility would be a pattern of use that assured that non-idempotent requests weren't able to be retried; e.g., <https://github.com/mnot/I-D/blob/gh-pages/Abandoned/http-poe/draft-nottingham-http-poe-00.txt> (I abandoned this draft because it's not really a new protocol element, it's just a pattern of use.).

That's one approach to the problem.  It's also possible to only use
POST for actions that don't have any real consequences.  For instance,
creation of a resource can be absurdly cheap.  If costly actions are
bound to idempotent methods, then you have a far more robust
application.

TLS 1.3 with 0-RTT is making some people nervous.  One of the things
that we're going to have to grapple with is how much of the
responsibility for replay we (in this working group) are able to take
on.

Now, as Amos outlined, there are many ways in which we can determine
that a retry is acceptable *according to the protocol as specified*.
The question of what is acceptable *according to the protocol as it is
used*.  There will be a subset of the first set that we want to
identify as applicable to 0-RTT [45], and maybe we need to pay a
little attention to the gap between theory and practice.  I suspect
that is where Subodh is coming from here.

[45] Obviously, anything that relies on a response from a server, like
421 or GOAWAY, isn't going to be a useful way to identify something as
being OK for use with 0-RTT.  For me, the big question is between safe
and idempotent (PUT especially).