LGTM. Unable to review the bats files though, doesn't look like the ONE_DIR=0 branch is tested for postfix/dovecot, I assume you want to cover that at least? Only looks like non-existent file(fresh install) is being tested, so the conditionals that trigger warnings aren't covered if that matters.

Should also have the PR link to #1455 for auto closing on merge.

Referenced issues that the PR fixes covers these two informative links to justify the use of pre-defined DH groups 👍 :

Mozilla explains how it's better for security and compatibility, while DHE itself is losing relevance:

yes, sharing the same parameters between multiple servers makes attacking all of them computationally cheaper, but it requires those parameters to be actually breakable in the first place (reused parameters make them a more rewarding target, not an easier target)

we use the standard FFDHE parameters for 2048. They are more compatible, and there aren't concerns about their security.
Note that standard DHE is a small (and shrinking) portion of handshakes and likely won't even be recommended in the next version of the standards.

Related security stackexchange discussion reaffirms the advice:

Instead of using pre-configured DH groups, or generating their own with "openssl dhparam", operators should use the pre-defined DH groups ffdhe2048, ffdhe3072 or ffdhe4096 recommended by the IETF in RFC 7919. These groups are audited and may be more resistant to attacks than ones randomly generated.

Traditional finite-field-based Diffie-Hellman (DH) key exchange during the Transport Layer Security (TLS) handshake suffers from a number of security, interoperability, and efficiency shortcomings. These shortcomings arise from lack of clarity about which DH group parameters TLS servers should offer and clients should accept. This document offers a solution to these shortcomings for compatible peers by using a section of the TLS "Supported Groups Registry" (renamed from "EC Named Curve Registry" by this document) to establish common finite field DH parameters with known structure and a mechanism for peers to negotiate support for these groups.

Thanks for the review @polarathene!
Suggested changes have been applied. I've also splitted the tests cases, ONE_DIR bijection is now covered.

Nice cooperation!

I'm still getting familiar with this stuff, but I have read about the move from 2048-bit to 4096-bit here will incur about 400% more overhead in operations/sec (just handshakes I guess?).

I am not sure yet, but it may only apply to DHE-RSA-* cipher suites? So is perhaps a non-issue, unless you run the mail server with a large user base that are unable to use any of the other ciphers.

If no ECDSA certificate is used with RSA being most common(and default with this image?), then the DHE ciphers are required for IE11 on Windows 7 which is EOL.. How that translates to the mail server world, especially third-parties sending inbound email to port 25 is unclear.

I'm still getting familiar with this stuff, but I have read about the move from 2048-bit to 4096-bit here will incur about 400% more overhead in operations/sec (just handshakes I guess?).

DHE is weak and should be avoided. If the client is only supporting DHE and not ECDHE, update the client. If your server is consuming too many resources due to DHE usage: I would recommend disabling DHE- ciphers and update the clients. The DHE ciphers have been phased out in Chrome 53 - 2016

ECDHE is preferred instead of DHE.

Deploy (Ephemeral) Elliptic-Curve Diffie-Hellman (ECDHE). Elliptic-Curve Diffie-Hellman (ECDH) key exchange avoids all known feasible cryptanalytic attacks, and modern web browsers now prefer ECDHE over the original, finite field, Diffie-Hellman. The discrete log algorithms we used to attack standard Diffie-Hellman groups do not gain as strong of an advantage from precomputation, and individual servers do not need to generate unique elliptic curves.
source

may only apply to DHE-RSA-* cipher suites?

It applies to any DHE-* cipher suite. See this https://vincent.bernat.ch/en/blog/2011-ssl-perfect-forward-secrecy and this https://security.stackexchange.com/questions/94390/whats-the-purpose-of-dh-parameters.

To sum up, (Ephemeral) Elliptic-Curve Diffie-Hellman (ECDHE) is preferred over static DHE. When using static DHE, the same parameters are used between different sessions and that's why it's bad. Ephemeral ECDHE are by conception, not affected by this issue.

If no ECDSA certificate is used with RSA being most common(and default with this image?), then the DHE ciphers are required for IE11 on Windows 7 which is EOL.. How that translates to the mail server world, especially third-parties sending inbound email to port 25 is unclear.

- SMTPD on port 25 shouldn't offer STARTTLS
- SMTPS on port 465 is now considered as obsolete, use submission on port 587 instead.
- SUBMISSION on port 587, requires STARTTLS

MTA-MTA can be secured using MTA-STS, the sender mail server is asked to use encryption when he's delivering emails to the receiver server. (Currently, it requires postfix to use https://github.com/Snawoot/postfix-mta-sts-resolver).
When this is enabled, postfix will send emails using a secure connection on the port 25:

mail postfix/smtp[3583]: Verified TLS connection established to gmail-smtp-in.l.google.com[2a00:1450:400c:c0c::1a]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)

