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 16:40, Ned Freed <[e-mail]> wrote:
>
> > 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.
>
> The relevance of POSH was discussed as recently as March on the UTA list.
> I believe it has come up in previously discussions as well.
>

Good to know it's come up at least.


>
> > 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.
>
> The situation here is very different. First, Google is one of the players
> behind this proposal and their withdrawl from standards-based email
> seems...
> unlikely.


As far as SMTP is concerned, at least, I'd agree.


> Second, the primary problem MTA-STS solves - added security against
> active attacks on existing email infrastructure - is quite different than
> the
> XMPP situation.
>
>
I'm not entirely sure that statement is accurate. The exact same list of
requirements is what drove POSH in my memory - an inability to authenticate
the certificates used in many cases and a (perceived) unwillingness to
share private keys, alongside a difficulty in certificate management when
hosting many domains.

Yes, XMPP has the advantage of less cruft and a simpler deployment model,
but I think that's largely irrelevant.


> > 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.
>
> I'm afraid you have this exactly backwards. Even if the SMTP server
> approach
> provided comparable security - and it doesn't -  deploying a new SMTP
> extension
> is quite difficult; we have an abundance of fully worked examples
> demonstrating
> this point. Whereas throwing up an A record, certificate, and server that
> serves out a single document is trivially easy. These days I don't rank as
> an
> experienced IT person, and I was able to do it for a test domain in about
> 20
> minutes.
>
>
I entirely agree that hosting a single document under HTTPS is trivial.


> This is not to say that there aren't issues implementing MTA-STS. There are
> significant issues, but they are all on the client side. Adding an HTTP
> client
> to your SMTP client significantly increases attack surface, so much so
> that I'm
> not willing to do it, and other folks have said they aren't willing to
> either.
>
> The approach I'm using is to build an MTA-STS query server with integrated
> caching support. I have one mostly coded, and while I haven't worked
> through
> all the caching and timeout issues yet, I have not found any significant
> implementation obstacles.
>
>
This workload is what I consider to be the antithesis of "intuitively
simpler".


> > 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 haven't implemented the SMTP client integration part of this yet so I
> may be
> speaking out of turn, but I've mapped it out and it appears to be
> reasonably
> straightforward.
>
> I've also looked at implementing DANE, and IMO it's a major PITA to
> implement,
> so much so that it would take substantial customer interest to make me do
> it -
> interest that has not materialized.
>
>
For what it's worth, I implemented DANE in XMPP, including securely
deriving reference identifiers - making it slightly more complex than RFC
7672 in the end due to XMPP authenticating both ends of an S2S stream - in
a couple of days. I didn't find it even a minor PITA to implement.


> And that's without even considering the difficulty of getting people to
> deploy
> funky DNS records. Like it or not, these days throwing up a single-purpose
> HTTPS server is dead easy. And keep in mind that someone using a hosted
> email
> solution need only deploy a single CNAME record pointing at the hosted
> solution's MTA-STS server. That's about as simple as it gets.
>
> > 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.
>
> Frankly, I don't care if it does or not. DANE is currently a nonstarter in
> my
> book, whereas while I dislike various aspects of this proposal, the
> reality is
> it's far easier to implement.
>
>
Well, we agree it's simpler on the receiving side at least, but that's only
because SMTP doesn't try authenticating the sending MTA.


> > 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:
>
> Please explain how it would be more useful.
>
> > 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 drags in some (but not all) of the implementation isssues with DANE. I
> probably would not have bothered to implement MTA-STS had this been part
> of it.
>
>
I suspect it's a lot easier than it sounds, actually. Otherwise I doubt I
could do it.


> > b) Make matches operate the same way as RFC 6125 (unreferenced, I note).
>
> Not sure what you mean about references: Section 3.2, fourth bullet point,
> section 3.3, second paragraph. section 4.1, first paragraph.
>
>
My error. I somehow missed that one.


> > 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.
>
> A comparable effect can be achieved by using a subdomain root reserved for
> email server use.
>
> So it's a choice between an easily implemented naming convention  and a
> bunch
> of PKIX esoterica. This does not strike me as a difficult choice.
>
>
Well, being *able* to use sRVName would be nice at least. The specification
as written prevents it, which seems unfortunate.

Being able to use dNSName is a given, of course. For one thing, it already
has support directly in OpenSSL's API - unless you're matching one wildcard
against another of course, when you have to do it yourself.


> > 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:
>
> I missed the "MX hostname" thing and agree it should be fixed. I also agree
> that "MX host" is misleading and should be replaced, but I could not come
> up with a useful replacement and so didn't suggest making that change in
> my review.
>
> >    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.
>
> Of course that's the commitment. How could it be otherwise?
>

Then that needs rephrasing, because I didn't see any "Of course" about it.

A commitment by the Policy Domain to support PKIX [RFC 5280] authenticated
TLS, using reference identifiers as listed.

(I'm trying to guess what was meant by "for the specified MX hosts".)


>
> > Using more common - and more uniform - terminology would be of huge
> > benefit: "Sending MTA", "Receiving MTA", and so on are well-known terms.
>
> Except those terms don't match up with anything that needs naming here
> AFAICT.
>
>
"Sending MTA" is used a fair amount (15 times). But they're sending to a
"receiving MX" (4.1), or a "SMTP server" (curiously, some "SMTP servers"
are sending email, though).


> > 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
>
> I haven't gone through the sections on SNI yet so I'm not going to
> comment on this.
>

The main difference (from memory now) is that RFC 7672 uses a "TLSA base
name", which is either the "MX hostname" before or after following CNAMEs.

Dave.