[16888] in cryptography@c2.net mail archive
Re: TLS session resume concurrency?
daemon@ATHENA.MIT.EDU (Eric Rescorla)
Wed Feb 16 07:51:11 2005
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
To: cryptography@metzdowd.com
Reply-To: EKR <ekr@rtfm.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 10 Feb 2005 16:29:57 -0800
In-Reply-To: <20050210205903.GJ14968@piias899.ms.com> (Victor Duchovni's
message of "Thu, 10 Feb 2005 15:59:04 -0500")
Victor Duchovni <Victor.Duchovni@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@metzdowd.com
