Re: [Uta] Last Call: <draft-ietf-uta-mta-sts-15.txt> (SMTP MTA Strict Transport Security (MTA-STS)) to Proposed Standard

[Dave Cridland <[e-mail]>]

On 11 April 2018 at 19:20, Viktor Dukhovni <[e-mail]> wrote:

>
>
> > On Apr 11, 2018, at 7:38 AM, Dave Cridland <[e-mail]> wrote:
> >
> > 2) HTTPS Call-out
> >
> > Given the policy is essentially trust-on-first-use, it's not clear to me
> why much of the STS policy cannot be transferred within SMTP itself,
> perhaps in response to the EHLO issued after STARTTLS completes. This is
> good enough for HTTPS's STS variant, and feels intuitively simpler for MTAs
> to implement.
>
> A key difficulty with using a receiving MTA (MX host) as a policy source
> for active-attack prevention (in the absence of DNSSEC) is that the MX
> RRset is not secured, so the policy thus obtained is not only subject to
> "stripping" on first contact (as is the case with STS as proposed) but also
> subject to tampering by an attacker who can cause a forged policy to be
> vended by a rogue MX host, and then keep that policy in place preventing
> connections to the real receiving MTAs.
>
>
Well, one assumes that an MTA gives out the policy for the MTA, not the
domain, but otherwise I take your points. I don't think that we'd end up in
a place markedly different, with the exception that it'd be MTA policy
rather than domain policy.


> A related issue is that when all the MX hosts are switched to an
> alternative provider, there's not a good way to learn of the policy
> change.  None of the new MX hosts are trusted per the old policy, and the
> none of the old MX hosts are in the new MX RRset.
>
> So unfortunately, a catch-22 prevents use of the MX hosts as oracles to
> authenticate themselves (lift themselves by their bootstraps).
>
> > 3) DNSSEC or not?
> >
> > The draft then goes on to compare the solution to DANE, and notes that
> DNSSEC is not required with MTA-STS - "at a cost of risking malicious
> downgrade attacks". These would be performed by DNS spoofing, which has a
> known history of occurring. In any case, what is distinctly unclear to me
> is whether MTA-STS without DNSSEC is materially different from RFC 7672
> without DNSSEC; if unsecured DNS is "good enough" for MTA-STS, my immediate
> question is whether it might therefore be good enough for at least some
> cases of DANE.
> >
> > I'd note that in RFC 7672, the presence of a (DNSSEC-secure) TLSA record
> is sufficient to mandate TLS - hence my question is whether an insecure
> TLSA record stipulating a particular trust anchor and/or valid certificate
> (PKIX-TA and PKIX-EE) might be sufficient to meet the same security
> requirements here.
>
> Without DNSSEC the protocol is not noticeably different from just
> STARTTLS, which has been quite successful at protecting against passive
> monitoring (90% of traffic in/out of Gmail uses TLS per the transparency
> report site).  For active attackers DNS forgery is in scope, at which point
> some way to guard against MX RRset tampering is needed.  Hence DNSSEC for
> DANE in SMTP and the HTTPS call-out in this draft.
>
> For the record, I'd still rather see the providers in question implement
> DANE, and this should be increasingly doable as they move their email
> servers to dedicated domains (e.g. in Google's case many new customers are
> on googleemail.com MX hosts, rather than the legacy aspmx.l.google.com
> et. al.).  So I see STS as a transitional technology that buys time.  I am
> not advocating STS, but I recognize that there's an operational reality
> that makes DANE difficult for the large providers at present.
>
>
I can sympathise with that, but MTA-STS is not built as a transitional
technology.


> > 4) Wildcard on Wildcard Action.
> >
> > It is deeply unfortunate that MTA-STS mandates a name match based on
> dNSName SANs only. I would have thought that emulating an SRV, and matching
> a corresponding sRVName, would be more useful - and overall, the idea that
> a new matching algorithm has been included so as to match an "mx pattern"
> to a dNSName wildcard just feels like an exploit waiting to happen.
>
> I see little evidence that such certificates are about to become
> mainstream.  Indeed SRV serves little purpose here, as the name being
> authenticated is that of the receiving MTA, which is in the provider's
> domain, so there's largely no need for "virtual hosting", and the MTAs are
> dedicated machines, that are not also Web servers, FTP servers, ...
> So DNS-ID is just fine for the SMTP certificates.
>
>
Again, I'd agree if we posit that MTA-STS is an end-state and not a
transitional one.


> The reason for MX patterns is to avoid the operational pain of having to
> always update one's MX RRset in two places (in DNS and on a web server).  A
> domain with an MX RRset
> of the form:
>
>   example.com. IN MX 0 mx1.mail.example.com.
>   example.com. IN MX 0 mx2.mail.example.com.
>
> would be able to specify a stable MTA-STS policy of:
>
>         mx: .mail.example.com.
>
> and later change the MX RRset to:
>
>   example.com. IN MX 0 mx1.mail.example.com.
>   example.com. IN MX 0 mx2.mail.example.com.
>   example.com. IN MX 0 mx3.mail.example.com.
>   example.com. IN MX 0 mx4.mail.example.com.
>
> without having to update the MTA-STS policy.
>
>
If we assume that the MTA-STS document will always be created manually. But
the only POSH-supporting provider I could find generates the POSH JSON
document for their customers; it's trivial for a provider to do.

