On Mon, 27 Oct 2008, Chris Newman wrote:
An RFC 3207 STARTTLS revision needs text related to server identity
check. I would prefer this text be as similar as possible to server
identity check text in other IETF application protocols.
The best-developed model that inter-domain SMTP might be based on is
server-to-server XMPP. (However be warned there are significant revisions
in RFC 3920bis.) SRV records in XMPP have the same function as MX records
in SMTP. XMPP avoids SMTP+TLS's DNS MX vulnerability by authenticating the
server JID (SRV owner name) not the host name (SRV target name).
In order to avoid requiring an IP address per domain, there must be a way
for the client to indicate to the server which domain it is trying to
send mail to, before negotiating TLS. RFC 3207 doesn't allow this.
If you follow this model there are more subtle implications. At the
moment, a server that is an MX for multiple domains can accept a message
with multiple recipients at any of those domains. Simple server-to-server
TLS would not allow this; it would instead have to be complicated with
support for multiple domains in the server certificate. However, if the
XMPP experience is repeated, it'll be impossible to buy these special
certificates from the CAs because they're focussed on web servers to the
exclusion of anything else.
There are also problems with intra-site relaying. This should probably
follow the message submission model, in which the client's configuration
directs mail by host name and authenticates the server by host name.
However in practice many MTAs resolve the next hop server via MX records
by default (e.g. unless suppressed by wrapping the host name in square
brackets) even when this is unrelated to the mail domain of any recipient
address.
For Submit, I'd expect the TLS server identity check to be
mandatory-to-implement and very close to that of IMAP and POP (or to
have a justification why it shouldn't follow IETF practices for this).
Agreed. (This is what is implemented.)
For SMTP transfer, the situation is different and probably needs technical
discussion to reach consensus on the path forward. It would not surprise me
if we needed one or more additional EHLO keywords/arguments to resolve
legitimate concerns.
Yes.
I will observe that for SMTP without SMTP AUTH, there is value in
opportunistic STARTTLS encryption without authentication as long as the
risks are understood.
It can help against on-path passive (snooping) attacks. It cannot help
against active attacks, and active attacks are much easier for an on-path
attacker.
Tony.
--
f.anthony.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
VIKING: NORTHWESTERLY BECOMING CYCLONIC THEN NORTHEASTERLY 5 TO 7, INCREASING
GALE 8 OR SEVERE GALE 9 FOR A TIME. VERY ROUGH OR HIGH. RAIN OR SQUALLY WINTRY
SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.