TLS session resume concurrency?

[Eric Rescorla]

Victor Duchovni <Victor.Duchovni at MorganStanley.com> writes:
> If multiple processes (or threads) have access to a shared TLS session
> cache, does the cache need N sessions to serve N threads? Or can (I
> think unlikely if sessions resume stream-ciphers from internal state
> in the cache) the same session be used by multiple clients?
>
> Postfix only has one TLS session slot per-peer, and so high concurrency
> destinations will typically renegotiate (N-1)/N connections. If an SSL
> session can be resumed from the same saved state multiple (overlapping)
> times the design need not change. Otherwise the problem calls for a
> multiple-session per destination cache...
>
> If the symmetric cypher is fully re-keyed when sessions are resumed
> while avoiding the fresh start PKI overhead, then life is simple
> and sessions can be re-used unmodified. Otherwise I may need to
> ponder on designs for a multi-valued cache.

You can have multiple simultaneous TLS connections that are
rooted in the same session. It's possible that the TLS server
will check the IP address of the client but that's not
specified in the protocol and AFAIK TLS servers do not.

-Ekr

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com