TLSA TTL value

[Viktor Dukhovni]

> On Mar 29, 2017, at 11:48 AM, John Allen <john at 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).

-- 
	Viktor.