On Mon, Mar 14, 2016 at 8:35 AM, Bill Cox <waywardg...@google.com> 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
