14 ms·

Making email more secure with MTA-STS standard

171 points by edmorley 7y ago

pwinnski 7y ago
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?
- pwinnski 7y ago
  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.
  - jcranmer 7y ago
    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.
    - shereadsthenews 7y ago
      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;
- tptacek 7y ago
  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.
  - pwinnski 7y ago
    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.
- shereadsthenews 7y ago
  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.
- LeonM 7y ago
  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 https://tools.ietf.org/html/rfc8461 [1] https://tools.ietf.org/html/rfc8460 https://tools.ietf.org/html/rfc8460 [2] https://www.mailhardener.com https://www.mailhardener.com
  - tptacek 7y ago
    It's great and unsurprising to see them adopting MTA-STS, since their name is on the RFC.
  - josteink 7y ago
    > 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
tptacek 7y ago
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.
- jcranmer 7y ago
  In theory, there is RFC 7929 and RFC 8162 [PGP and S/MIME keys over DANE], but I don't think DNS is the best way to expose that information. I also don't think anyone (important) actually supports these mechanisms to retrieve public keys.
- belorn 7y ago
  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.
  - tptacek 7y ago
    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.
eitland 7y ago
> 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+?
- ocdtrekkie 7y ago
  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-and-blogger.html https://blogger.googleblog.com/2019/01/an-update-on-google-a...
prolepunk 7y ago
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 https://news.ycombinator.com/item?id=18091690 There's this project that provides mta-sts implementation -- https://github.com/ldelouw/postfix-mta-sts-resolver https://github.com/ldelouw/postfix-mta-sts-resolver Has anyone used it and what is your experience?
- LeonM 7y ago
  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.
  - megous 7y ago
    > 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.
    - LeonM 7y ago
      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.
e12e 7y ago
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?
vkaku 7y ago
Yeah, they do complicated things like this, but leave out simple fixes like email accounts with dots in the address. If a Googler is reading this, yes, I have a real problem with Gmail.
- thepangolino 7y ago
  I think that’s a feature not a bug.
  - josteink 7y ago
    It’s non-standard behavior and open Gmail-users up for attacks. This has already been discussed many times on HN.
    - vkaku 7y ago
      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!
- kiwijamo 7y ago
  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.
  - vkaku 7y ago
    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.
thepangolino 7y ago
It boggles my mind how a client side proper and user friendly implementation of PGP has has always been dismissed as some silliness.
- lucb1e 7y ago
  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.
  - 0xb100db1ade 7y ago
    > 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!
    - anoncake 7y ago
      As a German, so would I. Because thats news to me.
    - lucb1e 7y ago
      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.
    - Leace 7y ago
      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 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.
svnpenn 7y ago
obligatory https://github.com/dominictarr/your-web-app-is-bloated https://github.com/dominictarr/your-web-app-is-bloated
LeonM 7y ago
> 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.
stonogo 7y ago
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.
- jsiepkes 7y ago
  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.
  - btown 7y ago
    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 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/ https://hstspreload.org/ . And all the criticisms of a preload list apply here. Still, this is much better than nothing.
  - stonogo 7y ago
    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.
vzaliva 7y ago
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.
- Waterluvian 7y ago
  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?
- LeonM 7y ago
  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).
  - OrgNet 7y ago
    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)
- sydli 7y ago
  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.
- elehack 7y ago
  Simple, non-evil answer: because it would severely impede spam prevention. This extensive writeup has details: https://moderncrypto.org/mail-archive/messaging/2014/000780.html 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.
dane-pgp 7y ago
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-you-posted-by/ 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 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-definition-requirements-penalties-best-practices-compliance-and-more https://digitalguardian.com/blog/what-nis-directive-definiti...
- spc476 7y ago
  Lovely, running my own email server could be punishable by jail time. And people bitch about the continuing consolidation and centralization of the Internet ...
  - Hello71 7y ago
    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.
  - dane-pgp 7y ago
    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.
ihonius 7y ago
.
garaetjjte 7y ago
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.
technion 7y ago
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".
- megous 7y ago
  > 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.
  - technion 7y ago
    Google's implementation guide says: Add a subdomain to your domain. This is consistent with my reading of the RFC.
  - icebraining 7y ago
    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.
  - kseistrup 7y ago
    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.
