This article is a disingenuous description of a lot of bad work. A more honest headline would be "Google making email more complex by introducing more protocols." Instead of just registering an SMTP-over-TLS port, now EVERY message requires an HTTPS lookup and a reconnection. That's not the intent, but the specification was so poorly written that it is the most common interpretation.

All of the input during the IETF draft phase was completely disregarded unless it came from a sponsoring corporation (all of whom are either Google or residential ISPs). This whole process is a shameful illustration of IETF process failure and I hope Google terminates it as readily as they do business units.

This comment is a lowbrow dismissal of important work. In the MTA-STS status quo ante, an attacker could break TLS and MITM SMTP transactions by forcing a protocol downgrade. That's an untenable situation, as would be a decree from the major mail providers that all mail must now be sent over TLS. The third alternative, widespread deployment of DANE, would be even more onerous for site operators, in addition to its unfortunate side effect of instituting a global PKI rooted in world governments.

There has been an SMTP-over-TLS port for ages. Obviously, that doesn't fix the problem, because a MITM attacker can simply RST connections to that port.

MTA-STS does not in fact require EVERY message to do an "HTTPS lookup and a reconnection".

Google is in a position where they could have disallowed protocol downgrades, setting a standard without defining a standard.

Ha, imagine the outcry in that case. It certainly would be even louder than this one.

There's nothing lowbrow about it; it's a technical objection to the protocol and a commentary on Google's socialization of a bad idea. I'll thank you to focus on the merits of the argument instead of trying to besmirch its character.

There is nothing untenable about "the situation," because the attack you suggest has never been spotted in the wild, targets one of the less-weak links in the SMTP chain (i.e. there is lower-hanging fruit), and finally comprise a false dichotomy between "MTS-STA" and "do nothing."

All MTA-STS requires is effectively fetching a domain name and port number over HTTPS, then DNS query as usual and connect to the port. Literally nothing is gained over simply securing the MX record delivery to start with, to the degree that when someone brought this up on the IEFT draft process the response was nontechnical -- "we think people already have an https endpoint" is not how you design a standard.

DANE exists, is only onerous to learn one time, and 'world governments' are how humanity operates, in case you haven't noticed. The fact that we currently have a global PKI rooted in huge corporations is not sustainable if you want an Internet that human beings are allowed to participate in. I acknowledge that this may be a fundamental disagreement in worldviews, but your preference for corporate rule over government rule is not the correct category of consideration for standards development.

There has not in fact been an SMTP-over-TLS port "for ages." There is not one now. There is a submission-over-TLS port for MUAs, and there is STARTTLS on port 25, but there is not an MTA-related SMTP-over-TLS port specified in any standard. STARTTLS is idiocy for obvious reasons beyond aesthetic layer violations, but the MTA-STS people declined to address in a technical manner their lack of support for SMTP-over-TLS port standardization, providing instead a set of assumptions about what other people might or might not know. Again, terrible. And again, exactly your argument here.

MITM attackers can RST connections to MTA-STS-specified ports just as well, and I question your implied assumption that MTA-STS somehow protects against this: it does not.

MTA-STS does not explicitly require every message to do anything; it requires MTAs to do all this legwork, and less wealthy operators can just pay for the bandwidth, right? Transport is free, of course -- at least if you were on the MTA-STS design committee.

Basically, every single defense of "MTA-STS" as a solution rests in the root of "we think fixing DNS is hard" and that is exactly the failure of vision I spoke about earlier. You've consistently expressed this view and I do not expect that you'll change your opinion, but copping out because things might be difficult is the wrong answer. Letting megacorps drive standards processes, rejecting every single attempt to collaborate that came from outside the ivory tower, and then telling us it's for our own good (because our poor little low-brow brains can't possibly fathom how nameservices work) is terrible, terrible policy.

MTA-STS is a failure of vision, a failure of process, and a failure of our industry. In the long run, it's a minor one, but it so purely and cleanly exemplifies the root causes of the de-democratization of the Internet that I feel strongly about calling it out as the failure it is.

I revise my criticism. What you're saying is (broadly) wrong, but it is not lowbrow. I apologize for the knee-jerk reaction.

I'm actually confused here. Stonogo is using enough detail that they sound like someone who understands the domain, but what they're saying is, in many cases, simply factually incorrect.

A few corrections:

1. MTA-STS does not specify ports. I don't even know where that comes from. Mail continues to be sent on port 25.

2. The claim that "nothing is gained over security the MX record to start with" is, again, simply untrue. DNSSEC alone does not solve anything, unless you also somehow validate the presented identity of the recipient MX--which is what DANE and MTA-STS attempt to provide. DANE arguably does this better (neglecting for now the debates about roots of trust and DNSSEC), but, to be perfectly clear, DNSSEC alone (or anything else that merely secures the MX record) does nothing to validate the recipient MX's identity (meaning you're vulnerable to e.g. BGP routing interception or other active MITM).

