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 <[EMAIL PROTECTED]> 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.
