Subject: [ietf-smtp] DANE / Fwd: ACTION REQUIRED: Renew these Let's Encrypt certificates by March 4

From: Дилян Палаузов <[email-masked]>
Date: Tue, 03 Mar 2020 13:50:14 +0000

Hello,

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.

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?

What is the right way to mass revoke certificates involved in DANE?

Greetings
  Дилян

-------- Forwarded Message --------
From: [email-masked]
To: [email-masked]
Subject: ACTION REQUIRED: Renew these Let's Encrypt certificates by March 4
Date: Tue, 03 Mar 2020 12:21:38 +0000

We recently discovered a bug in the Let's Encrypt certificate authority code, 
described here:

https://community.letsencrypt.org/t/2020-02-29-caa-rechecking-bug/114591

Unfortunately, this means we need to revoke the certificates that were affected 
by this bug, which includes one or more of your certificates. To avoid 
disruption, you'll need to renew and replace your affected certificate(s) by 
Wednesday, March 4, 2020. We sincerely apologize for the issue.

If you're not able to renew your certificate by March 4, the date we are 
required to revoke these certificates, visitors to your site will see security 
warnings until you do renew the certificate. Your ACME client documentation 
should explain how to renew.

If you are using Certbot, the command to renew is:

certbot renew --force-renewal

If you need help, please visit our community support forum: 
https://community.letsencrypt.org/t/revoking-certain-certificates-on-march-4/114864

Please search thoroughly for a solution before you post a new question. Let's 
Encrypt staff will help our community try to answer unresolved questions as 
quickly as possible.

Your affected certificate(s), listed by serial number and domain names:

0323f781386c8a5bded046fccf5ee07b3cbf: bapha.be www.bapha.be
033816bfd1fe5a6c35f83cd4072ab506dd1a: lists.aegee.org www.lists.aegee.org
0362a260840e028d77559331766a3a364b04: central.aegee.org www.central.aegee.org
0374340611a873e5d3dc3c251b9b634bfade: mail.aegee.org smtp.aegee.org
03b75379536d583dbb93d9786abce25aab91: mail.aegee.org smtp.aegee.org www.mail.aegee.org
03d2e7712ab3a259c4ed71bddb5707c0f714: lists.aegee.org www.lists.aegee.org
03f571a4fdf8e3f6a24c4e2c65e3f4dc4ff3: central.aegee.org www.central.aegee.org
04c7d79ca93bafc62dd022e29c351302c5c3: mail.aegee.org smtp.aegee.org www.mail.aegee.org
031e23f0635f6ae7c89ea6cf98eeccb666c8: central.aegee.org www.central.aegee.org
0343dae9a834cd535c2dd21ba21ff3f06390: central.aegee.org www.central.aegee.org
03a654a6bef5c3c27e7cc3aec44a7f8839f4: mail.aegee.org smtp.aegee.org www.mail.aegee.org
03b485da5b0f309cbc1031cbfd47d22d9bb3: mail.aegee.org smtp.aegee.org www.mail.aegee.org
03c9ce72fe8ee3c54beb31d55e88e679ca00: bapha.be www.bapha.be
0471e83802604dda8bbece170b6bc358287d: lists.aegee.org www.lists.aegee.org
04e0b4a44836ea9e19335bb9ad1f4dafdc3d: lists.aegee.org www.lists.aegee.org

If you are receiving this email in error, unsubscribe at:
  http://mandrillapp.com/track/unsub.php?u=30850198&id=2ae0669a7db54ba495d77e7101054508.Kpol6X3JUmCojB6o830csBoXvIA%3D&r=https%3A%2F%2Fmandrillapp.com%2Funsub%3Fmd_email%3Ddilyan.palauzov%2540aegee.org
Please note that this would also unsubscribe you from other Let's Encrypt 
service notices, like expiration reminders.

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 3 Mar 2020 19:25:49 +0100

> and complete TLSA/DANE/DNSSEC certificate rollover within 24h.

If timely renewal works, everything should keep on working smoothly.

> mass revokation is just bad for DANE+SMTP?

How about shortening the TTL right now?