As you can see, the negotiated cipher depends on what the sender mailserver supports and what the receiver mail server supports (negotiation).
MTA-STS is a recent specification. When a receiver enforces is MTA-STS policy, it should support recent ciphers such as ECDHE therefore, DHE shouldn't be a requirement. An uncommon case could be a mail server receiver with a MTA-STS policy which only supports DHE, in that case, a delivery failure could happen if the mail server sender does not supports DHE.

DHE is weak and should be avoided.

Doesn't the 4096-bit params in this PR resolve that at the expense of added overhead to support that strength?

If the client is only supporting DHE and not ECDHE, update the client.

Not possible if you're not in control of the client, eg third-party MTA sending email to your server on port 25.

I assume your advice is for mandatory TLS with the reduced cipherlist that direct users would be able to update to a better client.

The DHE ciphers have been phased out in Chrome 53 - 2016

They're advising plain-RSA if ECDHE is not available? That gives up PFS, I assume that decision is based on the 512-1024-bit strength for DHE(I didn't read the more info links they provide), and that either the increase overhead by increasing strength was a negative or they weren't trusting of servers to use stronger strength DH params?

Good to know though, thanks.

To sum up, (Ephemeral) Elliptic-Curve Diffie-Hellman (ECDHE) is preferred over static DHE. When using static DHE, the same parameters are used between different sessions and that's why it's bad.

When you are comparing ECDHE and DHE here, is "static" Finite Field?(eg the ffdhe4096 file in this PR). The last E for both being Ephemeral as you already pointed out, I've read exchanges a new key with each connection instead of reusing the same key?

My understanding of ffdhe4096.pem is that it provides the parameters for DH/DHE, but with DHE I thought that the ephemeral part that enables PFS is keeping it dynamic, rather than static?

EDIT: Read your security.stackechange link, they refer to "static" as without the ephemeral bit(just the E is wrong way vs what is discussed here and in cipher strings):

When static Diffie Hellman (DH) is used (as opposed to Ephemeral Diffie Hellman (EDH))

This discussion, details the difference further.

SMTPD on port 25 shouldn't offer STARTTLS

Source? RFC 2487 and RFC 3207 both state it is not required for inbound port 25(in the context of the port being open to the internet).

SMTPS on port 465 is now considered as obsolete, use submission on port 587 instead.

Not sure why this is being brought up here? I'm well aware of this, but the RFC you linked also points out the reassignment of port 465 to an implicit TLS submission port. I would advise using 465 when possible over 587.

SUBMISSION on port 587, requires STARTTLS

All plain-text mail server ports(SMTP, POP, IMAP protocols) support STARTTLS, but 587 does not require it. The STARTTLS RFC (3207) only mentions the submission port as being a useful way to use it, not that it's required.

In this project, we enforce TLS connections over STARTTLS otherwise refusing to continue with auth, except for port 25.

When a receiver enforces is MTA-STS policy, it should support recent ciphers such as ECDHE therefore, DHE shouldn't be a requirement.

It will still happily receive plain-text or STARTTLS when the other party does not support MTA-STS, refusal will happen if the other party previously had contact and communicated support for MTA-STS for X duration. Other than that, other TLS connections can still be made to those not supporting MTA-STS afaik.

This PR is just updating DH parameters as the NCSC-NL TLS Guidelines recommend.

Cipher choices are up to the mail server administrator, depending on his needs. If you need to support outdated clients, you will have choices to make. It's a tradeoff between compatibility and security.

Doesn't the 4096-bit params in this PR resolve that at the expense of added overhead to support that strength?

I've not calculated the cost of this. As I said, it's here only for backward compatibility. Drop DHE-* ciphers if you don't need them (as dovecot recommends). Modern TLS configuration should not rely on DHE-* ciphers.

Not possible if you're not in control of the client, eg third-party MTA sending email to your server on port 25.

