Re: [TLS] 0-RTT and Anti-Replay

[Nico Williams <[e-mail]>]

I'm missing some of the context.  Is this 0-RTT fast reconnect (a la
TCP-FO) or is this 0-RTT even for first-meet?  Regardless:

 - I don't really believe that distributed replay caches, are feasible
   without adding back a lot of the latency to be gained from having
   0-RTT.  Fast non-distributed replay caches are feasible, but from the
   discussion so far it seems like that's not interesting anyways.

   This is Kerberos experience talking.  Kerberos, you'll recall, hearts
   replay caches.  We do know how to make fast local replay caches, and
   even adaptive ones that respond to load.

 - I've made this point in the past that 0-RTT data has to be of the
   sort that is safe to use in this way, and therefore I agree strongly
   with comments made so far that this must show up in the API (client-
   and server-side) as such.

 - Idempotence isn't necessarily enough.  "Launch missiles" might be
   idempotent (e.g., world ending) or not ("accidental launch?"), but in
   the latter case a replay might then be idempotent (not accidental ->
   world ending).

 - And just in case anyone is proposing it, I object to TLS interpreting
   supposed-to-be-idempotent HTTP requests as idempotent.  As others
   have mentioned, there exist plenty of "HTTP APIs" that violate HTTP
   idempotence requirements.  Perhaps we should point and laugh, but
   ignoring them seems unwise.

 - Data to be delivered in a 0-RTT way really must be used with care.

   Any API must require that the application [developer] be aware of
   this.

FYI, I had an I-D once about combining SASL mechanism negotiation into
the TLS handshake so as to speed up LDAP, IMAP, and other SASL
applications.  There the 0-RTT data was the SASL mechanism negotiation,
and though it was used prior to handshake completion, its integrity was
also confirmed before any incorrectly-chosen SASL mechanism could yield
success and access for the attacker.  My I-D was specifically about
SASL.  Generalizing this to "any protocol" without taking care to
explain what kind of data can be used is dangerous.

Also FYI, GSS-API has ways to send/receive generic 0-RTT data with
complete handshakes, and has the same considerations that we are
describing for TLS.  The GS2 SASL mechanism uses this, again, for
negotiation purposes, not for application data, but the technique used
works for application data as well, with the caveats that we're
discussing.

The GSS case has not had a full treatment in any RFCs, but there's some
hints about it here and there.  At least GSS got the API right: the
application has to take extra steps to send and use 0-RTT data.  TLS is
much more widespread than GSS, therefore the potential harm of misuse of
0-RTT data is much higher.

Nico
--