Subject: IETF mail server and SSLv3

From: IETF Chair <[email-masked]>
Date: Mon, 25 Jan 2016 21:39:34 +0200

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.

Jari Arkko, IETF Chair

---

From: tom p. <[email-masked]>
Date: Tue, 26 Jan 2016 17:02:38 +0000

---- Original Message -----
From: "IETF Chair" <[email-masked]>
To: "IETF Announcement List" <[email-masked]>
Cc: "IETF" <[email-masked]>
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.

<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.

Tom Petch

Jari Arkko, IETF Chair

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 26 Jan 2016 14:55:53 -0500

> 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.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 26 Jan 2016 23:16:00 +0200

Tom, Phillip,

Impressive? Not much. If anything, I feel a bit
embarrassed that we are updating our servers
only now :-)

This really was just an IETF service announcement.
The tools team felt that if we are making changes
we should announce them rather than surprise
anybody. We plan to announce similar other things
as well, when there are changes. And I certainly
believe this particular change was a technically
reasonable thing to do.

We do of course have other things to discuss —
how much the IETF is doing for improving email
security in the Internet, and what can be done to
it to begin with. But that is a broader topic that
IMO, doesn’t have much to do with what specific
arrangements we have for our own e-mail
server (and at a particular layer of that server,
even).  Phillip’s questions are very rasonable
in that broader topic, however.

Jari

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 26 Jan 2016 17:49:23 -0500

> in that broader topic, however.

I was taking the object of the exercise being of the dog food eating variety.

In the past, I have noticed that people seem to miss the fact that the
point of eating the dog food is to encourage people to make it better,
not to get used to the taste.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 27 Jan 2016 01:20:09 +0200

> not to get used to the taste.

True too. But that is going to take another action, beyond our simple
update of protocols at a server.

Jari