I genuinely feel that matching a pattern against another pattern is
introducing an unnecessary complexity into a security protocol.

In any case, if the MX RRset changes in that way, an administrator has to
check each certificate to see what the dNSNames are anyway, surely?


> > It would feel considerably safer to do one of:
> >
> > a) Make matches operate the same way as DANE, by being based on hashes
> of SubjectPublicKeyInfo and/or the complete certificate. (Similar to POSH's
> approach of a certificate hash).
>
> That kind of pinning is not viable for long-term client caching.
>
> > b) Make matches operate the same way as RFC 6125 (unreferenced, I note).'
>
> That fails to deal with the issue of forcing every MX RRset update to
> require
> MTA-STS policy updates.
>

As above; while the policy might not need changing, and administrator has
to validate each and every host within the MX RRset to check the
certificates (particularly fun when multiple hosts masquerade under the
same name or address).

Hence much of the policy has to be sourced from the provider (as it is
today with POSH) and therefore how many "mx" keys there are and what needs
changing is largely irrelevant.


>
> > c) Both/either of the above.
>
> See above.
>
> > I assume the logic behind allowing a wildcard-to-wildcard match is to
> allow a Google user to simply specify ".googlemail.com" and ".l.google.com"
> as their MX identity patterns;
>
> exactly, and not have to keep changing the MTA-STS policy when the
> specific host names change.
>
> > however it feels as though Google could simply use a known name within
> the certificate for all their receiving MTAs, irrespective of the DNS
> records involved.
>
> This is why the MTA-STS policy was changed (at my request IIRC) to be not
> a filter on the MTA names, but rather a filter on the content of their
> certificates.  It allows for either a single name across all the
> certificates, or distinct certificates for each MTA (less likely a single
> point of failure) that don't share names (some CAs don't like multiple
> outstanding certificates for the same name) with a common "base name".
>
> > This, of course, presupposes that the administrator of the mail domain
> somehow does not know the precise names of the MTAs used in their own DNS
> records.
>
> See above.
>
>
See above. :-)


> > 7) Trust Anchors
> >
> > RFC 7672 suggests that MTAs cannot rely on a set of common trust
> anchors, in Section 1.3.4. While I'm not actually convinced this is really
> the case, I'm finding it odd that on the one hand, we have a consensus
> standards-track document that makes this assertion, yet on the other this
> draft makes - implicitly - the opposite assertion.
> >
> > It would be useful to understand if circumstances have changed.
>
> Certainly there've been many changes in the last ~4 years since
> RFC7672 was under development, and now a single CA (Let's Encrypt)
> dominates the landscape.  Out of a total of 6773 IP endpoints
> with DANE-verified certificate chains, the top 10 issuers of the
> EE certificate are:
>
> 3958       Issuer CommonName = Let's Encrypt Authority X3
>  534       Issuer CommonName = COMODO RSA Domain Validation Secure Server
> CA
>  419       Issuer CommonName = AlphaSSL CA - SHA256 - G2
>  109       Issuer CommonName = COMODO RSA Organization Validation Secure
> Server CA
>   73       Issuer CommonName = DigiCert SHA2 Secure Server CA
>   64       Issuer CommonName = Gandi Standard SSL CA 2
>   62       Issuer CommonName = RapidSSL SHA256 CA
>   61       Issuer CommonName = RapidSSL SHA256 CA - G2
>   51       Issuer CommonName = CAcert Class 3 Root
>   48       Issuer CommonName = Thawte TLS RSA CA G1
>
> and so to some extent not that many CAs need to be trusted to verify the
> majority of remote SMTP servers, my concern in 7672 was and remains that
> there's no way to
> exclude any of the CAs in the usual CA bundles (which bundle is
> authoritative?
> Mozilla's?) from being fully trusted for all domains.
>

The current trust anchors are, indeed, Microsoft, Google, and Mozilla.
Google even run their own global CRL.

Thanks for this information, though, it's very useful.


>
> On the one hand, one wants to be able to send email to any destination
> around
> the globe, and can't predict which CA some remote domain will prefer.  On
> the
> other hand one might not want to fully trust each and every CA for the
> world
> at large.  MTAs don't have an interactive user to "click OK" when
> authentication
> fails due to missing or stale trust anchors.  So my goal in 7672 was to
> avoid
> relying on a globally coherent set of trust anchors.
>
> If MTA-STS is primarily implemented by its sponsoring large providers, then
> this is mostly a non-issue, as they're unlikely to use certificates from
> "exotic" CAs that are not nearly-universally trusted.  If STS-adoption
> spreads like wildfire to lots of self-hosting domains around the globe,
> then the CA bundle issue might become relevant.
>
> --
>         Viktor.
>
>