On Mar 29, 2017, at 11:48 AM, John Allen john@klam.ca wrote:
In the event that a certificate is compromised, I would have thought that removing any information that might make the compromised cert appear valid should be removed ASAP.
Sure, if the private key is compromised you want to promptly replace the key+cert (key-pair) and publish an updated TLSA record. However, you're unlikely to notice such compromise within just a few minutes of the event.
So a pragmatic choice is to accept that in the event of key compromise there will be a window of exposure, and that lowering the TTLs has diminishing returns once the TTL is much lower than the time it takes you to discover the problem.
The other factor to consider is the duration of disruption if you replace your server key before the prior TLSA RRset expires from client caches. During that time clients may defer email to your domain because they have the old TLSA RR, but encounter a new server key-pair.
With my recommended "3 1 1 + 2 1 1" approach, if only one of the two keys is compromised, then you can keep the other in place, while rotating only the compromised key.
If you publish only "3 X X" or only "2 X X" records, then unplanned key rotation can disrupt mail flow for up to the TTL unless you publish the new TLSA record first, and wait a full TTL before deploying the replacement key-pair.
Bottom line, I still think a TTL of an hour or two is fine for TLSA records, and that "3 1 1 + 2 1 1" is a better solution than very short TTLs. The CA key can be off-line (if private) or difficult to compromise at the same time as your server key (if a public CA).
Of course with a public CA (e.g. the very popular Let's Encrypt) you have other risks (weak proof of domain control with DV).