Re: [TLS] Closing on 0-RTT

[Ilari Liusvaara <[e-mail]>]

On Sun, Jun 11, 2017 at 04:18:03PM +0100, Eric Rescorla wrote:
> Hi folks,
> 
> We've had a phenomenal amount of discussion around 0-RTT anti-replay,
> and based on my recent summary e-mails I think we generally agree
> about the technical facts, so it's time to finalize the PR and land it
> in the specification.
> 
> 
> Here's what I propose to do:
> 
> - Describe the attacks that Colm described.

That was mainly five attacks, right?

- 0-RTT without stateful anti-replay allows for very high number of
  replays, breaking rate limiting systems, even high-performance
  ones, resulting in an opening for DDoS attacks.
- 0-RTT without stateful anti-replay allows for very high number of
  replays, allowing exploiting timing side channels for information
  leakage. Very few if any applications are engineered to mitigate
  or eliminate such side channels.
- 0-RTT without global anti-replay allows leaking informtation
  from the 0-RTT data via cache timing attacks. HTTP GET URLs
  sent to CDNs are especially vulernable.
- 0-RTT without global anti-replay allows non-idempotent actions
  contained in 0-RTT data to be repeated potentially lots of times.
  Abuse of HTTP GET for non-idempotent actions is fairly common.
- 0-RTT allows easily reordering request with retransmission from
  the client. This can lead to various unexpected application
  behavior if possibilty of such reordering is not taken into account.
  "Eventially consistent" datastores are especially vulernable.

> - Distinguish between replay and retransmission
> 
> - Mandate (SHOULD-level) that servers do some sort of bounded
>   (at-most-N times) anti-replay mechanism and emphasize that
>   implementations that forbid replays entirely (only allowing
>   retransmission) are superior.

I don't remember seeing any scheme that looks feasible to implement,
and that could limit amount replays but not to one per "server".

(Of course, definition of "server" might sometimes be tricky, e.g.
8 "servers" all running in the same virtual machine.

Also, I think SHOULD is bit questionable when not following it
is almost certain to lead to severe problems.

> - Describe the stateless mechanism as a recommended behavior but not
>   as a substitute for the other mechanisms. As Martin Thomson has
>   pointed out, it's a nice pre-filter for either of these other
>   mechanisms.

Basically, the strike register is unimplementatble without bounding
the replay window first in time.

But I don't think that should be represented as a stateless
mechanism, merely as a way of limiting the resources used by
the strike register.

> - Clarify the behavior you need to get PFS.
> 
> - Require (MUST) that clients only send and servers only accept "safe"
>   requests in 0-RTT, but allow implementations to determine what is
>   safe.
 
Also:

- Note that 0-RTT exporters are not safe for authentication unless
  the server does global anti-replay on 0-RTT.




-Ilari