amaccuish 7y ago
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 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/ https://starttls-everywhere.org/policy-list/ [2] https://mta-sts.gmail.com/.well-known/mta-sts.txt https://mta-sts.gmail.com/.well-known/mta-sts.txt
- Snawoot 7y ago
  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).
lvh 7y ago
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.)
lvh 7y ago
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.)
- Snawoot 7y ago
  "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.
  - lvh 7y ago
    But why have that mechanism when HTTP already has a caching mechanism? Is it really "skip that HTTP request"?
    - Snawoot 7y ago
      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.
moocowtruck 7y ago
If there is one thing I am so happy I could cry about.. it's when I stopped managing mail systems.
upofadown 7y ago
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.
js2 7y ago
> 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 https://tools.ietf.org/html/rfc8461#section-3.4
zeroimpl 7y ago
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.
- hannob 7y ago
  DNS is usually not secure. DNSSEC is not deployed widely. End of story.
  - josteink 7y ago
    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.
    - zeroimpl 7y ago
      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.
    - dcbadacd 7y ago
      We have a standard for protecting DNS, but it's so bad - the tools are bad, the % of deployment is bad, the resolvers handle it bad, the ability for a regular sysadmin to deploy it is bad, it's just super bad compared to what we have with the HTTP PKI.
    - tptacek 7y ago
      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).
deleted 7y ago
[deleted]
shirro 7y ago
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?
- phicoh 7y ago
  From https://support.google.com/a/answer/9276511 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.
  - tptacek 7y ago
    This standard is nothing remotely like DNSSEC. It's a bottom-up key-continuity mechanism. DNSSEC is a top-down global PKI.
    - phicoh 7y ago
      From RFC 8461, Section 4.2: "The certificate presented by the receiving MTA MUST not be expired and MUST chain to a root CA that is trusted by the Sending MTA." (And Section 3.3: "During the TLS handshake initiated to fetch a new or updated policy from the Policy Host, the Policy Host HTTPS server MUST present an X.509 certificate that is valid for the "mta-sts" DNS-ID [RFC6125] (e.g., "mta-sts.example.com") as described below, chain to a root CA that is trusted by the Sending MTA, and be non-expired.") There is nothing bottom-up about this. Either you get a cert from CA trusted by Google, or you don't get any email from gmail.com. There is a lot that can be said about ICANN, but I prefer to trust those processes over making sure that my certs are trusted every random company that I need to receive e-mail from.
      - 7y ago
ge0rg 7y ago
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 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?

171 points by edmorley 7y ago

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?

pwinnski 7y ago
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.
- jcranmer 7y ago
  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.
  - shereadsthenews 7y ago
    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;
tptacek 7y ago
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.
- pwinnski 7y ago
  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.
shereadsthenews 7y ago
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.
LeonM 7y ago
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 https://tools.ietf.org/html/rfc8461 [1] https://tools.ietf.org/html/rfc8460 https://tools.ietf.org/html/rfc8460 [2] https://www.mailhardener.com https://www.mailhardener.com
- tptacek 7y ago
  It's great and unsurprising to see them adopting MTA-STS, since their name is on the RFC.
- josteink 7y ago
  > 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

tptacek 7y ago

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.

jcranmer 7y ago
In theory, there is RFC 7929 and RFC 8162 [PGP and S/MIME keys over DANE], but I don't think DNS is the best way to expose that information. I also don't think anyone (important) actually supports these mechanisms to retrieve public keys.
belorn 7y ago
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.
- tptacek 7y ago
  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.

eitland 7y ago

> 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+?

ocdtrekkie 7y ago
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-and-blogger.html https://blogger.googleblog.com/2019/01/an-update-on-google-a...

prolepunk 7y ago

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 https://news.ycombinator.com/item?id=18091690 There's this project that provides mta-sts implementation -- https://github.com/ldelouw/postfix-mta-sts-resolver https://github.com/ldelouw/postfix-mta-sts-resolver Has anyone used it and what is your experience?

LeonM 7y ago
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.
- megous 7y ago
  > 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.
  - LeonM 7y ago
    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.

e12e 7y ago

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?

vkaku 7y ago

Yeah, they do complicated things like this, but leave out simple fixes like email accounts with dots in the address. If a Googler is reading this, yes, I have a real problem with Gmail.

thepangolino 7y ago
I think that’s a feature not a bug.
- josteink 7y ago
  It’s non-standard behavior and open Gmail-users up for attacks. This has already been discussed many times on HN.
  - vkaku 7y ago
    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!
