SMTP REQUIRETLS (RFC 8689)
Max Mazurov
It is common knowledge that TLS for server-server SMTP is merely Opportunistic
(as defined in [1]) and there is no strong guarantee it will be used. Even
worse, in most cases MTAs lack any protection against active downgrade attacks.
chasquid is better than that with its security levels feature and MTA-STS
support. If security-aware stub resolver gets added to chasquid, it will be
possible to support the new SMTP extension called REQUIRETLS (RFC 8689[2]). Are
there any plans or thoughts about it?
[1]: https://www.rfc-editor.org/rfc/rfc7435.html
[2]: https://www.rfc-editor.org/rfc/rfc8689.html
--
Cheers, Max Mazurov
https://foxcpp.dev
Alberto Bertogli
>Hello, list.
>
>It is common knowledge that TLS for server-server SMTP is merely Opportunistic
>(as defined in [1]) and there is no strong guarantee it will be used. Even
>worse, in most cases MTAs lack any protection against active downgrade attacks.
>chasquid is better than that with its security levels feature and MTA-STS
>support. If security-aware stub resolver gets added to chasquid, it will be
>possible to support the new SMTP extension called REQUIRETLS (RFC 8689[2]). Are
>there any plans or thoughts about it?
while to see if this gets adopted by MUAs or other MTAs, and how.
Unlike other like MTA-STS, this RFC introduces significant
interoperability risks, because any MTA that doesn't support REQUIRETLS
(which also requires the target domain to implement MTA-STS or DNSSEC,
both fairly uncommon) will cause the mail to be rejected, which is quite
strong and can easily cause usability problems.
And this is not that trivial to implement, since it has implications for
DSNs, aliases expansion, etc. It's more intrusive than it might seem.
So before introducing all that complexity, I am interested in seeing how
much support this gets, not only from MTAs but MUAs too, and how it is
used in practice.
I know it's a bit of a chicken and egg problem, though, and this
position doesn't help. I wish things worked differently with email and
we could raise the security bar much faster, but in this case I worry
that the risk of interoperability issues is very large, and has a
significant likelyhood of cause REQUIRETLS to see extremely low
adoption. I really hope I'm wrong :)
chasquid already has some features that accept more risk of
interoperability problems in exchange for better security (the security
levels/downgrade protection you mentioned), and I think those are
definitely worth it. But I don't see REQUIRETLS as being that clear.
Does this help? What do you think?
Is anyone else planning on using/supporting this, or cares strongly
about it?
Thanks,
Alberto
PS: Also, some of the main motivations for REQUIRETLS are already
addressed by the protections included in chasquid, by being very
aggressive in negotiating TLS and tracking security levels to prevent
downgrade attacks. This doesn't change the point about support, but it
does mean that IMO chasquid users are getting a fair amount (but not
all) of the same practical benefits, with a much, much reduced
interoperability/usability risk.
Max Mazurov
> Does this help? What do you think?
I am not very sure about how well chasquid "security levels" actually protect
against active attacks. Without MTA-STS, X.509 verification means nothing since
it is possible to spoof MX records and simply redirect messages using them. On
top of that, MTA-STS has some trade-offs hurting its downgrade protection, they
are discussed in the RFC Section 10.2 [1].
Honestly, I hope for a wider DNSSEC+DANE adoption. It is downgrade-resistant
without any need for MTA to "remember" anything like chasquid does.
Sadly, Google seems to push MTA-STS so we are stuck with it now and it has
implications on REQUIRETLS security[2]. I am not sure what are these reasons
why big providers cannot deploy DNSSEC and DANE[2], though.
> Is anyone else planning on using/supporting this, or cares strongly about it?
So far I am not aware of any plans, but hey, the RFC is just one month old.
I was considering it for supporting it in maddy, but I guess I am not a big
player here. Emailed postfix-users list about it, also will probably ask
Thunderbird people.
[1]: https://tools.ietf.org/html/rfc8461#section-10.2
[2]:
https://datatracker.ietf.org/doc/review-ietf-uta-smtp-require-tls-07-secdir-lc-sheffer-2019-02-22
Max Mazurov
in IETF process for RFC 8689. Full message is in attachments, I will quote
parts I consider important for discussion in the scope of chasquid.
December 13, 2019 5:01 PM, "Viktor Dukhovni" <postfi...@dukhovni.org> wrote:
>I was involved in the IETF UTA WG process of this RFC. For the next ~10
>years there'll be little to no use of its feature that requests
>enforcing authenticated TLS along the entire delivery path. Too few
>systems will be capable of doing that to make it useful.
>
>The immediately useful feature of this RFC is per-message *opt-out* of
>receiving system TLS policy. Which can improve mail security by
>reducing the barriers to adoption of *default* TLS authentication via
>DANE or MTA-STS.
>
>More sites may be willing enable DANE and MTA-STS, once users can
>opt-out of the policy when (re-)sending time-sensitive messages that
>don't require confidentiality protection.
[...]
>I don't know how soon we might expect MUAs to include direct support for
>"TLS-Required: NO". Clearly it'll work for power-users of Mutt, Pine,
>Elm, ... And thus likely for the primary use-case of postmasters who
>want to inform downstream sites of TLS problems at their end.
>
>I am not inclined to expend resources on the REQUIRETLS feature for some
>years, until authenticated TLS becomes the norm rather than the
>exception.
So, I would think of implementing the following:
- Advertise REQUIRETLS extension on Submission to indicate
support for TLS-Required.
- Do not accept REQUIRETLS flag for MAIL FROM, since we
do not fully implement RFC 8689.
- TLS-Required overrides "security levels" feature and possibly
other policies related to TLS.