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

Since this was mentioned to me at IETF 101, I managed to find the time to
look it up and review. Several design decisions have left me confused; most
notably the notion of a call-out to HTTPS in the first place. Much of the
document is unclear to me, despite having a background of both Internet
Mail and the application of PKI in application protocols, and it appears to
willfully ignore prior art in this area.

1) A History Lesson

First, some history: In XMPP-land, we faced a similar issue with
large-scale providers (most notably Google) not wishing to host or manage
the certificates for their customers, alongside an assertion that customers
would not wish to provide their private keys to their provider. Despite the
strong evidence to the contrary in the case of HTTPS, the community
nevertheless developed POSH (RFC 7711), and did so in a protocol-neutral
way. In POSH, an entity fetches a well-known document from an HTTPS server
in order to securely obtain information with which to validate a
certificate by means other than building a traditional chain etc.

Notably, this was against a backdrop of CAs which were not free, and
generally quite expensive - this has changed markedly over the years since,
and I should note that POSH's support for self-signed certificates is
probably no longer relevant.

However, it surprises me that the MTA-STS draft does not appear to note
this prior art at all, and this makes me wonder whether it was even on the
radar.

Importantly, POSH was never deployed very heavily - I can find only one
deployment (and "most users opt to just give us the cert"). This was in
part because of Google's withdrawal from standards-based IM, which
liberated the community from having to support a use-case only Google
really felt important, and also the rise of free CAs, which avoided the
cost issue associated with traditional PKIX.

For reference, the XMPP community has a high penetration of DANE records
(around 10% of the self-selected group who test their servers through
community tooling) and a very high penetration of CA-signed certificates
(mostly Let's Encrypt).

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.

3) DNSSEC or not?

The MTA-STS problem is reasonably well-defined in the document - SMTP
servers often do host numerous domains, and unfortunately operating one's
own server has become a rarity, so domains are concentrated on a few
servers. STARTTLS is, as the abstract notes, theoretically susceptible to a
downgrade attack - but this does require either active MITM or some fairly
tight hoops to jump through to actually exploit.

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.

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. 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).
b) Make matches operate the same way as RFC 6125 (unreferenced, I note).
c) Both/either of the 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; 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, 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.

I further assume the logic in mandating matches against dNSName SANs is
because these are readily available; however sRVName SANs, by restricting
their use to a particular service, have the advantage that customers giving
these to their service provider might be deemed more acceptable.

5) Terminology and Nomenclature.

It is well-known that naming things remains the hardest problem in
technology.

However, this draft appears to have taken bold strides in demonstrating
that coming up with new names for things needn't be so challenging.

Take §7.1, for example, which dictates that the SNI extension MUST contain
the "MX hostname" - this latter term does not appear anywhere else in the
document. I'm going to guess that it means the RHS of the MX record, as
defined in RFC 7672 (and informative reference), which is the same as RFC
7672. "MX host", which appears once in RFC 5321, also appears elsewhere in
this draft, including in §1.1, where it is in this definition:

   o  MTA-STS Policy: A commitment by the Policy Domain to support PKIX
      [RFC5280] authenticated TLS for the specified MX hosts.

Impressively, by my reading, the commitment is for the Policy Domain to
support PKIX for all SMTP; and not just for specified hosts.

Using more common - and more uniform - terminology would be of huge
benefit: "Sending MTA", "Receiving MTA", and so on are well-known terms. If
a new term is needed, please do define it. If you mean to use terms from
other RFCs, these need to be Normative References and noted in the
Terminology section.

6) Reference Identifiers and derivation.

RFC 6125 provides a slew of terminology and best practise - from the same
UTA working group, as I recall. RFC 7672 also provides terminology and much
behaviour.

It feels as though this draft should at least attempt to use the same
terminology, and ideally the same behaviour, as RFC 7672 (and RFC 6125).

This is particularly noticeable in the difference between the reference
identifiers used within RFC 7672 (and used within the SNI discussed there)
compared with this draft, see for example this draft's §7.1, compared with
RFC 7672 §8.1

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.

Dave.