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

[Viktor Dukhovni <[e-mail]>]

On Mon, Mar 23, 2015 at 03:33:09AM -0500, Nico Williams wrote:

> On Sun, Mar 22, 2015 at 08:35:34PM -0700, Martin Thomson wrote:
> > For HTTP, I think we can use that first flight for idempotent queries
> > quite easily and (at worst) the HTTP/2 connection preface.
> 
> But TLS can't know what's happening at the application layer, so it had
> better be the case that the 0-RTT data is clearly denoted to the app as
> "had better be idempotent".  I.e., this becomes an API issue.  The name
> of the method would have to be indicative of danger.
>
> 0-RTT data is acted on at great risk.  It's OK to use it for negotiation
> purposes where the integrity of the negotiation will eventually be
> confirmed (else the connection fails).  For things like "launch
> missiles" it is a very bad idea to act on the command before
> authenticating it and determining that it's not a replay.  When we don't
> know the nature of the data, we must assume it can't be sent without
> authentication and replay protection.

Therefore, 0-RTT data must:

    * Require a non-default code path to send, (explicit request
    by the client to send a 0-RTT message).

    * Require a non-default code path to *receive*.  That is,
      the server must be configured to allow receipt of such data,
      and must explicitly request to read it.  If the server issues
      a read for protected data, while expedited 0-RTT data is
      pending, the connection should be aborted by the server's
      TLS stack.  Once the server exhausts all the expedited
      data, it can switch to reading protected data.

    * The server's TLS stack must not coallesce 0-RTT expedited
      (idempotent) data with subsequent protected data.

This allows servers that receive idempotent queries to avoid the
1-RTT latency.  Something akin to DNS lookups over TLS, (I am not
specifically advocating TLS as a transport for DNS in this message).

Servers reading expedited 0-RTT data will be aware that they are
doing that, and can/should reject operations that are unsafe in
that context.

This avoids all futile attempts to add stateful replay protection
to a stateless phase protocol.  I expect such attempts are doomed
to failure.

-- 
	Viktor.