docs: fix 404 in mailserver.env and default to RSA 2048 for TLS certs

[rahilarious]

Description

title

Type of change

• This change requires a documentation update

[polarathene]

Thanks for spotting the wrong MTA-STS docs link, it should use the version tag (optional) for better reliability?

---

The other changes from RSA 2048-bit to 4096-bit are not needed and can be reverted.

If you disagree, please justify why 110-bit of symmetric equivalent security strength is insufficient, and why you need roughly 40 bits more?

• Math:
  • RSA: https://gist.github.com/polarathene/9e3cd791091dc2bd075a2ec4cf793aaa
  • General entropy (password oriented - especially the lengthy discussion it links to; but offers some relevant insights)
• Reasoning: Default DKIM keylength of 4096 is too long #1854 (comment)
  • You need enough energy to boil all the oceans in the world to pull this off...
  • You can have all the hardware compute power for crypto-mining currently and it's still not happening.
  • Typically when you renew a certificate such as with LetsEncrypt as the CA, it's common to also change the private key in that process, that's a <90 day window, good luck 🤷‍♂️ (as if the financial cost without the time constraint wasn't a large enough barrier alone)

I have looked into this quite seriously in the past as you can see. If you have anything to explain why you think 4096-bit is adding any actual value, I'm always open to new information 👍

• Often though this is just security paranoia / parroting without understanding the topic well
• Some also wrongly assume that the difference between 2048-bit and 4096-bit RSA is only 2x, when it's actually more like 1 trillion times as much (roughly 40-bit symmetric delta). You don't need that, switch to ECC if you want more entropy.

[rahilarious]

The other changes from RSA 2048-bit to 4096-bit are not needed and can be reverted.

I also agree RSA 2048 is fine, I just wanted to have consistent keysize on ssl.md page.

* Reasoning: [Default DKIM keylength of 4096 is too long #1854 (comment)](https://github.com/docker-mailserver/docker-mailserver/issues/1854#issuecomment-806280929)

I'm bit confused here, when using MTA-STS (encrypted email using TLS) which key pair is used for encryption, env SSL_CERT_PATH? or DKIM key pair?

[polarathene]

I also agree RSA 2048 is fine, I just wanted to have consistent keysize on ssl.md page.

👍

Apologies about verbosity below. You may be aware of a bunch of that, but I like being thorough 😎

---

I'm bit confused here, when using MTA-STS (encrypted email using TLS)

MTA-STS isn't affecting email directly, it's only to remember compatible MTAs DMS sent mail to previously that used TLS to know that something is fishy if it can't use TLS (via STARTTLS) in future connections to that MTA. It's more of a bandaid over the fact that it's kind of expected (via an RFC) that mail sent over port 25 is permitted to be sent without encryption for compatibility / delivery reasons IIRC.

You only get that guarantee between the direct connection between DMS and that MTA, there may me multiple hops after that which you cannot ensure the traffic is encrypted, it's not quite the same as HTTPS due to how mail works. Although you could perhaps liken it to a reverse proxy that terminates TLS for HTTPS, then connects to another service unencrypted over HTTP, usually on the same system.

---

which key pair is used for encryption, env SSL_CERT_PATH? or DKIM key pair?

DKIM isn't about encryption, just verifying that your mail content wasn't modified in transit, since as mentioned above it could go through additional hops insecurely where someone tampers with it. This was a problem in some countries due to governments and also malicious use with airports/cafes IIRC.

If DKIM was compromised, it has no impact on past mail traffic since it's already been delivered untampered. The attack only benefits with mail signed that is sent going forward.

You provide a certificate for TLS that DMS will use to help secure the connection, it's primary role however is verifying trust. This differs a bit from the DKIM keypair as there is additional metadata beyond private/public keys, the public key is part of the X.509 certificate.

---

Your confusion with my link is understandable. The title implies it's about DKIM but my comment there is about public-key cryptography in general, but regarding RSA key size strength.

For TLS this is only really relevant for verifying authenticity against a third-party (CA), so that the client knows the server is who they claim to be, establishing trust that negotiating a secure connection is to the correct party. At least when using a cipher with perfect forward secrecy (PFS), that should be the only purpose for the RSA cert.

Provided PFS is in use, then the client and server exchange a bit of information to derive a session key for securing that connection with symmetric encryption (eg: 128-bit or 256-bit AES-GCM), this is done with fancy math that prevents someone listening to that earlier client/server exchange from having enough information to create the session key (since they're missing the secret part unique to client and server, see Diffie-Helman exchange).

An attacker would need to record that encrypted traffic, and then crack the session key which is roughly equivalent to those RSA key size metrics I referenced earlier (little bit stronger IIRC). We use standardized DHE params, presently 4096-bit (although I've been open to lowering it to 2048-bit / 3072-bit). AFAIK, since these are params for DHE used widely, it'd be similar in impact to attacking a CA like LetsEncrypt (which for RSA uses 4096-bit IIRC), these are also used by TLS 1.3 and 2048-bit will be preferred I believe.

However... most connections should be using ECDHE instead (compatible with RSA cert), where EC-256 is equivalent to 128-bit symmetric strength, thus DHE is less attractive. ECDHE is more difficult (remember that we're talking about absolutely massive cost to attack 128-bit, over 65k times as much my previous statements...that's a lot of ocean boiling!)

Since the session key and symmetric encryption are at least 128-bit these days, there's obviously more value in compromising the DHE/ECDHE parameters for a wider breach. At the limits of my understanding with the security aspects and impact at this point though 😅

Some security standards like by NIST will advise higher than I do, but that's usually in their interest to do so, and somewhat caters to a specific audience that likes bigger numbers / comfort over understanding the math. For the most part, what I advise is sane and secure; there is more affordable alternatives to getting information from a target than these attacks.

[github-actions]

Documentation preview for this PR is ready! 🎉

Built with commit: 7775316

[rahilarious]

At the limits of my understanding with the security aspects and impact at this point though 😅

hahahah. You're funny.

I LOVE your verbosity. Never apologize for it. Genuinely appreciate the efforts you put in well-thought out deep explanation. Thank you for kindness.

I'm more curious about you. How can I know more?

[polarathene]

I'm more curious about you. How can I know more?

You can reach me via LinkedIn👍