News for hackers. Stuff that matters.
Re:SMTP MTA Strict Transport Security (MTA-STS) by wahern on Friday September 28, 2018 @06:25PM (#18097564)
Except in the absence of DNSSEC it does not ensure transport security. An attacker positioned to perform a MITM of an SMTP session is also positioned to MITM DNS requests.

It's also worth mentioning that even if you skipped TXT querying and went straight to querying mta-sts.example.com, the attacker can just drop the A or AAAA record for mta-sts.example.com.

The only way to prevent this is to use DNSSEC, which can sign negative answers.

There is the benefit that if a policy is already cached the attack shouldn't work until expired. But much like SPF and similar issues, misconfigurations are so common I'd bet many transfer agents will still fail open if no TXT record is found (i.e. assume it's been disabled). In most organizations (and even small ones), the people or processes for managing DNS and e-mail are separate from WWW. With MTA-STS, when e-mail stops flowing people are going to have to check that their web sites (servers, proxies, etc) are setup properly. That's not at all obvious and will result in a lot of persistently broken systems. Senders are likely to put in mitigations because "it's not our fault" isn't always an acceptable answer.

Plus, if you can MITM you can just drop connections until the policy is expired. MTA's will cache for days; policies like these usually have expiration times on the order of minutes or hours so that one can quickly and easily fix broken configurations. The DNS TXT version + HTTP policy max_age is a very awkward mechanism. IT departments will not understand this stuff well enough to use it as intended. The wording in the RFC that policy max_age should be on the order of weeks is just them papering things over.

The whole thing sounds like they got mid way through a design predicated on using HTTP+TLS policies (the bright idea) before realizing how untenable things were, but stayed committed nonetheless.

Re:SMTP MTA Strict Transport Security (MTA-STS) by tptacek on Friday September 28, 2018 @06:46PM (#18097672)
The difference between your threat model and mine is that yours is based on concern for random people running small mail servers. I understand and respect that threat model, though I do not appreciate or really care about it.

On the other hand: I believe email is a technological dead end, and that we are not evolving towards an Internet with a more distributed email system, but with less distribution. I think that, from a utilitarian perspective, the only mail servers that matter are the ones that Google and its peers run, and that's the threat model I care about.

In my threat model, MTA-STS basically eliminates the concern DNSSEC/DANE addresses. Since your threat model includes rarely-used independently-operated servers (note that mine includes things like Fastmail and Proton!), servers that won't have cached assertions, MTA-STS is inadequate for your needs.

The problem I have with your argument is that to fix your problem, which is an extreme niche, you require the radical centralization of all cryptographic trust on the Internet into a tree-shaped PKI whose roots and trunks are controlled by world governments and whose technical underpinnings date back to the 1990s. Even if I was to stipulate that you had a point, DNSSEC wouldn't be a viable answer to it.

But that's a normative argument, and my point about DNSSEC being done is positive, not normative: deployment of MTA-STS is going to end DNSSEC. Not because I want it to (though I do) or because it should (though it should) but because it will: it drives a stake through the heart of the last truly motivating problem that DNSSEC was going to solve.

Re:SMTP MTA Strict Transport Security (MTA-STS) by wahern on Friday September 28, 2018 @06:57PM (#18097719)
> I think that, from a utilitarian perspective, the only mail servers that matter are the ones that Google and its peers run, and that's the threat model I care about.

I'd be surprised if Google doesn't already enforce TLS for other big peers like Microsoft. In your universe, what do we need a broken standard for?

> you require the radical centralization of all cryptographic trust on the Internet into a tree-shaped PKI

Web PKI isn't radically centralized? It's worse than radically centralized, because you can break Web PKI by attacking the weakest CA.

> it drives a stake through the heart of the last truly motivating problem that DNSSEC was going to solve.

MTA-STS may give people cover to pretend they don't need DNSSEC. But make no mistake: it doesn't actually solve the problem.

It's interesting that technical opinions of DNSSEC have devolved into such irrational hatred that people will openly proclaim that fake security is better than actual, DNSSEC-provided security. Yes, DNSSEC is complex. Yes, it has issues with network privacy. But those arguments don't redeem MTA-STS, which is fundamentally broken.

Re:SMTP MTA Strict Transport Security (MTA-STS) by tptacek on Friday September 28, 2018 @07:02PM (#18097730)
If we agree on the positive argument I don't think we have to resolve the normative one. I disagree with you on that, strongly, but do not expect to persuade you.
Re:SMTP MTA Strict Transport Security (MTA-STS) by gerdesj on Friday September 28, 2018 @08:51PM (#18098113)
The difference between your threat model and mine is that yours is based on concern for random people running small mail servers. I understand and respect that threat model, though I do not appreciate or really care about it.

Why should anyone be discriminated against based on the size of their mail server?

Re:SMTP MTA Strict Transport Security (MTA-STS) by pvg on Friday September 28, 2018 @10:07PM (#18098332)
Small mail server people got no reason to live.

  They got little hands
  And little eyes
  And they walk around
  Tellin' great big lies
That's why.