I am configuring a non-sticky load balanced cluster of HTTPS servers. To enable TLS session resumption when a previous client reconnects to a different server in the cluster I will be configuring shared session ticket keys across all servers in the cluster as per RFC 5077.
In the RFC, section "5.5. Ticket Protection Key Management" recommends that:
The keys should be changed regularly.
My research so far has not revealed any consensus on what "regularly" should be. A few references mention daily but without justification. Further, it appears that ticket keys on standalone (ie non-clustered) servers in popular implementations (eg Apache, nginx) are only rotated on process restart which could be very infrequent.
So, my question is essentially:
- Is there a rotation schedule for ticket keys that is considered secure? How is that schedule derived?
- If there is no recommended schedule, are there at least other aspects of TLS behaviour that define sensible upper and lower bounds for rotation frequency (eg client session cache times, certificate validity period)?