On Tuesday, March 11, 2003, at 02:21 PM, Eric Rescorla wrote:
ietf1(_at_)ietf(_dot_)org writes:
It did teach me the importance of protecting against the
man-in-the-middle attack. This is not often done, at least not by
default, in many STARTTLS implementations.
Indeed. The problem is that it's pretty hard to determine
a priori what certificate the peer server ought to be offering,
due to mail relaying and MX records.
or at least, proper behavior isn't well-defined. IMHO, about the only
behavior that is reasonable (assuming a single cert, which IIRC is what
TLS assumes) is to have the peer server offer a cert for the domain
name associated with the A record, not the one associated with the MX
record.
this doesn't protect against bogus MX records. but if the site doesn't
want to be an MX for that domain then it will refuse the mail - ideally
with an enhanced status code that indicates why the mail was refused.
it might even be reasonable for MTAs to detect that case and handle it
specially.