I've recently taken a closer look at some MX hosts that fail to
interoperate with the DANE survey's choice of TLS parameters. The
observed interoperability failures are easy to avoid, don't fall into
the trap of:
- On the one hand requiring DANE-capable clients to always
use TLS when delivering to your MX host.
- On the other hand choosing a narrow set of "secure" TLS
parameters, that may well result in no shared "ciphers"
with sensibly configured peers.
- Also leaving your TLS stack unattened for a decade or more,
with just outdated algorithms supported is not a good idea.
If you're publishing DANE TLSA records, you need to make
some effort to stay up to date.
I've seen a few MX hosts with DANE TLSA records, but:
- Only TLS 1.0, with neither TLS 1.2 nor 1.3 supported.
- Only CBC ciphers, with no AEAD ciphers (AESGCM at least).
- P521 (secp521r1) as the *only* supported key exchange group.
...
This type of over-constrained TLS configuration risks interoperability
failure and loss of ability to receive email from some senders.
The DANE survey engine engine settings are fairly typical:
- The underlying TLS software is a recent version of the Haskell's
"tls" package, which has dropped support for TLS older than 1.2.
This is not particularly atypical, even OpenSSL is no longer
easily coaxed into doing a TLS 1.0 handshake.
- The Haskell TLS library has also dropped support for CBC ciphers,
which OpenSSL does support, and though I've now forward-ported
support for CBC ciphers from an older release in my own build
of that library, I expect that there are other senders whose
TLS stacks no longer support (or will soon not support) CBC
ciphers.
- Choosing only the absolutely strongest options (e.g., P521 or
bust) is a bad idea. It is not unreasable on the sending side
to avoid unreasonably large RSA key sizes, unreasonably
large FFDHE primes, and unreasonably strong EC curves) as these
are quite wasteful of CPU resources to little security benefit.
Make sure:
* Your TLS group settings include at least one of:
- X25519 or SecP256r1 (P256)
- ffdhe2048 or ffdhe3072
* With RSA certificates, the key sizes is 2048 or 3072 bits
* With ECDSA certificates use a P256 key.
* Accept both AES128 and AES256 ciphers, and if posisble accept
CBC ciphers.
Better yet, as much as possible stick with default settings that are
optimised for interoperability at sensible, rather tham maximal values
in their various parameters.
--
Viktor. 🇺🇦 Слава Україні!
