Can you help me understand the differences, both algorithmic and practical, between RFC 5246 SessionID re-use and RFC 5077 Session Resumption?
Both appear to be ways to nail up a second TLS session without a Server certificate exchange, leveraging the full certificate exchange and validation of a previous, separate TLS session.
Having read RFC 5246 § 184.108.40.206 and RFC 5077 § 3, it seems that RFC 5077 hands a token to the client which has session setup information encrypted with the server's key, such that the client can hand the token back to the server and shortcut the negotiation and agreement of session setup parameters. RFC 5246, on the other hand, simply provides a reference to an existing connection that both parties share, and allows them to re-use those session parameters, based on both parties still having them in memory for the original session.
Is that a proper theoretical grasp?
Insofar as that's "close enough for government work", I'm interested in the real-world usage of the two separate types of connections:
- Is RFC 5246 SessionID good
- Only as long as the original session is still active?
- As long as there's a consecutive chain of sessions using the same SessionID?
- For a loosely defined amount of time after all such sessions have closed but before the SessionID is dropped from active memory?
- Is RFC 5077 Session Resumption
- Commonly used instead of RFC 5246 SessionID?
- Commonly used for more widely separated connections that RFC 5246?
- Commonly used at all?
- Do the two differ as described here:
- RFC 5077 token creation (server send to client) is wholly contained within encrypted packets, e.g., after the handshake?
- RFC 5246 session exchange is wholly unencrypted, e.g., within the early (ClientHello, ServerHello) parts of the handshake?
Any insight you can share is appreciated!