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

[Roland Zink <[e-mail]>]

On 22.03.2015 22:49, Eric Rescorla wrote:
>
> There are a number of basic ways to address this issue, but I think
> the main plausible[0] ones are:
>
> 1. Keep the server state globally consistent and also temporally
>    consistent so that replays can always be detected.
>
> 2. Remove the TLS anti-replay guarantee for the data sent in the first
>    flight and tell applications to only send data there that can
>    tolerate being replayed.
>
The server probably can't trust the clients choice. An API on the server 
side is needed as well to check that data received on the first flight 
is acceptable.

> 3. Remove the TLS reliable delivery guarantee for the data sent in
>    the first flight, so that the stack doesn't automatically replay it.
>
What does happen when the stack can't deliver it? Is the user asked to 
replay? Does the software hang?

> The first of these options (global state) is possible, but only in
> some limited circumstances, namely very sophisticated operators and/or
> situations where there's really only one server which has good state
> management. An example of the latter is WebRTC, where the server can
> have a different anti-replay context for each connection.
>
> The other two options clearly require a separate API to handle this
> special first-flight data and would require applications to handle it
> separately. So, for instance, in option 2, you would have something
> like:
>
Does this mean a standard API will be specified. A separate API would 
mean that 0RTT will not be available in many cases because the replay / 
delivery guarantee requirements are unknown in some layers.

The solutions 2 and 3 seem to give the problem to the application, e.g. 
either the application doesn't (need to) care or need to implement it. 
So solution 1 seems the way to go although for non single server 
solutions this may be complicated.

Roland