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)
Dear all,
With many thanks to Antony at the RIPE NCC for a difficult job, the draft minutes of our session in Edinburgh are now available.
https://www.ripe.net/community/wg/active-wg/services/minutes/ripe-ncc-servi…
Please let the co-chairs know of any errors and omissions.
As you know, we were time-limited during the session, in particular for comments to Hisham and Gabor. If you think the discussion of any topic covered by the minutes should continue, please feel free to carry on the conversations here on the WG list.
Meanwhile, we will consider how we structure the session at RIPE 93 to allow more time for discussion.
Thanks,
Rob, Stefan, Janos
