I asked this question a while back, and apparently I did not make a note of the answer, sorry.
What would be a "good" TTL for TLSA records. Because of there use in validating encryption certs, etc I assume that the shorter the better. I currently use 15min, is this too long or too short?
John A
On Mar 28, 2017, at 1:18 PM, John Allen john@klam.ca wrote:
What would be a "good" TTL for TLSA records. Because of there use in validating encryption certs, etc I assume that the shorter the better. I currently use 15min, is this too long or too short?
Set the TTL slightly shorter than the time it takes you to notice and fix a problem with the records. If you're unlikely to respond to any issues in under an hour, a TTL of much less than an hour will not be beneficial. Very short TTLs also add latency to mail delivery. On the other hand, very long TTLs make prolong problem duration.
On Tue, Mar 28, 2017 at 01:18:57PM -0400, John Allen wrote:
What would be a "good" TTL for TLSA records. Because of there use in validating encryption certs, etc I assume that the shorter the better. I currently use 15min, is this too long or too short?
the TTL is part of the DNS control plane and not strongly related to validity of the data (and neither is the DNSSEC signature lifetime, btw).
What threat or failure would suggest that 15 minutes was "too long"?
-Peter
I thought that one of the ideas behind TLSA is the ability to validate CA certificates. 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. In the event that the certificate is replaced then that information should be updated to reflect the old cert is "gone" and that new cert is in use. As I believe there is not a particularly good mechanism for publishing certificate revocations TLSA appears to provide a mechanism assist in revoking certs.
On 3/28/17 2:06 PM, Peter Koch wrote:
On Tue, Mar 28, 2017 at 01:18:57PM -0400, John Allen wrote:
What would be a "good" TTL for TLSA records. Because of there use in validating encryption certs, etc I assume that the shorter the better. I currently use 15min, is this too long or too short?
the TTL is part of the DNS control plane and not strongly related to validity of the data (and neither is the DNSSEC signature lifetime, btw).
What threat or failure would suggest that 15 minutes was "too long"?
-Peter
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).
Teilnehmer (3)
-
John Allen -
Peter Koch -
Viktor Dukhovni