--On Monday, July 27, 2015 15:17 +0200 Aaron Zauner <azet@xxxxxxxx> wrote: > Hi, > > UTA chairs recommended sending a mail about this to the UTA > and IETF lists. We're currently analyzing our datasets -- so > more/detailed data will become available shortly. > > Over the past couple of months we've been collecting SMTP, > IMAP and POP (implicit TLS, STARTTLS) security measurements > (primarily relating to TLS, X.509 Certs and offered protocol > extensions). I've given a short talk at IETF93 in SAAG on the > topic, the slides can be found over here: > https://www.ietf.org/proceedings/93/slides/slides-93-saag-2.pdf >... > We don't yet have a publication ready and our data sets are > currently not public, but will be in the foreseeable future. > However we're happy to provide details if any of you have > questions. Hi. I'm very much in favor of this work being done, results being published, and discussions being used to improve things. At the same time, I want to express a concern and hope it is reflected in any documents or recommendations. We know that there is still a lot of multiple-hop/ multiple-MTA-in-path email around, especially if one includes paths between the message-creation process and the submission server and between the delivery server, mailstore, and user/MUA that may involve dubious trust relationships or weak user authentication. Unless things have changed significantly in recent years, in most environments and for most attackers other than governments engaged in pervasive surveillance, attacks on servers hosting MTAs or mailstores are easier and more likely to be productive than attacks on message transport between MTAs. Whether one believes in OpenPGP, S/MIME, or something else, we know that the only really strong protection for message content that is relatively immune from compromised relays or mailstores (as well as from weak links in the transmission chain) involves encryption at the source and under the direct control of the sending user and decryption at the destination under the direct control of the receiving user. We also know that those techniques are little-used and that are a lot of theories as to why not. That low level of use may be, and probably is, a good reason for a concentrated effort on link encryption. However, we shouldn't make arguments for good-quality link encryption that have the effect of convincing people (even the fairly naive) that it makes either end-to-end content encryption or relay server hardening unnecessary or undesirable. And we should recognize that a message-originating site that transmits only (or only when the site identifies it as relevant) signed and encrypted messages but that chooses to not support the latest and best in link encryption is thereby inherently less secure or a less appropriate correspondent than one that uses link encryption alone. As I said, I favor this work, but there has been too much history in computer science and networking of coming up with easy solutions that make people feel good about "doing something" but that don't actually address the critical-path problems. I'm not suggesting this is one of those cases, but we should pay attention and be very careful that improvements in relatively unimportant or low-risk areas don't drive out more effective or comprehensive solutions. john