Re: [TLS] 0-RTT security considerations (was OPTLS)

[Nico Williams <[e-mail]>]

On Fri, Nov 21, 2014 at 04:55:23PM -0800, Watson Ladd wrote:
> On Fri, Nov 21, 2014 at 10:51 AM, Nico Williams <[e-mail]> wrote:
> >> >   It's much easier to have the server hold the
> >> > early data and have it bound into the client's next handshake msg.

Actually, there's no need to bind early data into the handshakes.  It's
enough that the client has to eventually confirm a handshake message
from the server, and for good measure the client should switch to a key
to which the server contributed before sending non-early data.  Then the
server can detect replays.

However, the security consideration remains that replay detection for
early data is not available until the handshake completes.  Thus early
data bearing messages like "launch missiles" must not be acted upon
until the handshake completes.  This is a fairly severe security
consideration...

> Why wouldn't the implementation of TLS automatically resend 0-RTT data
> if the server didn't accept it? This seems like the right solution.

Agreed.

In the case of the server not having the key with which to decrypt the
early data the only available choices are: a) abort, b) notify the
client app and let it abort or retransmit, c) hold on to the early data
for retransmission.  (a) is not a good idea, and (b) is probably too
complicated (as are all of these security considerations) for many apps,
which leaves (c) (your suggestion) as the best approach to the problem
of the client using a stale key (e.g., a session resumption ticket for
which the server forgot the key) for 0-RTT early data.

Nico
--