On Tue, Mar 03, 2020 at 01:50:14PM +0000, Дилян Палаузов wrote:
on a very short notice, Let’s Encrypt revokes its certificates with
the message below. This effectively means to start and complete
TLSA/DANE/DNSSEC certificate rollover within 24h.
If, as strongly recommended with Let's Encrypt:
https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022
you publish "3 1 1" records, rather than "3 0 1" or "3 0 2", and renewal
uses the same key (your key was not compromised). Then you don't need
to update your TLSA records at all. You should probably roll over your
keys from time to time when convenient and you can take the time to do
it right, but not for this particular firedrill.
Is this possible in general, when the DNS TTL on its own is 24h? Do I
understand something wrong, stating that this mass revokation is just
bad for DANE+SMTP?
Also keep in mind that DANE aside, (unless you also decided to go with
MTA-STS) there's very little other certificate validation going on in
SMTP, and precious little revocation checking, so in a real emergency,
if I had a choice, I'd run with the revoked certs, dual publish
old and new TLSA RRs, and keep DANE working until a TTL or two goes
by and it is safe to switch to the new cert. I'd also keep TLSA
TTLs at O(1hour) not O(1 day).
What is the right way to mass revoke certificates involved in DANE?
Keep designating trust in the same keys, and you don't most of the time
care about cert rollovers. Or just on special occasions when there's
no time to pre-publish TLSA RRs for new keys, reuse the old keys at
those times.
On Tue, Mar 03, 2020 at 04:06:04PM -0500, Phil Pennock wrote:
What is the right way to mass revoke certificates involved in DANE?
Make sure that the CA certificate is sent on the TLS connection too.
Pin the registrar cert via its public key, not just your own cert.
Here opinions differ. Trusting a CA that validates domain control as
weakly as Let's Encrypt would not be my choice. But with half the
world trusting Let's Encrypt's "proofs" of domain control, you can
perhaps be comfortable in knowing that you're not alone...
A properly thought out "3 1 1" key rollover process at least as robust
as "2 1 1" and less dependent on a redundant third party.
https://mail.sys4.de/pipermail/dane-users/2018-February/000440.html
Or just "certbot renew --reuse-key"...
--
Viktor.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp