On 6/23/22 11:02 AM, Viktor Dukhovni wrote:
On Sat, Jun 18, 2022 at 11:56:30AM -0600, Peter Saint-Andre wrote:
On 5/27/22 7:51 AM, Stephen Farrell wrote:
- section 3.2: I wondered why no mention of MTA-STS or
DANE? Could/should we say that MTA implementations
SHOULD include support for such strictness?
Hi Stephen,
Although these technologies (RFC 8461 and RFC 7672) seem sensible, I
don't think we authors have a good handle on whether they are widely
deployed enough to justify a SHOULD in a BCP. We will reach out to folks
in the email community for guidance.
Both DANE and MTA-STS have now been around for some years and there is a
body of operational experience with these protocols.
The story is roughly that:
- Both require no changes in the receiving MTA, it just needs to
support STARTTLS and be configured with a "suitable" certificate
chain that meets the promised constraints (be they DANE, MTA-STS
or both).
- Inbound DANE is supported on ~3.34 million domains.
* Many are small domains MX hosted by the likes of:
1,229,567 one.com
278,987 hostpoint.ch
170,237 infomaniak.ch
161,743 transip.nl
158,849 argewebhosting.nl
112,901 hostnet.nl
107,719 domeneshop.no
100,270 jouwweb.nl
96,866 loopia.se
95,410 webhostingserver.nl
...
* Some are email service providers hosting many users and
perhaps also customer domains, for example:
web.de
gmx.de
protonmail.ch
mailbox.org
posteo.de
...
- Inbound MTA-STS is supported by a much smaller number (a few
thousand not millions) of domains, but notably these include many
of the largest email service providers:
$ for d in gmail.com hotmail.com outlook.com yahoo.com aol.com; do
printf "%-20s " "$d"
curl -sLo - https://mta-sts.$d/.well-known/mta-sts.txt | grep
'^mode:' || echo
done
gmail.com mode: enforce
hotmail.com mode: enforce
outlook.com mode: enforce
yahoo.com mode: testing
aol.com
- Outbound deployment is considerably harder to measure, but
IIRC outbound DANE is supported by:
* outlook.com and Azure hosted Exchange customer domains
* one.com
* transip.nl
* protonmail.ch
* mailbox.org
* posteo.de
* ...
- The sending MTA does all the heavy lifting of implementing peer
validation per DANE or MTA-STS as applicable.
- Software support for outbound DANE is included in Postfix, Exim, Halon
MTA,
Power MTA, Cisco ESA, Microsoft hosted Exchange, ... with partial
support last I looked also in Sendmail and perhaps some Qmail
forks...
- Software support for MTA-STS is NOT included in either Postfix or
Exim due to its rather unwieldy architectural footprint, with a
mixture of HTTPS and SMTP and complex per destination caches.
At least in the case Postfix and Exim support for MTA-STS is
unlikely in the near term. The developers have expressed explicit
distaste for the protocol.
Returning to the question asked: SHOULD MTAS support DANE and/or
MTA-STS?
- If the question is about the software stack, then:
* Any MTA that supports STARTTLS already supports both inbound.
* Outbound support for MTA-STS is unlikely the leading open source
MTAs
* Outbound support for DANE is starting to be available even in
some of the cloud provider stacks, but is not yet prevalent.
- If the question is about operator diligence then:
* Inbound DANE requires DNSSEC support from both the recipient
domain and its MX host domain. The primary operational burden
is on the MX host operator, and DANE scales very well when a
single skilled operator MX hosts many domains. Adoption by the
domain hosting operator is growing, especially in northern
Europe, where DNSSEC-signing is presently also more prevalent.
* Inbound MTA-STS requires an HTTPS server for policy publication,
with support for the ".well-known/mta-sts.txt" URL.
* Both DANE and MTA-STS require careful management of associated
DNS records, in particular correct timing of DNS updates
relative to changes in certificate chains or the MTA-STS policy
respectively.
* Outbound DANE requires a local validating resolver on the MTA,
which is comparatively easy to set up, but is an extra step
that holds back some smaller less-skilled operators.
It also requires an X.509 layer in the TLS library that supports
DANE-style certificate chain validation. This is currently
available in OpenSSL, but last I looked not in e.g. BoringSSL or
LibreSSL.
* Outbound MTA-STS requires a complex long-term persistent policy
cache, and support for HTTPS probes in the MTA stack.
In light of the above, "SHOULD" is perhaps still a reach, though I do
think that support for DANE is at this point a best practice. As for
MTA-STS, I am not convinced given its narrow scope of essentially
just the largest operators that it was ever needed, policy for this
set of operators could be implemented statically by those sufficiently
inclined. That is MTA-STS is IMHO too complex for too little gain,
but I'm not exactly a neutral observer... :-)
Hi Viktor (and John too),
Thanks as always for the detailed information. I'll note that we already
have the following text about HSTS in the section on "Strict TLS"
(combining bullet points here for readability)...
* HTTP client and server implementations MUST support the HTTP
Strict Transport Security (HSTS) header [RFC6797], in order to
allow Web servers to advertise that they are willing to accept
TLS-only clients. Web servers SHOULD use HSTS to indicate that
they are willing to accept TLS-only clients, unless they are
deployed in such a way that using HSTS would in fact weaken
overall security (e.g., it can be problematic to use HSTS with
self-signed certificates, as described in Section 11.3 of
[RFC6797]).
Given the state of play for mail (and the ambiguity for non-mail
application protocols), I might suggest that we add the following
informational sentence at the end:
Similar technologies exist for non-HTTP application protocols,
such as MTA-STS for mail transfer agents [RFC8461] and methods
founded in DNS-Based Authentication of Named Entities (DANE)
[RFC6698] for SMTP [RFC7672] and XMPP [RFC7712].
We could also add something to the effect of "these technologies are
experiencing increased adoption so, even though they are not best
current practices at the time of writing, pay attention to future
developments" but that's fairly wishy-washy. If we have a clear
direction in the WG for normative language about DANE (for instance) at
this time, then I'd be open to that as well.
Peter
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
