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

[Viktor Dukhovni <[e-mail]>]

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

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.

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

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.

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

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

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

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.