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. > I don't believe this is technically viable for the large-scale server > operators most interested in 0-RTT. Having session ticket reuse across > clusters is a requirement for performance, especially in cases such as > moving load between clusters. In the cross-cluster case, neither session > caches nor strike registers are possible in the time-frames that are > interesting and relevant to 0-RTT (as strong consistency between clusters > has inherent latency that isn't possible in the 0-RTT time-frames). Making the SHOULD be about non-idempotent 0-rtt payloads is sufficient. That is, if you're GETting something and the server correctly makes GET idempotent, then you can accept 0-rtt without any replay cache checking. A POST, on the other hand, should get the fallback-to-full-handshake treatment. (And, indeed, the application should not even bother with a 0-rtt POST.) > I fear having a "SHOULD" requirement here is one that will be widely > ignored. It should not be ignored as to non-idempotent operations though! > Anything stateful here defeats the purpose of session tickets [...] Right. > Many of the discussions I've been in seem to have concluded that we > should always be assuming that 0-RTT data can and will be replayed, > and applications and application protocols need to design and use it > carefully, accordingly. Correct. See the above text about idempotency. Nico -- _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
