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

[Peter Saint-Andre <[e-mail]>]

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