3. MITM attackers cannot merely RST connections to STS-specified ports. Among other reasons, because STS doesn't specify ports (meaning this criticism is nonsensical) but, assuming "ports" was supposed to read "hosts", because STS requires senders to validate the host's presented certificate. That's sort of the point of that.

I think the criticism here was written by someone who knows a lot of the context but seems not to understand the threat model. If you don't understand the threat model, yes, STS is going to look crazy.

I don't love MTA-STS. It's an imperfect compromise, which is sort of the nature of compromises. Stonogo does fairly contrast it with two alternative approaches: DANE (not just DNSSEC) and simply announcing a planned deprecation of unauthenticated SMTP (which, as an aside, would also require some currently-nonexistent principles on MX presented identities, like that the identity must match the @hostname of the destination mailbox--a constraint currently commonly violated).

But it's trying to solve an actual problem. And, as I said, the heart of the criticism here is simply factually incorrect, whatever warts STS does indeed have.

Is this work important because it displaces DNSSEC or because it’s the right solution?

It's important to me because it displaces DNSSEC, but it's important to everyone else because it cleanly and quickly breaks an attack that people were worried about without boiling the ocean or requiring universal deployment of some new goo. I am not especially worried about the attack it breaks, because I don't believe in SMTP security in the first place. But it is a sensible way to address that attack.

Using an TLS only port doesn't solve the problem. Since MTA's will be required to also offer the normal unencrypted interface there would still be no way to tell an other MTA that it should use TLS with you. An mitm attack can then simply block access to your dedicated TLS port and force use of unencrypted protocols.

This is the same for-me-but-not-for-thee response the ISPs gave during the draft spec. Assign a TLS port, deprecate the plaintext port, and set a date when unencrypted SMTP is noncompliant. It really can be that simple, especially in an environment where Google has already demonstrated a willingness to manipulate the standards process for its own purposes.

The reason HTTPS is being forced into this process is exactly because HTTPS has a specified standard TLS-only port. Now we're married to a web protocol to send email, and the entire broken commercial web-of-trust hegemony is trickling into email as well. Google already has an outsized influence on which certificates may be trusted, and now that influence extends to email, de jure as well as de facto.

This is fragile, needlessly complex design, and it's depressing as hell to see it so thoroughly defended by people championing hypotheticals.

The fact that the argument for MTA-STS boils down to "DNS is insecure and we don't want to fix that problem" and the solution boils down to "just do everything over port 443 instead" indicates a severe failure of vision at every phase of this process.

In addition to the fact that, had Google declared plaintext SMTP EOL'd, someone else would be here to tell us how that too was an instance of Google ignoring the operator and standards community, and the fact that there's no real effort in the IETF to formally end plaintext SMTP, there's the fact that simply refusing to interop with plaintext SMTP wouldn't actually fix the problem; it would just break SMTP into a bunch of incompatible islands, which is run by a myriad of different users who are not, for a myriad of reasons, in a position to upgrade their software stack to TLS.

> different users who are not, for a myriad of reasons, in a position to upgrade their software stack to TLS.

These people, who I am not convinced exist in 2019, would also be left behind by MTA-STS, which still requires participation in the commercial PKI pyramid of trust, TLS connections and all. What makes you think an entity that cannot tls-wrap their mail service can instead rewrite the mail service to issue web requests, parse the responses, and then reconfigure their MTA on the fly for each response?

Deprecating plaintext messaging is a perfectly achievable goal, and there's no real effort in the IETF to do so because every such effort is drowned at birth by the bizarre "just do everything over HTTPS" phalanxes.

> "DNS is insecure and we don't want to fix that problem"

This isn't an accurate description of the anti-DNSSEC worldview. It's "DNS is untrusted, this is not a problem, and we want to keep it that way." If you're going to argue against it I think you need to portray the opposing side accurately.

I'm not describing a worldview; I'm describing the actual responses from the MTA-STS team during the IETF draft process. They did not say they wanted to keep DNS untrusted, they said that they did not think network operators were capable of understanding DNS security, and so the MTA-STS chose a different approach to securing SMTP.

Yep - this spec outlines exactly how to tell another compliant MTA that it should use TLS with you, and how to detect (on subsequent connections) this type of MITM. https://tools.ietf.org/html/rfc8461#section-10 explains the threat model.

Of course, to thwart an MITM of an initial connection, you'd need something like https://hstspreload.org/ . And all the criticisms of a preload list apply here. Still, this is much better than nothing.

STS is built around cached policies. It does not require an HTTPS transaction per message. Since a very high fraction of all email is sent between the sponsoring organizations (Google, Yahoo, Microsoft, and the ISPs you mentioned) it is likely that the aggregate cache hit rate will be approximately 100%.

If so much mail is sent between the sponsoring organisations that the aggregate hit rate will be approximately 100%, then wouldn't approximately 100% of mail be sent over the TLS only port were the sponsoring organisations to decide to only use TLS among themselves (e.g. a hardcoded SMTPS everywhere list) ?

The point of an open standard is so that the vanishingly small fraction of people running their own mail servers can easily implement it too.

