> > Requiring TLS is pointless if the MX record is not secure.
Alice, If the DNS is not secure, then that's a completely different issue. It should be fixed in the DNS rather than SMTP. And that's the reason DNSSEC was introduced, right?. Your whole assumption here is MX records are not secure. And guess what... By that assumption, we shouldn't use email at all for communication. You should also read this interesting article "where are all the helicopters? <https://dyn.com/blog/is-dnssec-adoption-worth-it-for-enterprises/>" MTA-STS is still relying on TXT record for caching. So MTA-STS is more of a duct-tape solution rather than a bulletproof solution. And one more issue with this solution is that, why protect only the senders? Why not receivers? The spoofing prevention records like SPF, DKIM and DMARC are still not secure, right? On Sun, Jan 6, 2019 at 10:58 AM Alice Wonder <[email protected]> wrote: > On 1/5/19 9:22 PM, Alice Wonder wrote: > > On 1/5/19 8:55 PM, Grant Taylor wrote: > >> On 1/5/19 8:05 PM, Alice Wonder wrote: > >>> Also I seem to recall talk of an e-mail header clients can add that > >>> tell a MTA not to forward it without encryption. > >> > >> I'd be curious to know what said header is, and what MTAs support / > >> honor it. > >> > >>> What the HTTPS server in MTA-STS really does is give some limited > >>> protection against DNS MX record spoofing for zones that do not have > >>> DNSSEC and/or for MTA clients that do not validate DNSSEC. > >> > >> What‽ That's contrary to my understanding of what MTA-STS is. > >> > >> My understanding of MTA-STS is that it's a way for receiving domains > >> to indicate that they support and want connections to their receiving > >> MTAs to use STARTTLS encryption. Thus sending MTAs can deduce that > >> there is a problem if they don't see STARTTLS as an extension when > >> connecting to said receiving MTAs. > > > > The https part contains a list of MX hosts (or regex of them). > > The MTA client is suppose to only use a MX host that is in both the MX > > record and the mta-sts https delivered policy. > > > > Yes it also then requires TLS (and I believe TLS 1.2+ but not positive) > > with a PKI validating certificate, but (assuming enforce mode) it is > > only suppose to communicate with MX hosts that are an intersection of > > what is in the MX record and the https delivered policy. > > > > So the https delivered policy is a 2FA for the MX record that is secured > > by TLS via PKI validation. > > > > TLS is then used to mitigate MITM attacks but if it was just to turn on > > TLS all that would be needed is the MTA-STS DNS record. > > > > The web server component secures the MX record. > > What I am trying to say - > > Requiring TLS is pointless if the MX record is not secure. > That's why MTA-STS needs the https component, to secure the MX record > when DNSSEC is not used to do so. > > When DNSSEC is used, DANE then is better at securing the connection so > MTA-STS is only needed when the server and/or client do not support DANE > for SMTP. And the MTA-STS RFC specifically says it is not to be used to > green light a connection when DANE validation is available but fails. > > _______________________________________________ > Uta mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/uta > -- Best Regards, Viruthagiri Thirumavalavan Dombox, Inc.
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
