3 ms·

Per the RFC, MTA-STS policy "presence and current version are indicated by a TXT record at the Policy Domain. [...] To discover if a recipient domain implements

by wahern 8y ago

Per the RFC, MTA-STS policy "presence and current version are indicated by a TXT record at the Policy Domain. [...] To discover if a recipient domain implements MTA-STS, a sender need only resolve a single TXT record." It doesn't remove the need for DNSSEC. Reading elsewhere in the RFC you find this gem: "the mechanism described here instead relies on certification authorities (CAs) and does not require DNSSEC, at a cost of risking malicious downgrades." So, basically, you use MTA-STS to prevent malicious SMTP TLS downgrades, but it doesn't actually prevent malicious downgrades unless you use DNSSEC. At least everybody has an excuse, now, to add an HTTP client to their mail transfer agent. Plus, now you get to duplicate MX information in two places, DNS and the WWW, even though it would have been trivial to declare STARTTLS as required in the TXT record.

tptacek 8y ago
The primary motivation of MTA-STS is to provide a mechanism for domains to ensure transport security even when deploying DNSSEC is undesirable or impractical.
- deleted 8y ago
  [deleted]
- Sephr 8y ago
  Motivations are important, but your response does not address the technical issues brought up by the parent comment. Initial discovery uses DNS, so wouldn't uncached hosts still be vulnerable to downgrade attacks without DNSSEC? MTA-STS seems to suffer from some of the same issues facing HPKP.
  - tptacek 8y ago
    DNSSEC advocates also believe DANE is needed to address the weaknesses in things like HPKP and HSTS. Of course, nobody else does, no mainstream browser implements DANE, and at least two have attempted to support DANE and then withdrew that support.
- wahern 8y ago
  Except in the absence of DNSSEC it does not ensure transport security. An attacker positioned to perform a MITM of an SMTP session is also positioned to MITM DNS requests. It's also worth mentioning that even if you skipped TXT querying and went straight to querying mta-sts.example.com, the attacker can just drop the A or AAAA record for mta-sts.example.com. The only way to prevent this is to use DNSSEC, which can sign negative answers. There is the benefit that if a policy is already cached the attack shouldn't work until expired. But much like SPF and similar issues, misconfigurations are so common I'd bet many transfer agents will still fail open if no TXT record is found (i.e. assume it's been disabled). In most organizations (and even small ones), the people or processes for managing DNS and e-mail are separate from WWW. With MTA-STS, when e-mail stops flowing people are going to have to check that their web sites (servers, proxies, etc) are setup properly. That's not at all obvious and will result in a lot of persistently broken systems. Senders are likely to put in mitigations because "it's not our fault" isn't always an acceptable answer. Plus, if you can MITM you can just drop connections until the policy is expired. MTA's will cache for days; policies like these usually have expiration times on the order of minutes or hours so that one can quickly and easily fix broken configurations. The DNS TXT version + HTTP policy max_age is a very awkward mechanism. IT departments will not understand this stuff well enough to use it as intended. The wording in the RFC that policy max_age should be on the order of weeks is just them papering things over. The whole thing sounds like they got mid way through a design predicated on using HTTP+TLS policies (the bright idea) before realizing how untenable things were, but stayed committed nonetheless.
  - tptacek 8y ago
    The difference between your threat model and mine is that yours is based on concern for random people running small mail servers. I understand and respect that threat model, though I do not appreciate or really care about it. On the other hand: I believe email is a technological dead end, and that we are not evolving towards an Internet with a more distributed email system, but with less distribution. I think that, from a utilitarian perspective, the only mail servers that matter are the ones that Google and its peers run, and that's the threat model I care about. In my threat model, MTA-STS basically eliminates the concern DNSSEC/DANE addresses. Since your threat model includes rarely-used independently-operated servers (note that mine includes things like Fastmail and Proton!), servers that won't have cached assertions, MTA-STS is inadequate for your needs. The problem I have with your argument is that to fix your problem, which is an extreme niche, you require the radical centralization of all cryptographic trust on the Internet into a tree-shaped PKI whose roots and trunks are controlled by world governments and whose technical underpinnings date back to the 1990s. Even if I was to stipulate that you had a point, DNSSEC wouldn't be a viable answer to it. But that's a normative argument, and my point about DNSSEC being done is positive, not normative: deployment of MTA-STS is going to end DNSSEC. Not because I want it to (though I do) or because it should (though it should) but because it will: it drives a stake through the heart of the last truly motivating problem that DNSSEC was going to solve.
tedunangst 8y ago
But now we have dns over https too?
- wahern 8y ago
  Wake me when we have DNS over HTTPS for anything except web browsers. Plus, someone running an MTA is very likely running a recursive DNS server on the same network, if not the same machine, that uses UDP or TCP for upstream queries. Anyone positioned to MITM SMTP is likely positioned to MITM DNS. EDIT: Ah, perhaps you meant that with DNS over HTTPS, MTAs will need an HTTP client anyhow. IMO the path of least resistance will be adding HTTPS, DNSSEC, or w'ever to machine-local resolver services. But point taken (whether earnest or sarcastic =)
  - tedunangst 8y ago
    Some sort of secure channel DNS seems likely to trickle down. Especially since an MTA is already well past getaddrinfo. And STS already requires https (which I do find kind of weird). So all the heavy lifting code of some form of secure DNS is here.
  - damm 8y ago
    All it takes is someone updating the glibc resolver function to handle DoH. Then update /etc/resolv.conf with your DoH option or old legacy.. ... Not a fan of DoH but it doesn't matter if I like it.
