On 1/11/19 9:52 PM, William Herrin wrote:
Your other idea of signaling via DNS that a man in the middle is present if the target SMTP server fails to support encryption could have merit. I think the specific mechanism (overloading the host name) is unwise but I'd be interested to see the concept developed further.
If there's one takeaway I have from this thread to date, it's this. An advisory mechanism in DNS, such as via a TXT record, that says something along the lines of "We always support STARTTLS - if you can't negotiate that, then you are probably experiencing a MITM" could have merit. DANE appears to already offer this (and more), but as has been pointed out, can be complex to deploy. The downside I potentially see to this is that, if someone can MITM DNS (even if not the SMTP TCP session itself) and DNSSEC is not mandatory for this mechanism, that attacker could potentially cause a DoS against anyone they choose who does NOT support STARTTLS by falsely signaling that it is to be expected. I'm not sure how real-world of a threat that is given increasing adoption of STARTTLS, but it's definitely something to consider. -- Brandon Martin