Not our concern. The server will be able to deliver on 25/plain. If the sender server is only supporting DHE-* ciphers you are facing a misconfigured/outdated sender server (you can enforce incoming messages to use TLS if you want, but it's not recommended).

Source? RFC 2487 and RFC 3207 both state it is not required for inbound port 25(in the context of the port being open to the internet).

Not for MUA----[:25]-->MTA. I was not talking about MTA----[:25]---->MDA (the MTA-STS example is using TLS).

EDIT: Read your security.stackechange link, they refer to "static" as without the ephemeral bit(just the E is wrong way vs what is discussed here and in cipher strings):

Both DHE and ECDHE use ephemeral keys, we are updating the dh parameters (used by DHE only, ECDHE uses elliptic curve) which are vulnerable to logjam attacks. 4096bits is currently considered as sufficient BUT it does not make DHE-* ciphers best choice during cipher negotiation.

If you need to support outdated clients, you will have choices to make. It's a tradeoff between compatibility and security.

DHE-* is still valid for TLS 1.2 cipher suites. This project does not restrict ciphers for non-mandatory TLS connections(port 25), other than the exclude list.

I've not calculated the cost of this.

There is some shared results in this thread, although as a user later points out, it was all run locally instead of taking client/server timing into consideration.

Modern TLS configuration should not rely on DHE-* ciphers.

This project doesn't include them in modern TLS_LEVEL, but does in intermediate TLS_LEVEL.

The prior link has explanations for why Mozilla includes them in their intermediate config, which is being referenced for my PR updating the cipherlist(their modern config is just TLS 1.3 which is not suitable for SMTP).

Not our concern. The server will be able to deliver on 25/plain.

We expect broader compatibility for receiving e-mail, so port 25 is more relaxed on ciphers, restriction is mostly on supported protocols. So DHE-* cipher suites are available, and can be used for TLS via STARTTLS, but as you've mentioned, the server is most likely to be negotiating with a better cipher, provided it supports >=TLS 1.2 protocol. Otherwise, the image needs to be deployed with intermediate TLS_LEVEL, else plain-text only.

Not for MUA----[:25]-->MTA

Source? Why wouldn't you want STARTTLS offered? There is nothing insisting it should not be available on port 25 under any scenario, just that you're not to reject if TLS cannot be negotiated.

Best practice would be not to have a MUA submit to port 25, that's fine as advice.

4096bits is currently considered as sufficient BUT it does not make DHE-* ciphers best choice during cipher negotiation.

I don't think anyone was claiming them to be best choice?

Since v2.3.3+ Diffie-Hellman parameters have been made optional, and you are encouraged to disable non-ECC DH algorithms completely. 

https://wiki.dovecot.org/SSL/DovecotConfiguration - SSL security settings

For broad compatibility, this image supports DHE-* ciphers. That said, DHE-* ciphers are subjects to logjam attacks with weak parameters and using a strong group make it resources consuming. If you have concerns about the resources usage, why don't you disable DHE cipher at all?

It is known for a while DHE ciphers are less efficient than ECDHE:
source Vincent Bernat November 28, 2011

Server is enforcing cipher order preference, according to that, DHE-* ciphers will be used when there is no preceding cipher available (if server cipher preference order is disabled, a misconfigured client could use DHE instead of ECDHE and use more resources...).

To my mind, I don't see why DHE-* ciphers should be kept in a modern configuration if I don't need them and it would probably better to drop them as Google Chrome did:

Meanwhile, ECDHE is already widely implemented and deployed. Servers should upgrade to ECDHE if available. Otherwise, ensure a plain-RSA cipher suite is enabled.

Dovecot is recommending disabling non-ECC DH algorithms, which mail server/client is not supporting ECC DH algorithms nowadays?
grep "TLS connection established" mail.log egrep -v "(shodan|immuniweb|internet-census)" | sed 's/.*: //g' | sort | uniq -c | sort -rn
Will give you an answer. (if necessary replace mail.log by mail.info)

Regarding Mozilla statement:

In any case, DHE is not going away for probably a couple years.

It's a point of view, Dovecot and Google Chrome don't share this opinion. (I would recommend not to support DHE-* ciphers if you don't need them, at least on dovecot, for postfix if you are confident and you don't want DHE to be resource consuming, otherwise keep it for postfix only).

modern config is just TLS 1.3 which is not suitable for SMTP

Why intermediate config would be suitable for SMTP? Mozilla config generator seems to be focused on the web, which is legitimately, using mozilla ssl config as a "one fit all" seems to be dangerous in an mail server context.

4096bits is currently considered as sufficient BUT it does not make DHE-* ciphers best choice during cipher negotiation.

I don't think anyone was claiming them to be best choice?

ffdhe4096 is a choice made for having a sufficient secured DHE-* cipher usage but it would be better to drop it if you have concerns about resources usage.

Source? Why wouldn't you want STARTTLS offered? There is nothing insisting it should not be available on port 25 under any scenario, just that you're not to reject if TLS cannot be negotiated.

Why would you use port 25 instead of 465 or 587 when you are using STARTTLS? Some MSPs are still using 25 for plain text; it's misleading to configure a MUA to submit messages on port 25 when 465 or 587 are available.

MSPs currently supporting such use of cleartext SMTP (on port 25)
as a means of Message Submission by their users (whether or not
requiring authentication) SHOULD transition their users to using
TLS (either Implicit TLS or STARTTLS) as soon as practicable.

The RFC https://tools.ietf.org/html/rfc8314 advises dropping plain text and start using implicit TLS but giving the background history of the port 25, why would you use this port when 465 or 587 are available.

Anyway, plain text over any port should not be available (and that's not part of this PR).

Cipher support is a complicated topic, it widely depends on the needs and I'm not gonna find a one fit all solutions about DHE, it consumes resources, it's a fact and we can't do a lot about that.

If you have any concern about using FFDHE4096, you could switch on FFDHE3092.
When using FFDHE2048 you will not pass NCSC-NL TLS tests.

To conclude, thank you for these interesting exchanges but I don't have a lot of time these days.

If you have concerns about the resources usage, why don't you disable DHE cipher at all?

For mandatory TLS connections, that's probably fine for our modern TLS_LEVEL setting to drop DHE, I don't know about ingoing/outgoing email via port 25 though.

It is known for a while DHE ciphers are less efficient than ECDHE

I don't believe that's been debated?

I was just pointing out that the impact of bumping up from 2048-bit to 4096-bit takes 4x as long (apparently), adding CPU overhead. For many users of this image that's unlikely an issue and the better security is good.

it would probably better to drop them as Google Chrome did

I'm of the understanding Google Chrome has done so from a client perspective. If a server is is using weak DH params, then the client isn't able to do much about that is it?

So from their end it's safer to not support those cipher suites in the first place, given that HTTPS has greater modern TLS adoption and should have better options as you have stated.

if server cipher preference order is disabled, a configured client could use DHE instead of ECDHE and use more resources...

Define "configured", if the client is saying it wants DHE, could it not be configured to only say it supports DHE too? Then it wouldn't matter what server cipher preference is if they only agree on a cipherlist intersection (I don't know how possible that is).

which mail server/client is not supporting ECC DH algorithms nowadays?

Old ones? All I know is SMTP servers lag behind web servers/browsers. Google reports some big companies like Samsung, AOL, AliExpress, Adobe not always negotiating encryption when sending email to gmail servers. Either they don't support TLS, or Google is too restrictive that they fallback to plain text.

It's a point of view, Dovecot and Google Chrome don't share this opinion.

Both serve a different type of connection, where the user is involved. Different story with postfix as you agree.

Additionally, even if you exclude DHE, I'm not sure if this has any effect on TLS 1.3 (you can't define them in the cipherlist, the cipherlist you supply is ignored, and client is free to choose, DHE is available in TLS 1.3, but does not use custom DH groups).

