On 07/27/2017 11:44 AM, Dave Warren wrote:
I've never understood why this is a special challenge in the SMTP world, it's generally a solved problem for HTTPS, XMPP, and various other protocols.
It's my understanding that the problem has to do with the (lack of) people involved in the transaction.
Usually, HTTPS / XMPP / etc. have a human in front of the client that can make (presumably) intelligent decisions.
Sure, humans can make (presumably) intelligent decisions between the MUA and their configured MTA. However, said configured MTA doesn't have a human to make a (presumably) intelligent decision when the receiving MTA uses a self signed (or otherwise untrusted) cert.
There is no human in the MTA-to-MTA exchange to "click ok" or "add exception" to the SSL / TLS certificate issue.
User-configured SMTP clients obtain a hostname from the user, using an incorrect hostname doesn't magically work, so adding one more validation test (certificate name matches hostname) doesn't seem onerous.
I believe recent versions of Thunderbird are doing something like this. (I don't remember the exact error I got when setting up a new mail server.)
Similarly, MX records with an incorrect hostname already don't work, so why would requiring a consistent mx.our-email-host.example. be used in MX records be a big deal?
I'm not following your question. Are you asking about using a naming standard for MXs? Or are you asking about making sure that the MX hostname is either the CN and / or (one of) the SAN(s)?
The STARTTLS command could be extended to allow "STARTTLS hostname" (like HTTPS SNI), where hostname would indicate the requested certificate, allowing multiple certificates to be used without a single certificate listing every possible alternate name. This would accommodate large virtual hosters who want to offer every client their own mail.client-company.example without dedicating IPs to every client.
If we're talking about names matching, shouldn't we also be checking the EHLO name? If so, it's too late to use SNI when using STARTTLS <SNI>.
-- Grant. . . . unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
