Re: [Uta] I-D Action: draft-ietf-uta-rfc7525bis-07.txt

[Viktor Dukhovni <[e-mail]>]

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... :-)

-- 
    Viktor.