Re: Expectations for TLS session reuse

[Kari Hurtta <[e-mail]>]

> If I attempt to do establish a TLS session on a new connection
> in parallel with an existing connection (as opposed to serially)
> is that still called session resumption?

Session resumption have special meaning.

https://tools.ietf.org/html/rfc5246#section-7.4.1.2

|   The ClientHello message includes a variable-length session
|   identifier.  If not empty, the value identifies a session between the
|   same client and server whose security parameters the client wishes to
|   reuse.  The session identifier MAY be from an earlier connection,
|   this connection, or from another currently active connection.  The
|   second option is useful if the client only wishes to update the
|   random structures and derived values of a connection, and the third
|   option makes it possible to establish several independent secure
|   connections without repeating the full handshake protocol.  These
|   independent connections may occur sequentially or simultaneously; a
|   SessionID becomes valid when the handshake negotiating it completes
|   with the exchange of Finished messages and persists until it is
|   removed due to aging or because a fatal error was encountered on a
|   connection associated with the session.  The actual contents of the
|   SessionID are defined by the server.
|
|      opaque SessionID<0..32>;


|   session_id
|      The ID of a session the client wishes to use for this connection.
|      This field is empty if no session_id is available, or if the
|      client wishes to generate new security parameters.
|
|   cipher_suites
|      This is a list of the cryptographic options supported by the
|      client, with the client's first preference first.  If the
|      session_id field is not empty (implying a session resumption
|      request), this vector MUST include at least the cipher_suite from
|      that session.  Values are defined in Appendix A.5.


/ Kari Hurtta