You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
mta-inRelated to incoming message processing part of the MTA functionality (mail exchanger).mta-outRelated to MSA or outgoing message processing part of MTA functionality.rfcRequest For Comments (ongoing discussion / research needed).securityRelated to security measures.
Transport security in SMTP world is merely Opportunistic, there is no practice like in the Web to always require encryption with matching DNS-ID and trusted certificate. Additionally, things get complicated with the use of MX records to delegate mail handling.
Overall, here are possible options for each SMTP connection, sorted by protection "strength":
No encryption (no protection altogether).
TLS without authentication e.g. self-signed cert. (protects against passive attacks only, server key can be spoofed)
TLS with server cert. authentication (protects against passive attacks, MX records can be spoofed)
TLS with server cert. authentication and DNSSEC (protects against passive attacks, STARTTLS support can be spoofed to downgrade connection to plaintext)
TLS with server cert. authentication and MTA-STS (protects against passive and active attacks, but policy expiry makes it unreliable)
TLS with server cert. authentication and DNSSEC+DANE (protects against active and passive attacks, best option)
Each of these options is better than the previous one so it makes sense to support all of them without directly falling back to the weakest one (no encryption).
Interaction with REQUIRETLS
SMTP REQUIRETLS extension requires TLS with valid and matching certificates and MX records authentication using either DNSSEC or MTA-STS. So messages using it are handled in a "strongest security or fail delivery" way instead of Opportunistic Security approach typically employed by MTAs.
Though, MTA-STS and DANE have similar but not same security characteristics (as was noted in the draft spec review, see References). This might degrade the actual security provided by extension in the long term if DANE becomes more widespread than MTA-STS (unlikely).
Provide policy options to require certain security level for all messages (already done, see authenticate_mx, require_mx_auth and require_tls directives for remote module).
(Possibly) Implement downgrade protection for non-REQUIRETLS messages by remembering the authentication/encryption status like chasquid does it.
It will help with messages sent without using REQUIRETLS extension (as practice shows, SMTP extensions support is poor and grows slowly). Though, it is not clear whether to group options by protection scope (passive/active attacks) for simplicity or provide high granularity. Later option may be better for security but also increases the chance of unexpected interactions.
The text was updated successfully, but these errors were encountered:
foxcpp
added
security
Related to security measures.
rfc
Request For Comments (ongoing discussion / research needed).
mta-out
Related to MSA or outgoing message processing part of MTA functionality.
mta-in
Related to incoming message processing part of the MTA functionality (mail exchanger).
labels
Dec 12, 2019
Matching TLSA record with DANE-TA (Usage 2) or DANE-EE (Usage 3) can replace PKIX and ServerName checks and provides the essentially same (or even stronger) protection against active attacks.
Observation: Most deployed TLSA records use DANE-EE.
TLS without authentication is still better than no TLS at all.
To save latency in transactions with a misconfigured recipient server
that cannot use TLS at all but still advertises STARTTLS support,
downgrade to non-authenticated TLS is attempted only on verification
errors (x509.UnknownAuthorityError or x509.HostnameError) and malformed
certificate errors (x509.ConstraintViolationError and
x509.CertificateInvalidError). In all other cases 'remote' module
fallbacks to plaintext directly.
While rearranging code to support this, some additional changes were
made to allow simplier implementation of security levels idea from #178.
See https://tools.ietf.org/html/rfc7435.
See #178.
Previous approach consisted of multiple independent options with unknown
interaction between each other and not offering enough flexibility for
local policy configuration.
Additionally, it was not possible to implement downgrade protection
mentioned in #178 because it was not clear what is "downgrade" since
options were not related in any linear order, this commit makes it
explicit via the "security levels" system:
MX: DNSSEC > MTA-STS > Nothing
TLS: Authenticated+Encrypted > Encrypted > Plaintext
Note DNSSEC and MTA-STS being different levels, they provide different
security guarantees. Keeping them together under "authenticated" level
would not provide enough granularity for levels-based downgrade
protection and local policies.
'common_domain' MX authentication option is removed. It was offering no
real protection and therefore is was problematic to use together with
planned downgrade protection.
All security level errors are marked as temporary to force requeueing
and allow local admin to troubleshoot them without losing messages.
'remote' tests are changed to use testTarget function to initialize
tested module instance, since security levels mapping requires some
pre-initialization.
Support for IP literals in address domain-part is disabled because it
is incompatible with the new verification logic and was broken anyway
(#176).
mta-inRelated to incoming message processing part of the MTA functionality (mail exchanger).mta-outRelated to MSA or outgoing message processing part of MTA functionality.rfcRequest For Comments (ongoing discussion / research needed).securityRelated to security measures.
Transport security in SMTP world is merely Opportunistic, there is no practice like in the Web to always require encryption with matching DNS-ID and trusted certificate. Additionally, things get complicated with the use of MX records to delegate mail handling.
Overall, here are possible options for each SMTP connection, sorted by protection "strength":
Each of these options is better than the previous one so it makes sense to support all of them without directly falling back to the weakest one (no encryption).
Interaction with REQUIRETLS
SMTP REQUIRETLS extension requires TLS with valid and matching certificates and MX records authentication using either DNSSEC or MTA-STS. So messages using it are handled in a "strongest security or fail delivery" way instead of Opportunistic Security approach typically employed by MTAs.
Though, MTA-STS and DANE have similar but not same security characteristics (as was noted in the draft spec review, see References). This might degrade the actual security provided by extension in the long term if DANE becomes more widespread than MTA-STS (unlikely).
Proposal
Implement REQUIRETLS extension (issue SMTP REQUIRETLS support #123)
Provide policy options to require certain security level for all messages (already done, see authenticate_mx, require_mx_auth and require_tls directives for remote module).
(Possibly) Implement downgrade protection for non-REQUIRETLS messages by remembering the authentication/encryption status like chasquid does it.
It will help with messages sent without using REQUIRETLS extension (as practice shows, SMTP extensions support is poor and grows slowly). Though, it is not clear whether to group options by protection scope (passive/active attacks) for simplicity or provide high granularity. Later option may be better for security but also increases the chance of unexpected interactions.
References
https://tools.ietf.org/html/rfc7435
https://tools.ietf.org/html/rfc7672
https://tools.ietf.org/html/rfc6698
https://tools.ietf.org/html/rfc8689
https://datatracker.ietf.org/doc/review-ietf-uta-smtp-require-tls-07-secdir-lc-sheffer-2019-02-22/
https://blitiri.com.ar/p/chasquid/docs/sec-levels/
Related: SMTP REQUIRETLS support #123.
The text was updated successfully, but these errors were encountered: