Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context)

[Colm MacCárthaigh <[e-mail]>]

On Fri, Mar 25, 2016 at 2:29 AM, Karthik Bhargavan <
[e-mail]> 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