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

[Ilari Liusvaara <[e-mail]>]

On Sun, Mar 22, 2015 at 02:49:28PM -0700, Eric Rescorla wrote:
> In the interim in Seattle, we had an extensive discussion of 0-RTT
> anti-replay in which DKG observed that all the proposed anti-replay
> mechanisms provide limited protection. The underlying problem is the
> desire to present a uniform interface in which the calling application
> can count on reliable delivery of the data it provides in the first
> flight, thus requiring the TLS stack to retransmit it automatically.

[...]
 
> 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:
> 
>     c = new TLSConnection(...)
>     c.setReplayable0RTTData("GET /....")
>     c.connect();

This is on client side, but how about server side?

1)

- Server app indicates to TLS stack if it supports 0RTT.
- If no support or 0RTT fails, 0RTT is refused and retransmitted
  data is prefixed into connection data.
- If supported and 0RTT transmission succeeds, app can read 0RTT
  data using separate call.

Problem: 0RTT supported but failing (e.g. wrong keys) is a special
case for serverside.


2)

- Server app indicates to TLS stack if it supports 0RTT.
- If no support, this is signaled to client.
- If supported but fails, this is signaled to client.
- 0RTT data (original or retransmit) is read using separate
  interface.

Problems: 0RTT supported/not supported is two different cases
for the client. Retransmit would need to be flagged specially.


3)

- If 0RTT fails or not supported, it is refused.
- Just prefix 0RTT data into connection data.

Prolem: Server can't tell apart 0RTT data from normal data.



Also, regarding security considerations due to replayability, would
"MUST NOT authenticate in 0RTT data" (which e.g. means cookies that are
possibly authenticating can't be sent)  be useful consideration?



-Ilari