microcolonel 8y ago
Did I miss something that made MTA DNS resolvers a target of spoofing? I don't see how a vaguely properly administered datacentre/server room network has much risk of DNS spoofing. If somebody is intercepting and modifying the traffic between your MTA and the authoritative DNS servers for your sending address, then I think you have far simpler attacks to worry about. Or maybe you have a recursive resolver which does not verify authority? Just configure it to check. Also, MTA-STS is the sort of thing you can monitor: a sudden downgrade after previously having seen support for a particular destination is a red flag, as is a large volume of non-MTA-STS traffic.

by wahern 8y ago

tptacek 8y ago

The primary motivation of MTA-STS is to provide a mechanism for domains to ensure transport security even when deploying DNSSEC is undesirable or impractical.

deleted 8y ago
[deleted]
Sephr 8y ago
Motivations are important, but your response does not address the technical issues brought up by the parent comment. Initial discovery uses DNS, so wouldn't uncached hosts still be vulnerable to downgrade attacks without DNSSEC? MTA-STS seems to suffer from some of the same issues facing HPKP.
- tptacek 8y ago
  DNSSEC advocates also believe DANE is needed to address the weaknesses in things like HPKP and HSTS. Of course, nobody else does, no mainstream browser implements DANE, and at least two have attempted to support DANE and then withdrew that support.
wahern 8y ago
Except in the absence of DNSSEC it does not ensure transport security. An attacker positioned to perform a MITM of an SMTP session is also positioned to MITM DNS requests. It's also worth mentioning that even if you skipped TXT querying and went straight to querying mta-sts.example.com, the attacker can just drop the A or AAAA record for mta-sts.example.com. The only way to prevent this is to use DNSSEC, which can sign negative answers. There is the benefit that if a policy is already cached the attack shouldn't work until expired. But much like SPF and similar issues, misconfigurations are so common I'd bet many transfer agents will still fail open if no TXT record is found (i.e. assume it's been disabled). In most organizations (and even small ones), the people or processes for managing DNS and e-mail are separate from WWW. With MTA-STS, when e-mail stops flowing people are going to have to check that their web sites (servers, proxies, etc) are setup properly. That's not at all obvious and will result in a lot of persistently broken systems. Senders are likely to put in mitigations because "it's not our fault" isn't always an acceptable answer. Plus, if you can MITM you can just drop connections until the policy is expired. MTA's will cache for days; policies like these usually have expiration times on the order of minutes or hours so that one can quickly and easily fix broken configurations. The DNS TXT version + HTTP policy max_age is a very awkward mechanism. IT departments will not understand this stuff well enough to use it as intended. The wording in the RFC that policy max_age should be on the order of weeks is just them papering things over. The whole thing sounds like they got mid way through a design predicated on using HTTP+TLS policies (the bright idea) before realizing how untenable things were, but stayed committed nonetheless.
- tptacek 8y ago
  The difference between your threat model and mine is that yours is based on concern for random people running small mail servers. I understand and respect that threat model, though I do not appreciate or really care about it. On the other hand: I believe email is a technological dead end, and that we are not evolving towards an Internet with a more distributed email system, but with less distribution. I think that, from a utilitarian perspective, the only mail servers that matter are the ones that Google and its peers run, and that's the threat model I care about. In my threat model, MTA-STS basically eliminates the concern DNSSEC/DANE addresses. Since your threat model includes rarely-used independently-operated servers (note that mine includes things like Fastmail and Proton!), servers that won't have cached assertions, MTA-STS is inadequate for your needs. The problem I have with your argument is that to fix your problem, which is an extreme niche, you require the radical centralization of all cryptographic trust on the Internet into a tree-shaped PKI whose roots and trunks are controlled by world governments and whose technical underpinnings date back to the 1990s. Even if I was to stipulate that you had a point, DNSSEC wouldn't be a viable answer to it. But that's a normative argument, and my point about DNSSEC being done is positive, not normative: deployment of MTA-STS is going to end DNSSEC. Not because I want it to (though I do) or because it should (though it should) but because it will: it drives a stake through the heart of the last truly motivating problem that DNSSEC was going to solve.

tedunangst 8y ago

But now we have dns over https too?

wahern 8y ago
Wake me when we have DNS over HTTPS for anything except web browsers. Plus, someone running an MTA is very likely running a recursive DNS server on the same network, if not the same machine, that uses UDP or TCP for upstream queries. Anyone positioned to MITM SMTP is likely positioned to MITM DNS. EDIT: Ah, perhaps you meant that with DNS over HTTPS, MTAs will need an HTTP client anyhow. IMO the path of least resistance will be adding HTTPS, DNSSEC, or w'ever to machine-local resolver services. But point taken (whether earnest or sarcastic =)
- tedunangst 8y ago
  Some sort of secure channel DNS seems likely to trickle down. Especially since an MTA is already well past getaddrinfo. And STS already requires https (which I do find kind of weird). So all the heavy lifting code of some form of secure DNS is here.
- damm 8y ago
  All it takes is someone updating the glibc resolver function to handle DoH. Then update /etc/resolv.conf with your DoH option or old legacy.. ... Not a fan of DoH but it doesn't matter if I like it.

microcolonel 8y ago

Did I miss something that made MTA DNS resolvers a target of spoofing? I don't see how a vaguely properly administered datacentre/server room network has much risk of DNS spoofing. If somebody is intercepting and modifying the traffic between your MTA and the authoritative DNS servers for your sending address, then I think you have far simpler attacks to worry about. Or maybe you have a recursive resolver which does not verify authority? Just configure it to check. Also, MTA-STS is the sort of thing you can monitor: a sudden downgrade after previously having seen support for a particular destination is a red flag, as is a large volume of non-MTA-STS traffic.