kiwijamo 7y ago
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.
- vkaku 7y ago
  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.

thepangolino 7y ago

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

lucb1e 7y ago
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.
- 0xb100db1ade 7y ago
  > 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!
  - anoncake 7y ago
    As a German, so would I. Because thats news to me.
  - lucb1e 7y ago
    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.
  - Leace 7y ago
    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 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.

svnpenn 7y ago

obligatory https://github.com/dominictarr/your-web-app-is-bloated https://github.com/dominictarr/your-web-app-is-bloated

LeonM 7y ago

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

stonogo 7y ago

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.

jsiepkes 7y ago
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.
- btown 7y ago
  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 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/ https://hstspreload.org/ . And all the criticisms of a preload list apply here. Still, this is much better than nothing.
- stonogo 7y ago
  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.

vzaliva 7y ago

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.

Waterluvian 7y ago
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?
LeonM 7y ago
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).
- OrgNet 7y ago
  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)
sydli 7y ago
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.
elehack 7y ago
Simple, non-evil answer: because it would severely impede spam prevention. This extensive writeup has details: https://moderncrypto.org/mail-archive/messaging/2014/000780.html 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.

dane-pgp 7y ago

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-you-posted-by/ 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 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-definition-requirements-penalties-best-practices-compliance-and-more https://digitalguardian.com/blog/what-nis-directive-definiti...

spc476 7y ago
Lovely, running my own email server could be punishable by jail time. And people bitch about the continuing consolidation and centralization of the Internet ...
- Hello71 7y ago
  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.
- dane-pgp 7y ago
  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.

ihonius 7y ago

garaetjjte 7y ago

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.

technion 7y ago

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".

megous 7y ago
> 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.
- technion 7y ago
  Google's implementation guide says: Add a subdomain to your domain. This is consistent with my reading of the RFC.
- icebraining 7y ago
  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.
- kseistrup 7y ago
  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.

amaccuish 7y ago

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 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/ https://starttls-everywhere.org/policy-list/ [2] https://mta-sts.gmail.com/.well-known/mta-sts.txt https://mta-sts.gmail.com/.well-known/mta-sts.txt

Snawoot 7y ago
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).

lvh 7y ago

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.)

lvh 7y ago

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.)

Snawoot 7y ago
"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.
- lvh 7y ago
  But why have that mechanism when HTTP already has a caching mechanism? Is it really "skip that HTTP request"?
  - Snawoot 7y ago
    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.

moocowtruck 7y ago

If there is one thing I am so happy I could cry about.. it's when I stopped managing mail systems.

upofadown 7y ago

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.

js2 7y ago

> 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 https://tools.ietf.org/html/rfc8461#section-3.4

zeroimpl 7y ago

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.

hannob 7y ago
DNS is usually not secure. DNSSEC is not deployed widely. End of story.
- josteink 7y ago
  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.
  - zeroimpl 7y ago
    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.
  - dcbadacd 7y ago
    We have a standard for protecting DNS, but it's so bad - the tools are bad, the % of deployment is bad, the resolvers handle it bad, the ability for a regular sysadmin to deploy it is bad, it's just super bad compared to what we have with the HTTP PKI.
  - tptacek 7y ago
    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).

deleted 7y ago

[deleted]

shirro 7y ago

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?

phicoh 7y ago
From https://support.google.com/a/answer/9276511 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.
- tptacek 7y ago
  This standard is nothing remotely like DNSSEC. It's a bottom-up key-continuity mechanism. DNSSEC is a top-down global PKI.
  - phicoh 7y ago
    From RFC 8461, Section 4.2: "The certificate presented by the receiving MTA MUST not be expired and MUST chain to a root CA that is trusted by the Sending MTA." (And Section 3.3: "During the TLS handshake initiated to fetch a new or updated policy from the Policy Host, the Policy Host HTTPS server MUST present an X.509 certificate that is valid for the "mta-sts" DNS-ID [RFC6125] (e.g., "mta-sts.example.com") as described below, chain to a root CA that is trusted by the Sending MTA, and be non-expired.") There is nothing bottom-up about this. Either you get a cert from CA trusted by Google, or you don't get any email from gmail.com. There is a lot that can be said about ICANN, but I prefer to trust those processes over making sure that my certs are trusted every random company that I need to receive e-mail from.
    - 7y ago

ge0rg 7y ago

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