On Fri, Mar 25, 2016 at 2:29 AM, Karthik Bhargavan < karthikeyan.bharga...@inria.fr> wrote:
> There has been much discussion on 0-RTT replay and here’s a quick summary > of my understanding. > We already knew that an active attacker, or a lossy network, or an > overzealous web browser could > and would cause 0-RTT (and even 1-RTT) data to be replayed to the server. > This can already happen > in TLS 1.2, in QUIC, and so we accepted it as a given in TLS 1.3. > TLS is used by more than web browsers, so this unfortunately isn't the case. In particular: * There are applications and protocols built on top of TLS that do not retry, because they are not replay safe. It's legitimate to prefer bossiness over duplication, and to rely on TLS for anti-replay at the transport layer. * More commonly; there are many applications and protocols that are tolerant of a small number of retries and even duplicates, but suffer severe harm in the face of a large or unbounded number of duplicates. As a result of these new concerns, I would say that TLS 1.3 should > recommend that all servers SHOULD > implement a replay cache, and those that cannot should clearly signal this > to the client, so that the client > can adjust its 0-RTT use case and its expectations accordingly. > +1 but I think we can go further here and specify 0RTT in such a way that it only works when the server maintains state, and so that any given 0RTT ticket may only be used once (to preserve forward secrecy as much as possible within the constrains of 0RTT). -- Colm
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
