On 11 April 2018 at 16:40, Ned Freed <ned.freed@xxxxxxxxxxx> 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.
