Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

[Colm MacCárthaigh <[e-mail]>]

On Mon, Mar 14, 2016 at 8:35 AM, Bill Cox <[e-mail]> wrote:

> As we all know, what matters most in security is the default mode.  I am
> suggesting making the default 0-RTT resumption mode stateful, with a
> documented session-ID (and let's bring back the timestamp, too, since we'll
> need it).
>

Having state would make things much more robust; but rather than the state
being around the channel itself (the TLS session), would it be more robust,
and more flexible, for the state to be around the action? like some kind of
hint cookie.

One of the problems with session resumption is that in order to be replay
safe; the sequence number has to restart where it left off. That requires
some kind of transactional store, and if you're doing all of this for
latency, you may end up eating all of the wins there.

Another way to go would be a token that represents an action, e.g.:

1. As part of a regular TLS session, post handshake, client sends a
hint_request request layer message type. This can be URL, or any arbitrary
data, and it's encrypted just as normal application_data is.
2. Server responds with a hint_response token; it's just an opaque token.
3. For future TLS connections; client is free to include the hint token
data in the 0RTT handshake data.

Some interesting advantages:

1. The hint is very distinct from from the application_data stream.
2. The server can choose to use the token ticket-style; encrypt the URL or
whatever directly in the hint.
3. The server could also choose to use the token session-ID style; store it
in a lookup table.
4. Either way; the server has explicit control over what may constitute a
hint and it can be checked and locked down; before the client can transmit
something that may turn out not to be safe.
5. A server could also defer returning the token until the end of the
application session. Hints could be used as application layer resumption or
continuation tokens.

Some downsides:

1. Transactional safety is very difficult; idempotence at the application
layer is a very difficult to achieve property and this doesn't solve that.
2. Similar to TLS tickets/ids: the user's on-the-wire forward secrecy is at
the mercy of the server.
3. Hints could be used as super cookies for user-tracking.
4. Complicated request-response semantics post-handshake (similar to
Heartbeats).
5. Doesn't seem worth the complexity to me.

-- 
Colm