TLS session resume concurrency?

[Victor Duchovni]

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.

--

 /"\ ASCII RIBBON                  NOTICE: If received in error, \ /
 CAMPAIGN     Victor Duchovni  please destroy and notify
  X AGAINST       IT Security,     sender. Sender does not waive
 / \ HTML MAIL    Morgan Stanley   confidentiality or privilege,
                                   and use is prohibited.

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