A Dour Look at https Cookies

HTTP cookie
Session ID
RFC 4507

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.

Symmetric Crypto Key

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:

Refusing to communicate over unencrypted channels should not require a 46 page RFC.

From sec 2.2:

Include the fingerprint of the host public key in the URI and it is no longer insecure.

I think that this is an issue only because the client (UA) is holding sensitive host data in the form of cookies in the clear. Rhetorically, why are these data outside the host? Cookies are a very bad idea!

A few more links:
Notes from the http editor
Stateless Protocol
Client side web sessions
https RFC
More bad cookies