Why intermediate config would be suitable for SMTP? Mozilla config generator seems to be focused on the web, which is legitimately, using mozilla ssl config as a "one fit all" seems to be dangerous in an mail server context.

How is it dangerous? I treated their intermediate with our modern, I also reference others advice, not blindly following Mozilla with not asking "Why".

I only take consideration to their cipherlist really, not so much their postfix generator which I've learned is probably not as well considered, but still is worth reading over their justification for certain choices.

ffdhe4096 is a choice made for having a sufficient secured DHE-* cipher usage but it would be better to drop it.

I meant there was no one claiming that DHE key exchange was best choice. ffdhe4096 is fine.

Why would you use port 25 instead of 465 or 587 when you are using STARTTLS? Some MSPs are still using 25 for plain text; it's misleading to configure MUA to submit messages on port 25 when 465 or 587 is available.

I didn't say that. I asked you why you would not have STARTTLS available on port 25.

I had pointed out RFCs regarding STARTTLS on port 25 for MTA => MTA. Then you said you were referring to MUA => MTA, I asked for where you're getting your information that you should not use STARTTLS on port 25 in such a situation, not that you should use port 25 for client submission.

I agreed with you that submission ports were better for that.

Port 465 is implicit TLS btw, no STARTTLS involved, that's on 587.

Some people may opt to have a container service send email without authentication by submitting to port 25, there's no real security issue when this is all done locally on the same server, no credentials to leak, and you'll get TLS anyway via STARTTLS. Authenticating on the submission ports is fine, any gain may be marginal in that scenario though?

Just to clarify, absolutely stick to submission ports when connecting to the server, eg via ThunderBird.

The RFC https://tools.ietf.org/html/rfc8314 advises dropping plain text and start using implicit TLS but giving the background history of the port 25, why would you use this port when 465 or 587 is available.

MSP is related to servicing users. Your containers that send transactional email are not the same.

If they were sending email to an external server themselves instead of via your local SMTP server, then yes, they should absolutely do so securely over 465 if available, otherwise 587.

Port 25 isn't going anywhere, users should not interact with it, but it's still important for transfer between MTAs.

Anyway, plain text over any port should not be available

That'd equate to dropped emails on port 25 if enforced, which the two RFC linked previously instruct you not to do.

(and that's not part of this PR).

To conclude, thank you for these interesting exchanges but I don't have a lot of time these days.

Yeah, sorry about going off-topic here. Totally understand, it's costing me a lot of time too.. Thanks for the insights :)