this post was submitted on 10 Sep 2023
55 points (92.3% liked)
Privacy
30749 readers
551 users here now
A place to discuss privacy and freedom in the digital world.
Privacy has become a very important issue in modern society, with companies and governments constantly abusing their power, more and more people are waking up to the importance of digital privacy.
In this community everyone is welcome to post links and discuss topics related to privacy.
Some Rules
- Posting a link to a website containing tracking isn't great, if contents of the website are behind a paywall maybe copy them into the post
- Don't promote proprietary software
- Try to keep things on topic
- If you have a question, please try searching for previous discussions, maybe it has already been answered
- Reposts are fine, but should have at least a couple of weeks in between so that the post can reach a new audience
- Be nice :)
Related communities
Chat rooms
-
[Matrix/Element]Dead
much thanks to @gary_host_laptop for the logo design :)
founded 4 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Okay, so I did some research to confirm my previous understanding and for the sake of completeness I just wanted to throw this information into this thread... Neither DNSSEC/DANE nor MTA-STS is required. AFAIK none of the huge e-mail providers like Gmail, Outlook, or iCloud implement DNSSEC/DANE, but protonmail and tutanota both do. Of those everybody implements MTA-STS, except for iCloud.
In the case of e-mail both of these aim to alleviate a big security flaw in e-mail, which is that when Alice is trying to send you an e-mail, Alice's mail server has no clue whether or not your e-mail server supports TLS (e-mail is older than TLS, so it's bolted on in an opportunistic fashion)... As a result if somebody can get in the middle of Alice's mail server and your mail server they can say "hey, I don't support TLS", and then Alice's mail server will just say "okay, fine, here's the e-mail unencrypted". Obviously such a downgrade attack is BAD, so DNSSEC/DANE and MTA-STS are attempts to prevent this from happening.
DNSSEC/DANE solves this problem because it guarantees that DNS records are legitimate and it can guarantee whether or not a DNS record that says "hey the mailserver supports TLS" does or doesn't exist. The disadvantage of this is just that it relies on DNSSEC, which has its own caveats.
MTA-STS attempts to mitigate the problem... With MTA-STS you add some DNS records that say "hey, look up the MTA-STS policy from this HTTPS server", and the HTTPS server provides a file that says whether or not the mail server requires TLS connections to prevent downgrades. This always bothered me, though, because if somebody can attack DNS this arguably gives you very little... And if somebody is in the position to block HTTPS traffic they can prevent the policy from being fetched as well. Theoretically this doesn't provide much of a guarantee, but I guess in practice it's probably a decent mitigation because if a policy has been fetched before there will be a cached version available, so you'd need a sustained or well-timed attack to break MTA-STS, and on the plus side they can't generate a bogus policy file to disable TLS connections to the mail server unless they can get a valid TLS certificate for your domain.
Either way, both of these things are pretty much entirely about receiving e-mail, and aren't spam mitigation measures, so they shouldn't have anything to do with your ability to send e-mail (which is the harder part). It matters for sending in the sense that you don't want e-mail that you send to other mail servers to get downgraded from TLS when it shouldn't either, which means your mail server should validate MTA-STS + DNSSEC/DANE for mail servers that you are sending mail to. Ideally you would set up DNSSEC/DANE and MTA-STS in order to prevent this class of attacks on your personal e-mail, though it's not strictly necessary. MTA-STS is pretty trivial to set up as long as you already have an HTTP server on hand to serve up the policy file (which you probably do). DNSSEC may be a heavier ask for people depending on TLD support, registrar support, nameserver support, and software support (a lot of the DNSSEC signing software coughldnscough seems to choke on certain RRs -_-), but this may be easy for many people to implement.