Conclusion: (arguments to follow) I believe that TLS security should be closely paired with session definition and that cookies should be stored at the web site next to the symmetric crypto key that defines the session. Session cookies should not be transmitted to nor returned from the client. Session cookies produced by server logic must travel thru the encryption logic, at the web site, which will have access to the symmetric key and the evolving state of the cipher stream. Instead of encrypting the cookies by the key, store them at the key site and include those cookies with subsequent session https requests from the client to the server. In some server architectures it is even better for the server to keep them.
This avoids the cost of encrypting and decrypting the session cookies.
It avoids the public network latency and transmission costs.
It avoids the vulnerability of corruption of cookies while stored in the client or the cost of authenticating them.
Anecdote
This would be awkward in a plan where a symmetric key is replicated and ciphering is performed by load balanced hardware. Such a scheme is itself awkward when it comes to the obligation of forgetting the key at the end of a session. Such schemes also magnify the opportunity for an attacker to decrypt cipher-text; there are too many places from which legitimate cipher requests may be made.
In TLS a symmetric crypto key is produced at session initiation by the host and communicated to the client. The key is forgotten at the end of the session. There are various strategies for where to keep the symmetric crypto key at the web site when there are many machines handling the https requests.
Quote from https RFC:
I quote from section 2.1 of the HSTS RFC:
From sec 2.2:
A few more links:
HTTP
Notes from the http editor
Stateless Protocol
Client side web sessions
https RFC
TLS RFC
More bad cookies