On Thu, May 04, 2017 at 02:44:06PM -0500, Benjamin Kaduk wrote: > On 05/04/2017 02:39 PM, Nico Williams wrote: > > On Thu, May 04, 2017 at 03:12:41PM -0400, Erik Nygren wrote: > >> On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla <e...@rtfm.com> wrote: > >>> 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining > >>> both session-cache and strike register styles and the merits of each. > > The SHOULD should say that the server-side needs to apply a replay cache > > OR fallback onto a full exchange when the 0-rtt data payload involves a > > non-idempotent operation. > > You seem confused on this key point. The server commits to accepting or > rejecting *all* early data, *before* it can look inside and see what it > is (in particular, whether or not it is idempotent).
Sure, that's fine. You could run an HTTP server that only accepts HEADs, GETs, maybe DELETEs, and accepts 0-rtt and have the client send all POSTs and such to a different HTTP server. > > [...] > > Which is why we (try to) make such a big deal about having an > application profile -- to write down what is actually idempotent. It's one good reason, but we were doing that ages ago, before 0-rtt was ever proposed. (Well, Kerberos has a 0-rtt scheme, with very little guidance on this point...) Nico -- _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
