Thanks for bringing this to our attention.
The current setup is an unfortunate side effect of several events.

We will look into this in more detail once the summer vacation is over
to find the right balance between availability on one side 
and confidentiality and integrity of email messages on the other side.

Kind Regards,

Hans Petter Holen
Chief Executive Officer
RIPE NCC
Phone: +31 20 535 4444

RIPE NCC, P.O. Box 10096, 1001EB, Amsterdam, The Netherlands // Stationsplein 11, 1012 AB Amsterdam

On Tue, 21 Jul 2026 at 14:33, David 'equinox' Lamparter <equinox@diac24.net> wrote:
Hi all,


on June 5th this year, @ripe.net MXes were impacted for about a day due to incorrectly deployed TLSA records.  This got fixed relatively quickly after poking people, with correct TLSA records getting added.

The issue back then was caused by RIPE operational choices to rotate the private keys whenever the certificates are refreshed through ACME, rather than just the certificate.  In an attempt to not have to update the records each time, the TLSA records referenced multiple Let's Encrypt *intermediate* CA's fingerprints rather than the end certificate/key.  Let's Encrypt then issued certificates for ripe.net with a different intermediate CA that was not listed.  From certificate validity times, I can see that it can't have been broken for more than roughly a day.

The less-than-a-day delay to this getting caught does IMHO indicate that this is used and validated by MTAs.  With this being SMTP, in most cases, you won't even get a mail delivery warning by that point yet, the outgoing MTA would still have mails in its queue and be retrying them.  Less than a day is basically "this was noticed immediately" for SMTP.

Unfortunately roughly on June 17th, all TLSA records were removed, leaving e-mails to ripe.net no longer DANE-protected.  They're still absent as of a few minutes ago.  This means that most MXes will fail open and deliver mails to ripe.net without TLS if something tampers with the connection to remove the STARTTLS advertisement.  ("hyperscaler" MTAs are a separate problem because those use MTA-STS and not DANE; but that requires the MTA to have an HTTP client which most FOSS ones don't by default.)

I would really like to have those TLSA records reinstated, or rather, any kind of TLSA record is fine - purely for fail-closed behavior, to prevent stripping of TLS.  It's generally not recommended practice to put root certificate fingerprints in there, but if that's what's doable (putting Let's Encrypt root fingerprints in it), that's fine.  Actual end certificate fingerprints would of course be better, but that does need DNS updates when the private keys change.

It would be a little disheartening to have ripe.net not be leading by example on this.  Best practice to ensure TLS gets used is DANE (plus MTA-STS).   We're pushing so hard for RPKI and then failing on e-mail security? :(

Hope this can be fixed,


equi (David)
-----
To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ncc-services-wg.ripe.net/
As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings.
More details at: https://www.ripe.net/membership/mail/mailman-3-migration/