A recent support issue raised awareness of RFC 8996 (published Mar 2021), which officially deprecates TLS 1.0 (1999) and TLS 1.1 (2006).
The linked RFC document provides justification for deprecation.
To clarify, this is the removal of support for TLS 1.0 and TLS 1.1 protocols. TLS_LEVEL=intermediate will remain for broader cipher coverage for the time being.
UPDATE: This change was implemented for the DMS v12 release (associated PR)
Additional reasoning
TLS 1.2 has been available since 2008 and broadly deployed by around 2016. There had been some exceptions with popular mail clients and devices that especially in the context of mail software deployments + clients lagging behind, that our support via the intermediate setting of TLS_LEVEL remained supported.
Debian, our current base image has already defaulted to TLS 1.2 as a minimum, requiring us to downgrade security when TLS_LEVEL=intermediate is required, simply adjusting a service config such as Dovecots to allow for lower TLS protocols is no longer sufficient. Newer versions of Postfix and Dovecot may likewise in the future drop support completely themselves too.
User Impact
Inbound mail should not be affected. Port 25 does not mandate a secure connection. No serious MTA should lack support for TLS 1.2.
You should not realistically need support for TLS 1.0 or TLS 1.1, except in niche scenarios such as an old printer/scanner devices that refuse to negotiate a compatible non-vulnerable cipher.
Usually these affected devices are old enough that the internet will be failing to verify certificates as the root CA certs on the device expire due to no longer receiving system updates. Some devices may allow opt-out of this trust verification, allowing TLS to still be established successfully.
These ciphers are to be dropped:
All of the above cipher suites use AES-CBC for encryption and SHA-1 for the HMAC.
As a result of this reduction in supported cipher suites, TLS_LEVEL=intermediate now only differs from TLS_LEVEL=modern via 6 additional AES-CBC cipher suites (with HMAC using SHA-256 / SHA-384).
Feedback
If you have any concerns or real use-cases requiring this support, please let us know.
Should a few users require support, we can provide documentation for additional configuration steps, but official support is intended to be dropped going forward. You may refer to these user-patches.sh workaround which is compatible with DMS up to the current release (v14).
A recent support issue raised awareness of RFC 8996 (published Mar 2021), which officially deprecates TLS 1.0 (1999) and TLS 1.1 (2006).
The linked RFC document provides justification for deprecation.
To clarify, this is the removal of support for TLS 1.0 and TLS 1.1 protocols.
TLS_LEVEL=intermediatewill remain for broader cipher coverage for the time being.UPDATE: This change was implemented for the DMS v12 release (associated PR)
Additional reasoning
TLS 1.2 has been available since 2008 and broadly deployed by around 2016. There had been some exceptions with popular mail clients and devices that especially in the context of mail software deployments + clients lagging behind, that our support via the
intermediatesetting ofTLS_LEVELremained supported.Debian, our current base image has already defaulted to TLS 1.2 as a minimum, requiring us to downgrade security when
TLS_LEVEL=intermediateis required, simply adjusting a service config such as Dovecots to allow for lower TLS protocols is no longer sufficient. Newer versions of Postfix and Dovecot may likewise in the future drop support completely themselves too.User Impact
Inbound mail should not be affected. Port 25 does not mandate a secure connection. No serious MTA should lack support for TLS 1.2.
You should not realistically need support for TLS 1.0 or TLS 1.1, except in niche scenarios such as an old printer/scanner devices that refuse to negotiate a compatible non-vulnerable cipher.
Usually these affected devices are old enough that the internet will be failing to verify certificates as the root CA certs on the device expire due to no longer receiving system updates. Some devices may allow opt-out of this trust verification, allowing TLS to still be established successfully.
These ciphers are to be dropped:
ECDHE-ECDSA-AES128-SHAECDHE-RSA-AES128-SHAECDHE-ECDSA-AES256-SHAECDHE-RSA-AES256-SHADHE-RSA-AES128-SHADHE-RSA-AES256-SHAAll of the above cipher suites use AES-CBC for encryption and SHA-1 for the HMAC.
As a result of this reduction in supported cipher suites,
TLS_LEVEL=intermediatenow only differs fromTLS_LEVEL=modernvia 6 additional AES-CBC cipher suites (with HMAC using SHA-256 / SHA-384).Feedback
If you have any concerns or real use-cases requiring this support, please let us know.
swaksuser also shared a similar legacy client concern.mynetworkstrust (roughly equivalent to functionality of thePERMIT_DOCKERENV) on the scanners IP, where it could deliver mail to port 25 to be forwarded externally via a configured virtual alias.Should a few users require support, we can provide documentation for additional configuration steps, but official support is intended to be dropped going forward. You may refer to these
user-patches.shworkaround which is compatible with DMS up to the current release (v14).