Yes, this is an instance where the giant email providers could simply have agreed among themselves not to allow SMTP TLS MITM attackers, and then left everyone to fend for themselves.

Maybe it is just me, but I get mail from lots of small organisations. Maybe the bulk volume of mail is handled by a few parties, but if I look at all mail I care about, there are lots of parties.

This is great news. It's worth noting: the subtext behind MTA-STS (actually made explicit at one point in the RFC) is that it works without DNSSEC and DANE, which major mail providers weren't adopting (for good reason).

Since breaking SMTP TLS MITM was one of the few remaining things DNSSEC could help with that didn't have answers in other protocols, this is a major blow to any impetus to roll DNSSEC out in the future. Between MTA-STS, DNS-over-HTTPS/TLS, and certificate transparency, I think DNSSEC is essentially moribund now.

MTA-STS is a Trust on First Use protocol (for those who has not read the RFC, check section "10. Security Considerations"). DANE with DNSSEC is not.

The benefits and drawbacks of TOFU is well known, and ssh is one where most administrators first get a feel for it. In this case however we don't even have any human validation, so it is blind trust on first use. Maybe future version of popular email servers will hardcode a initial certificate or policy for gmails and other major email provider, but that would be beyond the scope of MTA-STS.

The same people who push DANE and DNSSEC yesterday will continue to do it tomorrow. Adding caching and policy to starttls is good, and for major email provider the first use will be done once and a valid version will effectively remain in the cache forever since normal daily use will keep it up to date. This scenario might not be as applicable to say a lawyer firm who for security reasons run their own email server, where a larger potential number of cases the initial email is the first time one email server connect to the other.

The advantage of key continuity (the better term than "TOFU") over top-down PKI is that key continuity works at scale, and PKI does not. As you note: key continuity schemes admit to straightforward enhancements, like preload registries, that PKIs don't.

I don't really want to go too far down this rabbit hole, but if a lawyer firm came to us for advice and told us they run their own mail server "for security reasons", we would tell them for security reasons to stop doing that.

Yes, people will continue advocating for and noodling around with DNSSEC, the same way they do with PGP key servers and custom cipher cascades. But that's not the test for whether a technology is successful --- at least not these kinds of technologies. It is looking less and less likely --- I'd say we're past the event horizon now --- that DNSSEC will ever be a mainstream component of the Internet security model.

We have had a similar protocol for TOFU on the web for a very long time called HTTP Public Key Pinning, and it did nothing to deprecate PKI. It is a bit telling that google actually removed HTTP Public Key Pinning in 2017 from chrome.

I can't speculate if DNSSEC can continue grow or will fall in use in some unspecified future, but I suspect that a TOFU version of key pinning for email server won't be the death knell. If it work it is because the wast majority of email traffic is located in basically a handful of companies, which is why the wast majority of domain owners won't notice a difference. I would assume Microsoft already pins the certificate of Google servers and vice verse.

I'm not saying that global key continuity schemes always work, only that they have worked (SSH is the best-known example), where global PKI schemes have never once worked.

Late edit:

But note: Google didn't follow up the deprecation of HPKP by promoting DANE. Rather: CT is working, and given that, HPKP wasn't worth the hassle. CT doesn't depend on DNSSEC either!

>(SSH is the best-known example), where global PKI schemes have never once worked.

I’ve seen PKI work for SSH in $large-gov-branch. It works just fine but it requires a cert infra most orgs don’t want.

PKIs certainly work in enterprise settings.

If we look at gmail's current policy: version: STSv1 mode: testing mx: gmail-smtp-in.l.google.com mx: *.gmail-smtp-in.l.google.com max_age: 86400

Then if somebody can take over the domain google.com they immediately start receiving mail for gmail.com. If you can take over gmail.com you may have to wait for a day.

The classical argument against DNSSEC (the governments are in control) applies just as much to MTA-STA.

Why is there no love for DNSSEC and DANE?

Google [against dnssec].

> SMTP is therefore vulnerable to man-in-the-middle attacks. Man-in-the-middle is an attack where communication between two servers is intercepted and possibly changed without detection.

While it's true that MTA-STS can protect email in transit from downgrade attacks, it is not intended to prevent changes to email content. In fact, even with perfect MTA-STS adoption it still won't prevent the MTA itself from changing the message contents (the message passes through every MTA unencrypted).

If you want to protect the authenticity of your email, use DKIM. If you want to prevent MTA's from stripping the DKIM header, use DMARC.

Google also uses ARC to sign messages, but that's not end-to-end like DKIM is.

For the record, Gmail already includes an indication for when an email wasn't received (or won't be sent) using TLS:

https://blog.google/products/gmail/making-email-safer-for-yo...

and currently this applies to roughly 5% of emails:

https://transparencyreport.google.com/safer-email/overview

It would be nice to get this number down to zero, across all email providers, perhaps by some combination of harsher warnings in the UI, penalising the deliverability of insecure messages, and even legal action.

In terms of the latter, I note that the EU's recent NIS Directive could potentially lead to such actions being taken:

https://digitalguardian.com/blog/what-nis-directive-definiti...