> What is the right way to mass revoke certificates involved in DANE?

I think you can always get new certificates, add new TLSA records, and swap
certificates right before revocation, hoping the new records will have
propagated by then.

hth
Ale
--

---

From: Russ Allbery <[email-masked]>
Date: Tue, 03 Mar 2020 11:43:18 -0800

Дилян Палаузов <[email-masked]> writes:

> on a very short notice, Let’s Encrypt revokes its certificates with the
> message below.

Not all of them.  None of mine seem to be affected, for example.

-- 
Russ Allbery ([email-masked])             <https://www.eyrie.org/~eagle/>

---

From: Phil Pennock <[email-masked]>
Date: Tue, 3 Mar 2020 16:06:04 -0500

> 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.

Eg:

; For Let's Encrypt, where they have multiple signing paths, we use
; public-key hashing, not certificate hashing.
; This avoids breakage given, eg, IdenTrust vs other authority paths.
_letsencrypt-tlsa IN TLSA ( 02 01 01 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18 ) ; X1 & X3
_letsencrypt-tlsa IN TLSA ( 02 01 01 b111dd8a1c2091a89bd4fd60c57f0716cce50feeff8137cdbee0326e02cf362b ) ; X2 & X4

and then CNAME to that for each service affected.

I really am not a fan of DANE-EE (Usage 3) certs.  It always seems so
fragile, to be doing DNS timeout dances and pre-issuing replacement
certs, and relying upon others not using resolvers which cache for too
long.

DANE-TA (Usage 2) identifying the public key of the Certificate
Authority (so that their re-issuing the cert doesn't break you, eg Let's
Encrypt X1 vs X3) is a much more robust setup IMO.

Usage:          DANE-TA(2)
Selector:       SPKI(1)
Matching Type:  SHA2-256(1)

I use a single TLSA record for each "group of CAs which might be valid
here" and then CNAMEs for each service using it.

Note that Let's Encrypt have a second standby CA ready to use, X4, to go
with their active X3.
Publish the fingerprints of the public keys of both X3 and X4.

-Phil

---

From: "John Levine" <[email-masked]>
Date: 3 Mar 2020 19:38:27 -0500

>If timely renewal works, everything should keep on working smoothly.

Nope.  I had to force early renewals for about a dozen of mine, but not any of the DANE ones.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 7 Mar 2020 04:29:46 -0500

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.

> 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.

---

From: Phil Pennock <[email-masked]>
Date: Sun, 8 Mar 2020 07:42:57 -0400

> perhaps be comfortable in knowing that you're not alone...

If that's the concern, then tell Let's Encrypt which accounts are
allowed to issue certificates for your domain.

Eg, in the zonefile for `spodhuis.org` I have:

@  CAA  0  issue "globnix.net"
@  CAA  0  issue "letsencrypt.org\; accounturi=https://acme-v01.api.letsencrypt.org/acme/reg/1134193"
@  CAA  0  issue "letsencrypt.org\; accounturi=https://acme-staging-v02.api.letsencrypt.org/acme/acct/12581965"
@  CAA  0  issue "letsencrypt.org\; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/79096293"
@  CAA  0  issuewild ";"
@  CAA  0  iodef "mailto:[email-masked]"

See RFC 8657 for more on `accounturi`.

(Ignore my in-house CA `globnix.net`; and I recommend comments in the
 zonefile or whatever you use, to index those account numbers and keep
 things straight.)

-Phil

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 8 Mar 2020 09:42:22 -0400

> @  CAA  0  issue "letsencrypt.org\; accounturi=https://acme-v01.api.letsencrypt.org/acme/reg/1134193"

Which then of course relies on their DNSSEC validation working properly,
and (recent case in point) their implementation of CAA records working
properly, ...  I just avoid them entirely:

    dukhovni.org. IN CAA 0 issue dukhovni.org
    _25._tcp.smtp.dukhovni.org. IN TLSA 3 1 1 5e078b3160569f165a69eb860395bbbdc7576c3603c3452b07139c276b26d01c

As I said, opinions differ. :-)

-- 
    Viktor.