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

[Daniel Kahn Gillmor <[e-mail]>]

On Sun 2015-03-22 18:02:05 -0500, Stephen Checkoway wrote:
> None of the options makes me very happy and I'm really concerned that applications and/or implementations will mess this up and it'll lead to a vulnerability.

i share this sentiment.

> If we absolutely must support 0-RTT (and I believe that we do), then I agree with ekr that relaxing reliable delivery of the first-flight data is the least bad choice.

Calling it "unreliable" in the sense that we can't guarantee that it
will get through sounds likely to mislead users.  In fact, the
"unreliability" is that we don't know whether the data was accepted and
processed by the remote server or not (particularly, in the case of a
distributed service, which the client probably can't distinguish).

So in practice, the data sent in the first flight needs to be seen as
"replayable" in some sense.  If it is rejected by the server but the
handshake continues, then the client has three options as it crafts its
1-rtt reply:

 0) send the same payload again
 1) send some different payload (with the same semantics)
 2) send some different payload with different semantics
 3) abort the connection and surface the error to the user

in cases 0 and 1, the first 0rtt payload could actually still be
processed by some other server, and the client would never know about
it.  So case 0 is strictly "replayable" (as in, the attacker can cause
the same payload to take effect twice) and case 1 is "semantically
replayable".

I'm having trouble getting my head around any cases that fall into
case 2, and case 3 is what ekr called "implausible".

so "replayable" still seems like the right way to declare this flight to
users, even though it sounds worse than "unreliable".

> I'm not sure how in-scope API recommendations are, but I think that first flight data absolutely needs to be an explicit API call. That is, something like
>
>     c = new TLSConnection(...)
>     c.write(data)
>
> SHOULD NOT send data along with the handshake. Ekr's setUnreliable0RTTData really seems like the way to go.

  c = new TLSConnection(replayableData,...)
  if c.replayableDataSucceeded :
     c.write(nextFlight)
  else:
     ....

I think there are lots of ways that developers can get burned here.
Even testing these codepaths is tricky.

     --dkg