Lovely, running my own email server could be punishable by jail time. And people bitch about the continuing consolidation and centralization of the Internet ...

You're welcome to run your own insecure email server, but don't expect other mail servers to connect to it, or accept connections from it.

Also, don't allow other people to send or receive email from that server unless they have given you their informed consent that it does not meet the basic industry standards for security.

Sure, and servers should refuse to connect and deliver mail to gmail.com addresses without consent from the recipient that their email can be read by Google employees and any government with the jurisdiction to compel them since they don’t offer email encryption.

Your definition of “basic industry standards for security” is not the same as others who are serious about security and it’s not the same as people slinging birding newsletters.

The fact that legal action to fit your taste is being suggested is pretty tone deaf.

You're just strawmanning now.

First, the parent said nothing about jail time. Unlike what many Americans think, incarceration is not the only penalty that can be imposed by the government.

Second, there are already legal penalties for certain types of misconfiguration. For example, if you run an open proxy, or public file server, you could already be punished for transmitting or storing illegal content. However, most governments worldwide have at least a modicum of sense, and do not mete severe punishment (e.g. incarceration) for obvious mistakes.

> When sending mail to a mailbox at a subdomain, compliant senders MUST NOT attempt to fetch a policy from the parent zone. Thus, for mail sent to "user@mail.example.com", the policy can be fetched only from "mail.example.com", not "example.com".[0]

That's not great for those of us who like to use Fastmail's anything@user.example.com feature.

This specification also doesn't work well for those who run their own SMTP servers and who are less likely to have cached policies. Meanwhile, the big email providers could hard-code a list of the other big email providers and never downgrade when talking to them (as I imagine they already do).

So who's this spec for, then?

0. https://tools.ietf.org/html/rfc8461#section-3.4

I'd like to be wrong, but with the nature of this standard, I don't expect heavy adoption. If a person is deploying G Suite or Office 365 or similar, they get asked to setup MX records, TXT for SPF, possibly DKIM and so on. If I could create a record that says "use the policy Microsoft/Google publish", it would be a no brainer. And it would take off because, much like SPF, these groups can just add it to their onboarding checklist.

As soon as you say "deploy an end point on your domain", it falls in the too hard basket for unimportant domains. Moreover, in a corporate situation the people running mail have no involvement in web endpoints. For the mail domains I professionally manage, that falls into the domain of another department, and the people involved in running web endpoints are going to say something like "if it was important, Wordpress would do it already for us".

> The Policy Host DNS name is constructed by prepending "mta-sts" to the Policy Domain.

All the adopter has to do is set:

  mat-sts.his-domain A IP-OF-MAIL-HOST

or

  mat-sts.his-domain CNAME HOST-NAME-OF-MAIL-HOST

And the mail hoster can take care of the reset, including getting a certifiacte for mat-sts.his-domain, and hosting a web server.

It's just more DNS records.

You also have to set

    _mta-sts.his-domain TXT "v=STSv1; id=[POLICY VERSION ID];"

And you have to update that ID every time the policy hosted on the web server changes.

It is very poor practice to use CNAME for things like this. In the example above, mat-sts.his-domain will inherit any records of his-domain: A, AAAA, MX, and what not.

Don't use CNAME for this.

Google's implementation guide says:

   Add a subdomain to your domain.

This is consistent with my reading of the RFC.

My issue would be that even if "gmail use it", people using G Suite with custom domains probably aren't.

I deployed this a few days ago using postfix-mta-sts-resolver in docker, spun up an nginx server to handle the txt file, and added the dns txt record. Fairly straightforward. I'll keep an eye on my logs and see if it changes anything.

