SMTP MTA Strict Transport Security (MTA-STS)
tools.ietf.org
SMTP MTA Strict Transport Security (MTA-STS)
1–10 of 42 posts
Re: SMTP MTA Strict Transport Security (MTA-STS)
#2Wow, I'm glad that this is official now. Is there a list of providers supporting MTA STS? I've seen Gmail has appropriate policy files and records but I've never seen anyone hit mta-sts subdomain on my own domain (meaning no one is checking it).
Re: SMTP MTA Strict Transport Security (MTA-STS)
#3The authors include Google, Yahoo, Comcast, and Microsoft --- basically the core providers of Internet email.
What's interesting about MTA-STS is its motivation: it's an effort to ensure TLS between MTAs without relying on DNSSEC. SMTP was one of the few remaining Internet security gaps DNSSEC purported to fill, and the IETF has now for the most part worked around that gap.
I think adoption of MTA-STS --- a foregone conclusion, I think, given its sponsors --- is basically the end of DNSSEC. Thankfully!
Re: SMTP MTA Strict Transport Security (MTA-STS)
#4Nice! MTA-STS is for the email space what HTTP Strict Transport Security (HSTS) is for websites.
This RFC has been around for a bit, and if I understand correctly was recently moved to the status "Proposed Standard" from "Internet-Draft".
I'm glad to see email security continuing to move forward. Thank you to the people who put what was undoubtedly considerable time into making this a reality.
Question to those who are more knowledgeable: Is there a way to determine whether a particular inbound connection is respecting a domain's MTA-STS policy? It'd be nice to be able to monitor what percent of incoming connections are MTA-STS aware, as a way to measure adoption.
Re: SMTP MTA Strict Transport Security (MTA-STS)
#5The authors include Google, Yahoo, Comcast, and Microsoft --- basically the core providers of Internet email. What's interesting about MTA-STS is its motivation: it's an effort to ensure TLS between MTAs without relying on DNSSEC . SMTP was one of the few remaining Internet security gaps DNSSEC purported to fill, and the IETF has now for the most part worked around that gap. I think adoption of MTA-STS --- a foregone…
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.
Re: SMTP MTA Strict Transport Security (MTA-STS)
#6Isn't that redundant with DANE TLSA records?
Re: SMTP MTA Strict Transport Security (MTA-STS)
#7Nice! MTA-STS is for the email space what HTTP Strict Transport Security (HSTS) is for websites. This RFC has been around for a bit, and if I understand correctly was recently moved to the status "Proposed Standard" from "Internet-Draft". I'm glad to see email security continuing to move forward. Thank you to the people who put what was undoubtedly considerable time into making this a reality. Question to those who a…
I don't think so. You could probably try and correlate the originating IP/subnet HTTPS policy request and subsequent SMTP connection.
Re: SMTP MTA Strict Transport Security (MTA-STS)
#8The authors include Google, Yahoo, Comcast, and Microsoft --- basically the core providers of Internet email. What's interesting about MTA-STS is its motivation: it's an effort to ensure TLS between MTAs without relying on DNSSEC . SMTP was one of the few remaining Internet security gaps DNSSEC purported to fill, and the IETF has now for the most part worked around that gap. I think adoption of MTA-STS --- a foregone…
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…
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.
Re: SMTP MTA Strict Transport Security (MTA-STS)
#9Isn't that redundant with DANE TLSA records?
The point is that (to a first approximation) nobody uses DNSSEC, which is badly flawed, and MTA-STS doesn't rely on it.
Re: SMTP MTA Strict Transport Security (MTA-STS)
#10Earlier quoted context omitted.
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…
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]