On Mon, Apr 20, 2026 at 07:51:40AM +0100, Sad Clouds wrote:
> > Those a sensible choices. FWIW, my own server has essentially just an
> > RSA certificate, there's no tangible benefit to also provisioning an
> > ECDSA certificate at present.
>
> When you say there is no benefit, are you referring specifically to the
> cryptographic strength of the keys against brute-force attacks?
No, I am referring to practical pros/cons of managign an additional
certificate. Two cert chains add complexity, is it worth it?
- It does not help with interoperability, everyone supports RSA,
otherwise there are way too many systems they'd not be able
to communicate with.
- The security benefits are of little practical import and not worth
the additional complexity, anyone who can crack your RSA keys can
likely do the same with ECDSA, both are only vulnerable to quantum
computer attacks, and ECDSA may actually fall first (fewer qbits
needed). None of this threatens past traffic.
So all you're buying is the operational cost of managing to sets of TLSA
records to keep correct if/when you rotate keys.
> I’ve been reading about RSA versus ECDSA, and some sources recommend
> deploying ECDSA as well, since it uses smaller keys and allows servers
> to perform the signing step during the TLS handshake more efficiently.
None of that has practical relevance. Don't take it seriously.
> I think this is one of the reasons I prefer DANE over MTA-STS. It
> removes the middleman (i.e. certificate authorities) and instead
> lets you rely on DNSSEC to publish and verify your own keys.
Sure, likewise.
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
