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
