Steven M. Bellovin wrote: > The primary use of STARTTLS for SMTP is for mail *submission*, not > relaying. That is, when clients (like Eudora) generate mail, they > submit it to an ISP or organizational SMTP server. If this server is > accessible from the Internet, it should require some sort of > authentication, to avoid becoming an open spam relay. This is > sometimes done by a password over a TLS-protected session. > > In other words, this isn't opportunistic encryption, and doesn't run > into the problem of "random smtp server has a self-signed cert". The > client should be configured to know what cert to expect.
Steven raises an interesting point. Having looked at various STARTTLS implementations it appears to me that if not the designers of STARTTLS then at least the authors of STARTTLS-enabled MTAs appeared to have envisioned the use of STARTTLS primarily to secure and authenticate email submission, not MTA-to-MTA SMTP transfer. STARTTLS's ability to encrypt authentication information, in practice primarily SASL, during mail submission from the MUA to the MTA is certainly welcome; I myself am making extensive use of it in my SMTP infrastructure. Mail submission does however not represent the bulk of STARTTLS-encrypted SMTP traffic on the Internet today. A brief unscientific look at some maillogs that I performed a few months ago showed that MTA-to-MTA (for the MTA's in question this equates site-to-site SMTP traffic) use of STARTTLS is a resounding 3 orders of magnitude more common than the use of STARTTLS to secure and authenticate submission from MUAs. Here is why: once STARTTLS-enabled MTAs reached a certain density, which appears to have been exceeded on parts of the Internet sometime over the last year, the ability to support STARTTLS triggers the well-known "fax effect": the moment you enable STARTTLS in your MTA, connections to other MTAs will automatically be secured, at worst with opportunistic encryption. With each MTA supporting STARTTLS added to the Net the percentage of encrypted SMTP connections increases as the use of STARTTLS takes place without even the knowledge, much less the elusive active cooperation, of dozens, hundreds, or even thousands of users per MTA. I boldly submit that more email is presently being encrypted on the Internet every single day using STARTTLS than has ever been secured using PGP, S/MIME, or other MUA-based encryption methods combined over the entire history of SMTP. Case in point: I am one of the heaviest users of PGP that I am aware of. In addition, I have used PGP for longer than most, going back to my days as an alpha tester of PGP 2.0. I have used and continue to use S/MIME extensively. Nonetheless, my primary MTA processes more TLS encrypted email in under a week than I have ever encrypted using MUA-based systems in my entire life. Perhaps a student with access to the logs of a large STARTTLS-capable university MTA will write a paper containing a quantitative analysis of today's use of STARTTLS. There is definitely a paper waiting in analyzing this phenomenon. It is my hope that the authors of MTAs will integrate the lessons learned from the de-facto use of STARTTLS to enable additional desirable STARTTLS-based feature in future releases of their software. --Lucky Green --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
