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.
It seems to me that DNSSEC has little to do with MTA-STS. In fact, DNSSEC is only listed four times in RFC 8641. Further, MX records can pass DNSSEC validation just fine and still be subject to route hijacks and the likes. Said attacks can downgrade SMTP by removing the STARTTLS EHLO option, all without running afoul of DNSSEC.
It's my understanding and belief that MTA-STS would continue to protect / detect such manipulation of STARTTLS in such an attack.
What I'm not sure of is if MTA-STS will help detect certificates from alternate CAs that allow the attacker to falsely claim to be the receiving MTA. (I need to do more reading.)
SMTP itself still works without running a web server. The web server really is just an easier way than DNSSEC for some admins to secure the MX response, a 2FA on the MX response so to speak.
Apples and hammers. (Not even two types of fruit.)How does DNSSEC secure the MX (response)? - Sure, DNSSEC can validate that the MX and associated A / AAAA records for a domain have not been tampered with. But that does nothing to ensure that someone isn't tampering with STARTTLS.
Or were you alluding to DANE (which requires DNSSEC) and MTA add-on software checking for certificate information in DNS to determine if STARTTLS should be used and it's absence an indication of a problem?
Not really all that high level, and if they are too high level for the user, there are inexpensive services that do it for you, including valid certificate thanks to Let's Encrypt.
I'm going to agree with Viruthagiri on this one. Setting up a web server, including TLS certificate, is more advanced than many people are comfortable with. Granted, all of the requirements / steps involved are relatively simple in and of themselves. There are more than a few of them, any one of which can be problematic for someone who is completely new to doing such.
Don't let your familiarity / comfort of a task cloud the complexity of the task.
I agree it would be better if Google started signing their zones and supported DANE for TLS.
I don't foresee Google using DNSSEC or DANE any time soon. Much less using information that receiving domains publish in conjunction with STARTTLS.
-- Grant. . . . unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
