On Tue, Jan 26, 2016 at 12:02 PM, tom p. <daedulus@xxxxxxxxxxxxx> wrote: > ---- Original Message ----- > From: "IETF Chair" <chair@xxxxxxxx> > To: "IETF Announcement List" <ietf-announce@xxxxxxxx> > Cc: "IETF" <ietf@xxxxxxxx> > Sent: Monday, January 25, 2016 7:39 PM > > For your information, while SSLv3 has been disabled on IETF web servers, > it has still been enabled on mail transport. The tools is taking action > to disable SSLv3 even on mail transport. After this, all IETF web and > mail servers support only TLS-based transport on secure connections. > > If you have any feedback regarding this, let me or the tools team know. > > <tp> > > It seems a somewhat strange executive decision. e-mail, famously, is > not end-to-end so what happens between the IETF mail servers and > whatever E/ISP the IETF uses seems like a local decision that does not > affect the service I get (whereas what happens between my e-mail client > and the E/ISP that I use has a major impact on the service I get). > > So this looks like an impressive sounding announcement in advancing the > field of privacy that actually does not mean very much. There has probably been no idea more damaging to the security of the Internet than the idea that end-to-end is the only way to do security. Email is an intrinsically store and forward system. Every network mail system has had at least three parties and Internet mail has had a four corner model since the early 90s. It is not possible to provide protection against traffic analysis at any layer above transport using existing standards. People periodically make claims to have done so, none of their schemes to date has been remotely practical. Nor is it possible to protect content against interception at the server nodes without message layer security. S/MIME and OpenPGP are end-to-end for a reason but neither protects the message headers and even if the subject line is encrypted, the From and To headers leak much information. So if we are going to start to get a grip on email security we need BOTH transport layer encryption AND end to end message layer encryption. TLS is not a substitute for S/MIME or OpenPGP. But even with both in place, our current infrastructure is unsatisfactory. We don't have a well supported security policy infrastructure. And to provide really solid traffic analysis defense, there should be link layer encryption in addition with flood fill. Back in 1992 when I started doing crypto, the fastest machines I could get my hands on (which were among the fastest existing at the time) were barely able to do RSA1024 without serious impact on performance. Today I am demonstrating a system that makes use of a PKI with 11 separate key pairs just to demonstrate configuration of email security for one person on two devices. Times have changed. Back in 1992 we had to make choices and compromises to make the WebPKI work. Those constraints haven't been relevant in a decade. With the new ECC work in CFRG, I can do full strength crypto out to a $5 Rapsberry Pi 0 without concern. And it isn't an insurmountable obstacle even on the Arduino class devices. Lets stop doing either/or security and start doing 'all of the above' security.