On Fri, Nov 20, 2015 at 10:38:14PM -0500, Patrick Domack wrote:
Perhaps we need a new protocol by which a TLS server can securely pre-publish the next certificate without activating it (say include it in a new TLS extension), thus allowing the DNS server operator to automate TLSA record updates by querying the SMTP server (authenticated via the current records).
That sounds pretty difficult to adjust for, and would need a lot of changes.
Well, it requires IETF action and software support on the server side, yes.
I like the current dnssec method, where we can publish multiple keys. I will generally publish a new key a month ahead of time for my ksk rollover, then rotate it, and then a month later remove the old key.
This works today, but automating the publication of the "future" TLSA record is the part that some will struggle with.
The same method could be done for tlsa, by publishing multiple records.
Not could, is. See:
https://tools.ietf.org/html/rfc7671#section-8.1 ...
I have not tested if any software accepts this or not, but just publishing the new one a week ahead of time, rotating it, and removing the old one at the same or later time (in case of failback), to me sounds like the perferred method.
Yes, that's what section 8 of RFC7671 describes. And of course this is supported by Postfix and Exim, and will soon(ish) be supported by OpenSSL.
The problem is that if certificate deployment is fully automated (see today's Let's Encrypt thread on this list), then prepublishing the next TLSA record becomes difficult.
The work-arounds, are:
* Keep the key the same while getting new certificates for it, publish "DANE-EE(3) SPKI(1) SHA2-256(1)" records, change keys manually, and go through the usual prepublication process for the key digest.
* Switch to using "DANE-TA(2) SPKI(1) SHA2-256(1)" records, with a selector of SPKI rather that Cert, because with a third-party issuing CA, you have less control over when the CA cert might get re-issued to extend its life, or cross-sign it, ... Then you're good while the same CA (private key) continues to issue your certificates. The CA cert needs to appear in your chain even if it is a root CA.
https://tools.ietf.org/html/rfc7671#section-5.2