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/