I also note that google is in the starttls-policy [1] list in testing mode (they're also on testing, not enforced, for mta-sts on gmail.com [2])

[0] https://github.com/Snawoot/postfix-mta-sts-resolver (this is more up-to-date than the PyPI package)

[1] https://starttls-everywhere.org/policy-list/

[2] https://mta-sts.gmail.com/.well-known/mta-sts.txt

If you are concerned, for both MTA-STS and STARTTLS-Everywhere you may use enforcing policy even against domains in testing mode at the cost of small possibility of delivery failure.

postfix-mta-sts-resolver has config option strict_testing: true

starttls-policy-cli has Early Adopter mode of config generator (-e, --early-adopter).

I don't get this standard. Why have a https lookup of policy. I have a signed dns. I publish information about services and trust on there. Why don't google just accept dnssec or if they think it is broken then fix it. I have dnssec with tlsa, caa, spf, dmarc, dkim already in my dns. Now I need to maintain a file on a web server as well?

From https://support.google.com/a/answer/9276511

version: STSv1 mode: testing mx: mail.solarmora.com mx: *.solarmora.net mx: backupmx.solarmora.com max_age: 604800

It is just fascinating how people who dislike DNSSEC are recreating it over HTTPS. Poorly, because unlike DNSSEC, this has obvious downgrade attacks.

In the end you have to trust DNS anyhow, because if you control someone's DNS, getting a letsencrypt cert takes only a few seconds.

This standard is nothing remotely like DNSSEC. It's a bottom-up key-continuity mechanism. DNSSEC is a top-down global PKI.

No, it's bottom-up in that it's deployed at endpoints and does not require universal deployment, or root-to-branch continuity, in order to function. DNSSEC requires a global PKI, with cryptographically signed delegations from the DNS roots through TLDs run by governments all the way to every involved system; it's only been in the last 10 years that it has even been technologically possible to accomplish this (MTA-STS could have been deployed in 2005).

MTA-STS doesn't prevent non-TLS SMTP servers from functioning; all it does is ensure that if you have TLS, that attackers can't strip it.

If you have enough faith in ICANN to vest control of Internet trust in them, that's, well, you do you.

DANE doesn't require universal deployment of DNSSEC either. The sending mail server only needs DNS resolvers that are transparent to DNSSEC. Which is just about everything. And you can also run a modern recursive resolver on mail server itself if you are behind an old one.

DANE does not prevent non-DNSSEC or non-TLS SMTP servers from functioning. And of course, it actually prevents MITM attacks from stripping TLS.

Just about every 'government run' ccTLD is DNSSEC signed. There is nothing that prevents a site from using DNSSEC.

The gTLDs are not government run. There is no government involvement in google's TLD (.google). And because of ICANN rules, .google is actually DNSSEC signed.

So can we use DNSSEC for email today. Everything is in place and if you don't like governments, stick to gTLDs.

Ostensibly, you're saying, not all of the gTLDs are government run. Of course, the most important TLDs are in fact run by governments, in particular the FVEY SIGINT governments and China.

.GOOGLE is "actually DNSSEC signed", but, of course, GOOGLE.COM (and GMAIL.COM) --- the domains that actually matter --- aren't.

My purpose on this subthread isn't to litigate DNSSEC, but rather to back up the rather straightforward observation that MTA-STS is a bottom-up point solution that doesn't depend on the deployment of a global PKI, and that DANE is the opposite of that. The two aren't comparable. As I said, MTA-STS could have been deployed in 2005, or, for that matter, all the way back into the Netscape TLS days.

Since the purpose of MTA-STS is to avoid DNSSEC (that's not my observation, it's stated directly in the RFC), and the standard's foremost and first adopter is Google, which, like virtually every major tech company excepting Cloudflare (which sells DNSSEC services), does not use DNSSEC, I think we can safely predict that we will not be using DNSSEC for email today.

Maybe you can expand a bit on how the receiving MTA can have certificates (both for the HTTPS part and the SMTP-TLS part) that are signed by a CA trusted by the sender?

Currently we have only one system for doing that (at scale) and that is the current global PKI system. The situation would have been much worse 10 years ago because many organizations were not using HTTPS at the time, partly because obtaining certificates was expensive and a lot of work.

DNSSEC has a single root which is recognized by everybody doing DNSSEC.

In contrast, the collection of TLS CAs is only losely defined. For example, there is a java application that I use. The java libraries do not recognize the CA used by the Dutch government. So after each update of the libraries, things start failing again. We can expect the same for MTA-STS unless everybody sticks to the CAs that are trusted by common browsers.

Bottom-up security doesn't work on a global scale. It somewhat works for ssh, because that is mostly local. It completely fails to work at scale for pgp.

At this point I'm just happy to see we're on the same page about MTA-STS being a bottom-up mechanism. I don't really care whether you think it will work well. MTA-STS addresses a problem I myself don't much care about (I'm convinced email security is an oxymoron). I'm interested in it primarily for the signal it sends about major providers intentions with respect to DNSSEC.

If you are likely to be attacked by an entity that can do a MITM between email servers, you are already well beyond the level of threat where you need to encrypt end to end. This isn't very interesting.

Can somebody explain why this couldn't be as simple as adding a DNS TXT entry which says to use TLS for a specific domain? Then add a large TTL on this DNS entry so it can be cached for a week or more.

If it was that simple, I'd turn this on now.

DNS is usually not secure. DNSSEC is not deployed widely. End of story.

All security of everything on the internet relies on DNS.

If the problem is that DNS isn’t secure, nothing is, and DNS should be fixed first instead of fucking up every other internet protocol instead with crappy bandaids. That’s just obvious engineering.

The people behind this spec are obviously incompetent or have ulterior motives.

Virtually none of the security of the Internet depends on the security of the DNS; not depending on DNS for security has been an explicit design goal of Internet cryptography since the mid-1990s, which is, for instance, why IPSEC and DNSSEC evolved separately (DNSSEC was a DoD project spearheaded by TIS).

Yes, I don't see how this MTA-STS avoids the DNS security issue. The system first uses a DNS TXT record to indicate a policy exists, then uses HTTPS to fetch that policy.

Thing I don't understand about the MTA-STS spec and glossed over until someone pointed it out to me: there's both an `id` in the DNS record (which is supposed to refer to the specific policy uniquely, but can be anything e.g. a hash or an incrementing identifier) _and_ the policy itself has a max_age. I don't quite understand why the max_age itself isn't sufficient, since that does expiry anyway? (The stated reason is preventing an HTTPS lookup, but HTTP already has a fine cache mechanism so that sounds like a potential false economy.)

"Cache" term in MTA-STS is misleading. Standard encourages to fetch new policy even before expiration of cached copy. If you have some cached policy and "id" is not updated since then, you may skip actual request to policy server via HTTPS.

In MTA-STS "cache" is more like fallback minimum known to sending party.

But why have that mechanism when HTTP already has a caching mechanism? Is it really "skip that HTTP request"?

RFC 8461 Section 3 states:

"These TXT records additionally contain a policy "id" field, allowing Sending MTAs to check that a cached policy is still current without performing an HTTPS request."

So, yes, it is "skip that HTTP request".

Despite HTTP(S) has caching rules defined, they are just different from "caching" logic incorporated in MTA-STS. Key differences are: 1. Sending party ought to update MTA-STS policy for recipient domain far before it expires. 2. Sending party can check if policy is still actual without direct contact with policy server by mean of retrieving id in TXT record. That significantly reduces amount of requests policy server has to serve in order to keep all senders up to date with its latest STS policy. Normally, HTTPS requests occur only once from each sender per policy version. 3. Sending party must reuse cached policy if STS policy of recipient suddenly disappeared without trace or failed to fetch for other reasons.

In a nut shell, "cache" and "max-age" in MTA-STS has different interpretation than in HTTPS and require some additional (obscure) logic for processing.

So this obviously doesn't solve the initial-connection issue (where it relies on untrusted DNS for discovery... if only we had DNSSEC).

But for later connections, it is essentially defining a caching of:

- a boolean flag that a trusted certificate is to be used

- a flag whether violations are to be reported to an endpoint obtained from untrusted DNS

- a maximum age of this "policy"

how is it superior to:

- just querying / dumping this policy as informational headers after STARTTLS (possibly guarded by a new EHLO feature)

- TLS TACK (https://tools.ietf.org/html/draft-perrin-tls-tack-00), which is kind of abandoned, but is an equivalent to HSTS, just at the correct layer

and how does it solve the problem that even if you have a policy defined, a MitM attacker can just redirect all policy reports with a very-long-lived _smtp._tls.example.com DNS record pointing to their own property or to nowhere?

There's a lot to like here, but two things I wish were different:

> MTA-STS policy suggestions in the security center are available to G Suite Enterprise and G Suite Enterprise for Education customers only.

MTA-STS policy suggestions do not seem like a serious differentiator for Enterprise GSuite.

Secondly: it'd be awful nice for ease of deployment if GSuite would just like, host that policy file for me? That way I still need to set 2 records (the TXT record and a CNAME), but at least I'm not in the business of hosting HTTP.

(I imagine what this will look like is a Terraform module.)

MTA-STS only helps when the providers on both end use it. This post doesn't seem to say: will there be anything in the interface to indicate whether a message transmitted via MTA-STS or not?

A message is not 'transmitted via MTA-STS', it is transmitted via SMTP that uses TLS (SSL) to secure the connection between mailservers.

MTA-STS [0] is a method to publish a policy on whether email servers (known as Mail Transfer Agents, or MTA's) are allowed to use insecure (non-TLS) connections for email from your domain.

MTA-STS is needed because the system to deliver email over the internet (SMTP) has a fallback method where it will switch to an unencrypted connection if the encrypted connection fails for some reason. By blocking a encrypted connection in the middle, an attacker can force a mailserver to fall-back to a non-encrypted connection. This way the attacker can intercept the message in transit. This is known as a downgrade attack. Some governments are known for doing this.

So, MTA-STS prevents downgrade attacks (to a certain extend, because the MTA's that your email passes through must support it).

There is also a new proposed standard called TLS-RPT [1] that allows for reporting the usage of TLS, so you know if your MTA-STS policy caused an email delivery to fail.

At Mailhardener [2] we are working on hosted MTA-STS and TLS-RPT integration (both features are still in closed beta for now). It's great to see Gmail adopting MTA-STS, as this will accelerate adoption globally.

[0] https://tools.ietf.org/html/rfc8461 [1] https://tools.ietf.org/html/rfc8460 [2] https://www.mailhardener.com

It's great and unsurprising to see them adopting MTA-STS, since their name is on the RFC.

> MTA-STS is needed because the system to deliver email over the internet (SMTP) has a fallback method where it will switch to an unencrypted connection if the encrypted connection fails for some reason.

I couldn’t possibly see any simpler way to solve this very basic problem.

/sarcasm

If I understand your question (I might not):

MTA-STS works the same way HTTPS-STS works: you cache the lookup result and remember it for future transactions. This is a pretty powerful feature in HTTPS (it more or less breaks "SSL stripping" without requiring users to actually do anything), and the relationships between MTAs are far more stable than those between browsers and web servers, so you'd expect the potency of STS to be proportionally improved.

If you're asking more generally about who's going to adopt STS, the RFC was cosponsored by essentially all the major mail providers. This is likely to be a universal standard in the coming years.

I was thinking more about how it would be indicated in headers (or the interface), but yes, you've helped me understand this better. Thank you.

A message isn't "transmitted with" MTA-STS. MTA-STS allows you to publish policies that others consume when sending and receiving mail.

If you are concerned that your mail to or from your gsuite domain might be sent without TLS encryption and authentication you can require TLS in your admin console. Traffic without TLS will bounce at the SMTP boundary of Gmail.

Answering my own question: For messages sent today from a Google Apps account to a gmail account, I see that instead of "mailed-by: <domain>", there are now two new headers: "signed-by: <hostname>" and "security: Standard encryption (TLS)" with a link to learn more.

This seems to be about S/MIME support, not MTA-STS support.

In general, with email headers, you cannot trust any of them. The one exception is the Received header added by your MTA, and perhaps other headers if you know your MTA adds them and you know that it will strip any that appear in the original message.

You can verify the authenticity of any header that appears in the DKIM signature. That's why you see things like this in the signature:

  h=mime-version:from:date:message-id:subject:to:x-original-sender
         :x-original-authentication-results:precedence:mailing-list:list-id
         :list-post:list-help:list-archive:list-unsubscribe:list-subscribe;

It boggles my mind how a client side proper and user friendly implementation of PGP has has always been dismissed as some silliness.

In the current day of multi-device users, I'm not sure a "user friendly implementation of PGP" can ever exist.

People want their email on their phone, on their laptop, and on their tablets. They want to keep those emails when they get a new phone, or lose their phone, or it gets smashed.

But most importantly, people want others to be able to know that others can read their email, and unless the people you are emailing know how to decrypt PGP encrypted email (or use the same client as you), they'll just get a mess, possibly with instructions on extra steps they need to take to decrypt it. And when you (in practice) are only able to email people using the same client, might as well just pivot the product into a secure messaging system like Signal or Telegram.

And that's not even getting into the amount of work and discipline something like PGP needs to work. Did you lose your master key? well you're fucked, might as well start over new and convince everyone you have ever talked to that you are still the same person.

People generally aren't against PGP because it doesn't work or the security isn't good enough, they are against it because it's complicated and difficult and punishes mistakes hard.

To most people, perfect security is useless if the average joe can't use it. Perfect security is useless if it requires constant diligence from users to prevent mistakes which in effect delete every bit of data you have. Perfect security is useless if you need to use out-of-band secure signaling in order to setup a secure channel.

That is why PGP is being dismissed. Because no matter how many coats of lipstick you put on that pig, at the end of the day it's a complicated, damn near user hostile program that punishes mistakes. And it's really fucking hard to make a "user friendly implementation" of something that will instantly and irrevocably destroy all of your communication the first time you lose your phone, or you have a house fire, or a theft, or any other number of things.

>Perfect security is useless if you need to use out-of-band secure signaling in order to setup a secure channel

I have bad news for you. This is the entire foundation of https. Those root certs aren’t there by magic.

Depends on where you are. As a Dutchman that moved to Germany, in NL it's somewhere between geeky and annoying for the recipient when you use PGP, whereas when communicating with potential employers in Germany, it's not even talked about. It's just the standard thing to use.

Since I've moved, every time I see PGP being dismissed as too hard to use, I feel like I'm back in some echo chamber where people just keep repeating that and start to believe it.

> when communicating with potential employers in Germany, it's not even talked about. It's just the standard thing to use.

Did I read that correctly? PGP is popular in Germany?

If so, I'd love to hear more please!

Curse of knowledge - I forgot that it's not obvious that I'm a security person! Should have mentioned that!

So yes it's popular... in the security community. In the Netherlands, it was also used, but usually reluctantly when the other party asks for it and it cannot politely be refused.

GnuPG is developed by Werner Koch that's German, there are a lot of German startups that work on PGP too (e.g. https://www.cotech.de).

I also used PGP to communicate with customers from Germany but it's not that every German customer of mine uses it.

As a German, so would I. Because thats news to me.

I think it is true that PGP is too hard to use for the majority of users. Any kind of end-to-end encryption practically prevents a web interface, since decrypting in JavaScript is little better than decrypting at the web server.

I’ve been thinking a lot about secure, end-to-end encrypted email replacements and have grappled with many of the same questions that Open Whisper Systems (the makes of Signal) had to think about. A centralized solution favors convenience, and will likely bolster adoption, while a decentralized solution will probably be harder to use and so won’t build its critical mass of users.

The person who comes up with a distributed, decentralized, end-to-end encrypted email-killer receiving broad adoption deserves some kind of very prestigious award.

It doesn't have to be JavaScript. In my immediate family and colleagues, everyone uses either Thunderbird or, in cases of my dad, MS Outlook. Some friends use webmail, but nevertheless, an open source client is super common. An addon can do pgp there.

Which is not to say it's not too hard. As my parents age, I notice their capacity for understanding new things decreases. It's not just technology, also games with new logic that they haven't seen before takes a while to grasp. Sometimes I feel like I'm talking to a four year old except that they understand and remember everything that existed 20 years ago. How they are ever to understand the concept of encryption, I don't know, let alone find the buttons to import a key from key servers.

For people below ~50yo, however, enigmail shouldn't be beyond them. The issue is that they don't know why they should care and therefore don't take the time to learn what it is.

It's not an echo chamber, PGP is hard to use, especially for the layman who would benefit the most from it.

So now to send email over SMTP it is required to host policy on.. HTTPS server? (or else all your mail will end up in spam?) Why it isn't just extra TXT DNS record indicating that TLS is required?

EDIT: I think DANE TLSA records are already doing that.

So, this is require-tls-on-first-ns-lookup? If dns isn't mitm'd, you'd get a flag requiring tls;this can/should be cached - and fallback to plaintext smtp (no tls) be disabled? Is that the gist?

I do not understand why for over a decade Google resists implementing end-to-end encryption in Gmail.

For example, it would help with "man-in-the-middle" attacks they are citing as motivation from MTA-STS.

Because there is no practical method to do so. Email was never designed to be end-to-end encrypted and implementing end-to-end encryption would mean that everybody must switch to an end-to-end encryption capable protocol.

Google is not resisting, they would implement end-to-end if they could, but they can't.

FWIW: As long as the email does not leave Google (i.e. an email between 2 gmail inboxes) it is actually already encrypted end-to-end (AFIAK).

They could easily do it for communications between gmail users... they just don't want to do it.

> FWIW: As long as the email does not leave Google (i.e. an email between 2 gmail inboxes) it is actually already encrypted end-to-end (AFIAK).

no, end-to-end means from user1-to-user2, not from user1-to-gmail and then from gmail-to-user2 (ie: gmail should never be able to see the content of your communications if it was truly end-to-end)

Simple, non-evil answer: because it would severely impede spam prevention. This extensive writeup has details: https://moderncrypto.org/mail-archive/messaging/2014/000780....

Long story short, to control spam, you basically have 2 options:

1. Control who can send messages 2. Inspect message content 3. Impose costs

Signal and WhatsApp chose (1). E-mail (and probably any federated protocol) requires (2) or (3), and there is no universally-adopted (3) for e-mail.

Their business model is to mine your mail. Spam censorship is just a feature that happens to fall out.

Just call it "sentiment analysis". Forgive me if I don't take their words at face value.

If they can't currently or in the future sniff out things about the content of your email, what's the point of gmail as a product?

even with e2e email like pgp or s/mime, a lot of email metadata (even subject lines, commonly) gets leaked onto the wire. improving transport security prevents that.

> Post a Comment

> You are welcome to contribute comments, but they should be relevant to the conversation. We reserve the right to remove off-topic remarks in the interest of keeping the conversation focused and engaging. Shameless self-promotion is well, shameless, and will get canned.

> Note: Only a member of this blog may post a comment.

Another victim of Goolge+?

It looks like they're using Blogger's commenting system at the moment.

EDIT: It looks like this happened automatically, according to https://blogger.googleblog.com/2019/01/an-update-on-google-a...

This looks a lot like SPF.

I've been looking if this has been implemented in Postfix and I found a past HN thread on it -- https://news.ycombinator.com/item?id=18091690

There's this project that provides mta-sts implementation -- https://github.com/ldelouw/postfix-mta-sts-resolver

Has anyone used it and what is your experience?

MTA-STS is nothing like SPF.

SPF is a method to publish a policy on which senders are allowed to use your domain so send email.

MTA-STS is a method to force MTA's to only use and accept TLS encrypted connections when handling email send from your domain.

The MTA-STS resolver you linked to is used to implement MTA-STS capability in Postfix MTA. It's intended for MTA administrators. You don't use the resolver to setup MTA-STS for your own send email, for that you must setup a DNS record and a HTTPS enabled webserver.

> MTA-STS is a method to force MTA's to only use and accept TLS

It's still advisory information, like SPF. The other end has to implement it.

That is correct. SPF, DKIM, DMARC, MTA-STS and TLS-RPT are all opt-in features for the receivers.

One could say that email is the ultimate legacy product of the internet.

I have a Gmail account with a dot in it. Works just fine. Yes you can leave off the dot and/or add more dots. But there is nothing broken about that.

It works fine, except when it doesn't. They let another guy sign up with dots and I get his emails, letters from his girlfriend, bank statements and what not.

And at some point, they stopped doing these erroneous signups.

But I still keep getting these emails because they strip all the dots and relay them. This is just terrible.

I don't care about the -4 as much as I care about someone understanding how serious this issue really is.

I think that’s a feature not a bug.

It’s non-standard behavior and open Gmail-users up for attacks.

This has already been discussed many times on HN.

It's per the RFC standard but it cannot be blindly followed in Gmail due to their signups issue.

Yes, they did allow A.B@gmail.com and AB@gmail.com to sign up, and each of these is mapped to a different Inbox. And an email that goes to A.B@gmail.com also goes to AB@gmail.com.

And yes, this opens Gmail users for attacks, phising amplification and much more!