Subject: Re: IETF mail server and SSLv3

From: Derek Atkins <[email-masked]>
Date: Tue, 02 Feb 2016 21:00:02 -0500

IETF Chair <[email-masked]> writes:

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

Have you disabled non-TLS SMTP transport, too?

If not, isn't there a chance that disabling SSLv3 will cause *SOME*
email to fallback to non-encrypted?

> Jari Arkko, IETF Chair

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 4 Feb 2016 02:40:01 +0000

> Have you disabled non-TLS SMTP transport, too?

That would clearly be premature.

> email to fallback to non-encrypted?

A very small chance, but given the rapidly diminishing and already
negligible fraction of systems that are only capable of SSLv3, this
is an acceptable cost of reducing the attack surface and opportunities
for downgrade and other attacks against the vast majority of
remaining systems.

I'm glad to see active support for the positions expressed in
RFC7435, and indeed one generally gets more security by raising
the ceiling (making stronger crypto available) than by raising the
floor (requiring stronger crypto than was previously acceptable).

However, after making stronger crypto available for long enough,
and reaching sufficient deployment levels that obsolete crypto is
legitimately almost never needed, it is eventually time to move on
and raise the floor too.

I am quite comfortable at this time with a requirement of better
than SSLv3 for SMTP on the public Internet.

-- 
	Viktor.

---

From: John C Klensin <[email-masked]>
Date: Thu, 04 Feb 2016 11:22:57 -0500

--On Thursday, 04 February, 2016 02:40 +0000 Viktor Dukhovni
<[email-masked]> wrote:

>...
> I am quite comfortable at this time with a requirement of
> better than SSLv3 for SMTP on the public Internet.

Unless there is a fallback to clear text, I am not.  If we were
to succeed in creating a situation in which the only email that
could be sent or received on the public Internet was encrypted
in transit (and, by the way, encrypted or otherwise very well
protected and secured on relays and in mail stores), I think it
is only a matter of time before some government resorts to the
time-honored approach of making the use of crypto illegal and
specifying harsh punishments for its use.   

The effect of such a decision would be to cause whole countries
to vanish from the connected email network environment.    I
think that would be undesirable in general and inappropriate for
IETF materials and discussions.   For that and other reasons, I
think there is a balance to be struck between being open and
transparent and trying to insist on high levels of privacy for
things that are really need very little privacy protection (or
that are fully public in other ways, e.g., by appearing in
generally-accessible archives).  YMMD.

     john

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 4 Feb 2016 17:59:40 -0500

> On Feb 4, 2016, at 11:22 AM, John C Klensin <[email-masked]> wrote:
> 
> Unless there is a fallback to clear text, I am not.

Yes, of course with cleartext transmission in the absence of STARTTLS
support.  I had expected that would have been clear from context.

The point being that systems that are STARTTLS-capable are at this
point essentially without exception capable of TLSv1 or better.

My statement should have said "requirement of better than SSLv3 to
complete a STARTTLS handshake".  I am not suggesting that we've
reached sufficiently broad STARTTLS adoption to make it realistic
to end support for cleartext SMTP.

At https://www.google.com/transparencyreport/saferemail/
we see a very small positive slope in the percentage of TLS
outbound mail (~2% per year) and no sign of growth in TLS inbound
mail (I'm guessing the bulk email senders don't much care for TLS
and send more traffic on weekdays than weekends).

-- 
	Viktor.

---

From: [email-masked]
Date: Thu, 04 Feb 2016 19:00:44 -0800 (PST)

> support.  I had expected that would have been clear from context.

That's in no way sufficient. Not only do you have to be willing to do without
STARTTLS, you also have to be willing to close the connection and try another
in the event that the server offers STARTTLS, the client attempts to use it but
the TLS negotiation fails for some reason.

I suspect this is the "fallback" John was talking about.

Not all SMTP clients offer this capability, and without it you can get into
stuck message situations.

> point essentially without exception capable of TLSv1 or better.

Maybe. But even if this is true, there are other ways for TLS negotiation
to fail. (The one that has been the biggest nuisance historically is where
TLS is enabled on the server but no certificate is installed, causing all
attempts to use TLS to fail unconditionally.)

> and send more traffic on weekdays than weekends).

Gmail falls back to cleartext on a new connection when TLS negotiation fails.

				Ned

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 5 Feb 2016 04:13:46 +0000

> the TLS negotiation fails for some reason.

This is true, reasonably well known[1] and largely tangential to
the topic of this thread which is ietf.org disabling SSLv3 support
in SMTP STARTTLS. My point is that this action, be it mostly
symbolic, is at this time harmless as the overwhelming majority of
TLS-capable servers and clients can now do TLSv1 or better.

-- 
	Viktor.

[1] http://www.postfix.org/TLS_README.html#client_tls_may

	With opportunistic TLS, mail delivery continues even if
	the server certificate is untrusted or bears the wrong
	name. When the TLS handshake fails for an opportunistic
	TLS session, rather than give up on mail delivery, the
	Postfix SMTP client retries the transaction with TLS
	disabled. Trying an unencrypted connection makes it possible
	to deliver mail to sites with non-interoperable server TLS
	implementations.

The implementation and documentation of this was joint work with
Wietse back in early 2006.  These days, when STARTTLS fails, Postfix
tries other MX hosts first and if they all fail, defers the mail
initially. Cleartext fallback kicks in on the second delivery
attempt if STARTTLS fails again.

---

From: [email-masked]
Date: Fri, 05 Feb 2016 06:42:34 -0800 (PST)

> attempt if STARTTLS fails again.

Actually, I consider this approach as unacceptable unless the second delivery
attempt occurs within a minute or two. (Which, incidentally, is a much shorter
retry period after deferral than the standards recommend.)

				Ned

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 5 Feb 2016 15:44:35 +0000

> retry period after deferral than the standards recommend.)

The default is 5 minutes, with doubling exponential backoff up to
a cutoff of somewhat over an hour:

    $ postconf -d {min,max}imal_backoff_time
    minimal_backoff_time = 300s
    maximal_backoff_time = 4000s

(These, combined with per-destination concurrency limits to avoid
overwhelming remote systems that come back after a period of
downtime, and throttling of destinations when enough back-to-back
deliveries fail, do a better job of avoiding hammering remote
systems than the recommendations in the standards, while substantially
reducing delay when transmission fails on the first attempt).

I typically override these to min/max = 225s/7200s (this reduces
congestion delay if the queue happens to hold enough long-term
deferred mail, since with these settings the fraction that is active
at any given time is reduced by a factor of 2 or so).

As for "unacceptable", you might find the below fall into that
category:

  * IIRC Sendmail never falls back to cleartext if STARTTLS is
    advertised.

  * Microsoft's Schannel TLS stack at outlook.com and in Exchange
    by default solicits client certs it does not use and then rejects
    client connections that happen to present a certificate chain with
    an MD5 signature, even when it the self-signature of a root CA
    as with CAcert.org.

  * The ancient SChannel implementation in Exchange 2003 ignores all
    but the first 64 ciphers in the client's TLS hello, and has a
    broken DES3-CBC implementation that fails post-handshake with
    trailing garbage in the TLS response to EHLO that breaks the
    established TLS connection after "MAIL FROM".  Only RC4-SHA
    and RC4-MD5 work (but modern Schannel at outlook.com refuses
    to negotiate RC4).

    $ posttls-finger -o tls_medium_cipherlist=RC4-SHA -c -Ldebug microsoft.com
    posttls-finger: initializing the client-side TLS engine
    posttls-finger: setting up TLS connection to microsoft-com.mail.protection.outlook.com[207.46.163.138]:25
    posttls-finger: microsoft-com.mail.protection.outlook.com[207.46.163.138]:25: TLS cipher list "RC4-SHA:!aNULL"
    posttls-finger: SSL_connect:before/connect initialization
    posttls-finger: SSL_connect:SSLv2/v3 write client hello A
    posttls-finger: SSL_connect error to microsoft-com.mail.protection.outlook.com[207.46.163.138]:25: lost connection

  * DANE/DNSSEC at mail.mil and the many domains it is MX for is
    fubar'ed, because their firewall "protects" the DNS servers by
    blocking lookups for exotic records such as TLSA.

    $ dig -t tlsa +noall +comment +ans _25._tcp.pri-jeemsg.eemsg.mail.mil.
    ;; connection timed out; no servers could be reached

    $ dig -t a +noall +comment +ans _25._tcp.pri-jeemsg.eemsg.mail.mil.
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 14873
    ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

  * Despite being notified at the beginning of Aug 2015, isphuset.no
    still has has upgraded from a buggy PowerDNS version that
    botches TLSA record denial of existence for the domains of all
    their DNSSEC hosted customers.  [ In the example below, the
    name internot.no seems rather apt ]

    $ unbound-host -t tlsa -v _25._tcp.internot.no.
    _25._tcp.internot.no. has no TLSA record (BOGUS (security failure))
    validation failure <_25._tcp.internot.no. TLSA IN>: nodata proof failed from 195.35.82.103

As for a delay of < 5 minutes delivering email to such broken sites
it is, for most users, a reasonable trade-off to reduce needless
TLS fallback in the face of routine transmission glitches.

Though in the case of mail.mil, internot.no and the like, one has
to explicitly disable DANE support for those domains, since in
order to avoid downgrade attacks there is no fallback when TLSA
record lookups timeout or servfail.

-- 
	Viktor.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 5 Feb 2016 11:06:52 -0500

Rather than discussing this on the IETF list, wouldn't it be rather
more productive for the discussants to get together and thrash out a
draft on how to use STARTTTLS in SMTP?

RFC3207 was published in 2002. 14 years and several revisions to TLS
later, it is probably time for a RFC3207-bis.

---

From: [email-masked]
Date: Fri, 05 Feb 2016 08:13:34 -0800 (PST)

> later, it is probably time for a RFC3207-bis.

Since the issue at hand is the ramifications of a policy change for
IETF lists, the answer is no, it wouldn't.

It's unfortunate that such a policy choice requires a deep understanding
of how existing email software implements STARTTLS, but that's the situation
we're in.

				Ned

---

From: [email-masked]
Date: Fri, 05 Feb 2016 08:04:10 -0800 (PST)

> a cutoff of somewhat over an hour:

That's borderline IMO.

>   * IIRC Sendmail never falls back to cleartext if STARTTLS is

A fix has been available for a while; the apparent plan is to integrate 
it into sendmail 8.16. See:

http://www.sendmail.org/%7Eca/email/patches/tls_failures.p1#sthash.iwHHaXb0.dpuf

for details. However, since the fix doesn't allow for immediate fallback, it
leaves a lot to be desired.

> TLS fallback in the face of routine transmission glitches.

That's a consequence of piggybacking cleartext fallback on the deferral
mechanism you use for transmission failures. It doesn't have to  be done this
way.

				Ned

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 5 Feb 2016 11:36:39 -0500

> On Feb 5, 2016, at 11:04 AM, Ned Freed <[email-masked]> wrote:
> 

Final comment.  Cleartext fallback in Postfix is NOT piggybacked on the deferral
mechanism, in fact until quite recently cleartext fallback was done synchronously
during the initial delivery.

And in fact, it is still synchronous now, because the second delivery still tries
TLS again (just in case the first failure was a fluke) and then retries in cleartext
without extra delay (beyond the time it takes to try and fail TLS).

The new approach is a careful compromise that avoids over-eager cleartext fallback
on the first attempt, not because we don't have the code to do it right away, but
because we *chose* to delay and try TLS again.

With that, I'm done imposing on [email-masked] in this thread.  Sorry about the
noise.

-- 
-- 
	Viktor.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 5 Feb 2016 12:04:33 -0500

> of how existing email software implements STARTTLS, but that's the situation

The point of eating the dogfood is process improvement. Not to get
used to the taste. And the point is lost if we then create our own
special dogfood.

Capturing the process and the special sauce is what I am after.

As far as policy goes, the admin of an IETF service should be
permitted to change the config any time they like provided that they
are compliant with an IETF spec.

---

From: John C Klensin <[email-masked]>
Date: Fri, 05 Feb 2016 13:47:57 -0500

--On Thursday, February 04, 2016 19:00 -0800
[email-masked] wrote:

>> Yes, of course with cleartext transmission in the absence of
>> STARTTLS support.  I had expected that would have been clear
>> from context.
> 
> That's in no way sufficient. Not only do you have to be
> willing to do without STARTTLS, you also have to be willing to
> close the connection and try another in the event that the
> server offers STARTTLS, the client attempts to use it but the
> TLS negotiation fails for some reason.
> 

I hadn't thought through all of the details but more or less
yes.  

> Not all SMTP clients offer this capability, and without it you
> can get into stuck message situations.
> 
>> The point being that systems that are STARTTLS-capable are at
>> this point essentially without exception capable of TLSv1 or
>> better.
> 
> Maybe. But even if this is true, there are other ways for TLS
> negotiation to fail. (The one that has been the biggest
> nuisance historically is where TLS is enabled on the server
> but no certificate is installed, causing all attempts to use
> TLS to fail unconditionally.)

In addition, the IETF often fails to understand how slowly
change occurs, especially when the changes are expected to
replace existing practices that seem to work.  We've still got
messaging systems around that haven't fully gotten MIME and that
therefore still using "message and attachments" models.
Similarly, 18 or 19 years ago, our big focus was on
authentication rather than privacy and the IETF was on an
anti-password tear, so we developed CRAM-MD5, not just as a
serious proposal but a hack to show that, with the technology of
the time, it was possible to move beyond passwords without
requiring heavy-duty authentication servers.  It has been a long
time, but I think we were also concerned about restrictions on
encryption and encryption export (a set of problems that were
not solved the IAB/IESG statement in RFC 1984 a few years
earlier).    Despite our understanding of the difficulties with
CRAM-MD5 (most obviously, its reliance on MD5 itself), I still
see it used and used with SMTP AUTH as well as with POP and
IMAP.  Why?  Well, maybe to avoid encryption, but I'd guess more
likely just out of habit and legacy behavior.

RFC 1918 is, itself, another example.  It is a good policy
statement which most of us supported and considered valuable
then and still do.   But it is  not a magic wand that brought
about immediate and lasting changes -- many of the debates and
policy proposals it refers to are still very much with us; some
seem to be experiencing a resurgence after appearing to have
gone away.    

Ultimately, some actors are going to follow our advice and some
aren't and, especially when we promote a "stop doing this or
using that" measure, we need to decide what sort of Internet we
want: one that is as open or inclusive as possible or one that
isn't nearly as open to those who don't follow our rules and
preferences.  While I appreciate Victor's follow-up
clarification, that tradeoff applies whether we are talking
about, e.g., "crypto or the mail doesn't go through" or "no
transit privacy unless you use a preferred version of TLS".   

FWIW, I think what Ned, I, and many others have heard from users
over the years is that they prefer that messages get through
and, most of the time, behave as if that is far more important
than marginal privacy or security.  I wish that preference were
a little different, but my (and other) efforts to educate the
public about why they should care more --at least to the extent
of making sure they can use whatever privacy and authentication
mechanism that are available and that they judge to be effective
for their needs have, so far, not been very successful.

       john

---

From: [email-masked]
Date: Fri, 05 Feb 2016 09:30:58 -0800 (PST)

> used to the taste. And the point is lost if we then create our own

I completely disagree, but that's beside the point.

The issue at hand is whether or not to disable the use of old ciphersuites in
the IETF's use of STARTTLS in SMTP. Irrespective of the reasons we have for
doing that, John's point was and is that it can adverse effect on our ability
to reach everyone who wants to participate. 

This effect can be mitigated to some extent by your choice of SMTP client
software and how you configure it. To that end it's important to understand
what options are available and what the consequences are of their use.

It's also important to reach some measure of consensus on how much
inconvenience is too much. It's clear that Viktor and I disagree on this - I
think supporting people who for whatever reason have to contend with crappy
email software is far more important than any sort of dogfood eating exercise.

> Capturing the process and the special sauce is what I am after.

That's all fine and dandy, but it isn't what this conversation is about.

And after spending several years pretty much begging the security area to take
some small notice of this particular set of issues, you can understand why I
have very little patience left for having the much more detailed conversation
you apparently want to have.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Fri, 05 Feb 2016 15:08:39 -0500

--On Friday, February 05, 2016 09:30 -0800
[email-masked] wrote:

>> The point of eating the dogfood is process improvement. Not
>> to get used to the taste. And the point is lost if we then
>> create our own special dogfood.
> 

I don't know if my reason for disagreeing is the same as Ned's,
but I've always thought the point of eating the dogfood is to
improve the technical quality of our standards and protocols by
promoting a better understanding of how they do (or do not) work
in actual operational practice.  Process improvement seems to me
to be only slightly more relevant than teaching one's favorite
cat, goldfish, or elephant to enjoy the dogfood or consider it
nutritious.

I wouldn't think that was worth taking the time to say except
that each of these proposed changes has potential costs, costs
of the discussions we need to have before making them, costs to
either make changes or live without them, costs to people who
are thereby denied convenient (for them) access to things we
claim are public and generally accessible.  I think that, as
long as the IETF claims to be about engineering a production and
very large-scale network rather than engaging in utopian
thinking of various sorts, those costs have to be justified (or
not) by serious discussions of what we expect to accomplish (and
why we expect that) and by presentation of threat models and how
the changes will mitigate against those threats.  

This conversation seems to be about how newer methods are better
than SSLv3 and therefore we should get rid of the latter.
Well, as long as clear text fallback is available and works
efficiently (and I think Ned's suggested maximum two-minute
delay is, indeed, a maximum) I guess I don't care.   But, for
those who think this is about privacy and its promotion, that
then makes the question one of whether SSLv3 is worse than plain
text, not only whether it is worse than an appropriate version
of TLS.   It could be worse in either practically or symbolic
terms, but that goes back to goals and threat models.

> The issue at hand is whether or not to disable the use of old
> ciphersuites in the IETF's use of STARTTLS in SMTP.
> Irrespective of the reasons we have for doing that, John's
> point was and is that it can adverse effect on our ability to
> reach everyone who wants to participate. 

And adverse effects on our claims of complete openness.

> This effect can be mitigated to some extent by your choice of
> SMTP client software and how you configure it. To that end
> it's important to understand what options are available and
> what the consequences are of their use.

Yes, although (to exaggerate quite a bit) if the effect is to
tell people that, if they are to participate effectively in
IETF, they better be running SuperDuperMailClient version 99 or
later, that would be, IMO, a net loss too.   As Ned has implied
(even if not said explicitly), many IETF participants have no
control over the the client (or server) software they use.   If
they are also part of corporate environments in which people are
wondering about the value of IETF participation for other
reasons, a demand that the organization either switch software
or allow an exception could easily be one less (or one company
less) active participant in the IETF.  I don't see that as a
desirable outcome, no matter how much dogfood is happily
ingested by those who are left.

> It's also important to reach some measure of consensus on how
> much inconvenience is too much. It's clear that Viktor and I
> disagree on this - I think supporting people who for whatever
> reason have to contend with crappy email software is far more
> important than any sort of dogfood eating exercise.

Yes.  See above.

> And after spending several years pretty much begging the
> security area to take some small notice of this particular set
> of issues, you can understand why I have very little patience
> left for having the much more detailed conversation you
> apparently want to have.

As the two of you and probably some others know, I made an
explicit personal decision to avoid active participation in
computer security issues in the mid-1970s, before the IETF and
indeed before the Internet.  One reason was that there seemed to
be a number of people in the field who were a lot smarter about
the issues than I was and I thought I could more productively
spend my time in other ways.   But another important one was
that I saw a little bit too much of reasoning that started from
"we have this solution, let's see where it can be applied",
rather than "this is a problem we need to solve because, let's
find a solution that addresses it without unnecessary
undesirable side effects" and I have trouble working that way.
It appears that nothing much have changed in 50 years except the
latter problem seems to have gotten worse.

Just as Ned wishes that some of the fundamental application and
deployment questions would be addressed in a serious way (and I
do too), I wish every security-related protocol document would
contain a mandatory section describing the threat model the
protocol or technique is intended to address and how it will
address it.

     john

---

From: "John Levine" <[email-masked]>
Date: 5 Feb 2016 21:10:42 -0000

>to reach everyone who wants to participate. 

Has anyone looked at the logs to see how much SSL3 there actually is?
In my logs, which are doubtless not representative of anyone but
they're what I've got, here's what I see for the past six weeks of
starttls on my IPv4 server:

22617 TLS1.2/X.509/AEAD
16791 TLS1.0/X.509/SHA1
2526 TLS1.2/X.509/SHA256
2069 TLS1.2/X.509/SHA384
1058 TLS1.2/X.509/SHA1
 339 TLS1.1/X.509/SHA1
 232 SSL3.0/X.509/SHA1
 147 TLS1.0/X.509/MD5
   8 TLS1.0/X.509/SHA256

And here's the past year on my lower volume IPv6 server:

130886 TLS1.2/X.509/AEAD
44172 TLS1.0/X.509/SHA1
6610 TLS1.2/X.509/SHA1
1485 TLS1.1/X.509/SHA1
 259 TLS1.2/X.509/SHA384

(The much higher numbers are mostly because gmail sends all their mail
to me over IPv6 with TLS.)

I was surprised to see 237 SSL3 connections, so I looked at the ones
in the past day, all of which are from two servers on a network in
Turkey running ancient versions of Merak, and trying to send me spam.
One is sending spam from the bogus domain globalconferences.org (no A,
AAAA, or MX record) presumably for fake conferences.  So at least
here, rejecting SSL3 would only block a little spam.

What do other people see?

R's,
John

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 5 Feb 2016 16:40:14 -0500

> here, rejecting SSL3 would only block a little spam.

I would be surprised by any legitimate SSL3 mail because the STARTTLS
spec came long after TLS 1.0 was settled.

There might be a mail server out there that cannot legitimately do TLS
but I would be very surprised. And any server that can't accept
TLS/1.0 inbound isn't compliant with the spec anyway.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 5 Feb 2016 15:39:28 -0500

> On Feb 5, 2016, at 3:08 PM, John C Klensin <[email-masked]> wrote:
> 

With my RFC7435 opportunistic security hat on, quoting from that
document:

   Cleartext, not comprehensive protection, is the default baseline.  An
   OS protocol is not falling back from comprehensive protection when
   that protection is not supported by all peers; rather, OS protocols
   aim to use the maximum protection that is available.  (At some point
   in time for a particular application or protocol all but a negligible
   fraction of peers might support encryption.  At that time, the
   baseline security might be raised from cleartext to always require
   encryption, and only authentication would have to be done
   opportunistically.)

   ...

   With unauthenticated, encrypted communication, OS protocols may
   employ more liberal settings than would be best practice when
   security is mandated by policy.  Some legacy systems support
   encryption, but implement only outdated algorithms or protocol
   versions.  Compatibility with these systems avoids the need to resort
   to cleartext fallback.

   ...

   The support of cleartext and the use of outdated algorithms, and
   especially broken algorithms, is for backwards compatibility with
   systems already deployed.  Protocol designs based on Opportunistic
   Security prefer to encrypt and prefer to use the best available
   encryption algorithms available.  OS protocols employ cleartext or
   broken encryption algorithms only with peers that do not appear to be
   capable of doing otherwise.  The eventual desire is to transition
   away from cleartext and broken algorithms, and particularly for
   broken algorithms, it is highly desirable to remove such
   functionality from implementations.

Bottom line, the decision to disable SSLv3 is reasonable provided
the impact of doing so, either in terms of loss of privacy or increase
in latency due to cleartext fallback, is truly negligible.

Curating the legacy broken crypto long past the time that effectively
nobody needs it is not a good idea.  That legacy crypto comes with
an increased attack surface and with opportunities for downgrade attacks
against peers that are capable of stronger crypto.

So opportunistic TLS applications like RFC3207 SMTP do need to tolerate
weaker crypto while it is needed for operational reasons, but need to
move forward once that is no longer the case.

It is my judgement that we've reached the point in the adoption curve
where we can abandon SSLv2, SSLv3, EXPORT ciphers and single-DES ciphers.
We are rapidly approaching a time when RC4 can also be turned off, and
may be there already, but that is not yet quite clear.

So there are operational judgement calls to be made here, and I am
reasonably confident that disabling SSLv3 at ietf.org is a sensible
call.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 5 Feb 2016 16:48:07 -0500

> On Feb 5, 2016, at 4:40 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> 

Surprise!

http://www.engardelinux.org/modules/index/list_archives.cgi?list=postfix-users&page=0279.html&month=2013-09

But that was in 2013, and my response was:

  As I mentioned, at this time, deprecating SSLv3 is most likely 
  counter-productive. I am hoping that in a couple of years it will 
  be a practical default for the SMTP client only, where you can 
  define exceptions for problem destinations via smtp_tls_policy_maps. 

  A polite note to their postmaster linking to this thread may 
  encourage them to start making plans to upgrade to inbound systems 
  that can support TLSv1 and up (strictly speaking the STARTTLS EHLO 
  response in SMTP promises support of TLS an IETF standard, not SSLv3).

The timeline for SSLv3 deprecation turned a bit better than I expected,
(for various reasons that were hard to predict in 2013), so at this point
"no SSLv2/SSLv3" is a good choice for both SMTP clients and servers.

-- 
	Viktor.

---

From: Lixia Zhang <[email-masked]>
Date: Mon, 8 Feb 2016 00:21:13 -0800

> On Jan 26, 2016, at 1:16 PM, Jari Arkko <[email-masked]> wrote:
> 
> 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.

and supposedly that's on the table now?
would be good to hear what's the plan here.

Lixia

---

From: [email-masked]
Date: Mon, 08 Feb 2016 08:35:31 -0800 (PST)

> would be good to hear what's the plan here.

Well, let's see. We have the UTA WG, which among other things is reworking the
standards having to do with email's use of TLS. 

We have the DMARC WG, which is addressing various issues surrounding the use of
DMARC, including but not limited to trying to solve the DMARC-list interaction
problem.

The DANE WG is working on one draft on using secure DNS for S/MIME
certificates, another on using DANE to associate PGP keys with email
addresses. And historically has done a bunch of work on SMTP security
using DANE.

There are regular discussion of various email security issues - far too many
to list here - on the ietf-smtp, perpass, and appsawg lists. And there
are probably other lists I'm forgetting about.

In summary, a lot of work has been done, and a lot more work is underway.

But none of this seems especially relevant in this context, so this is all
I'm going to say about it.

				Ned

---

From: Lixia Zhang <[email-masked]>
Date: Sun, 21 Feb 2016 09:08:12 -0800

> On Feb 8, 2016, at 8:35 AM, [email-masked] wrote:
> 
> 
> Well, let's see. We have the UTA WG, which among other things is reworking the standards having to do with email's use of TLS. 
> 
> We have the DMARC WG, which is addressing various issues surrounding the use of DMARC, including but not limited to trying to solve the DMARC-list interaction problem.
> 

apology for my slowness in responding to email.  thanks for the enumeration of ongoing effort, and I agree that none of this seems especially relevant, as my earlier question was specifically asking a plan to address Phillip's comment in his first reply to the SSLv3 announcement:

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.

I'd also add that this issue is not limited to just email (a cisco forecast claims that "Sixty-two percent of all Internet traffic will cross content delivery networks by 2019 globally", note that today's CDN traffic is not limited to videos, but includes other more critical contents).  
Lets recognize the fact that "Internet achieves end-to-end security by end-to-end encrypted channel" is an illusion, as data is not delivered through an end-to-end connection in many cases today, and it is likely to become more so with more mobiles and DTN-style apps. 

Lixia

---

From: John C Klensin <[email-masked]>
Date: Mon, 22 Feb 2016 04:01:45 -0500

--On Sunday, February 21, 2016 09:08 -0800 Lixia Zhang
<[email-masked]> wrote:

> 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.
> 
> I'd also add that this issue is not limited to just email (a
> cisco forecast claims that "Sixty-two percent of all Internet
> traffic will cross content delivery networks by 2019
> globally", note that today's CDN traffic is not limited to
> videos, but includes other more critical contents).   Lets
> recognize the fact that "Internet achieves end-to-end security
> by end-to-end encrypted channel" is an illusion, as data is
> not delivered through an end-to-end connection in many cases
> today, and it is likely to become more so with more mobiles
> and DTN-style apps. 

Lixia,

While I agree with everything you say above, I am not clear
about where you think it takes us.  In particular, there is a
layering issue involved with, e.g., "end to end" meaning
something different for IP and TCP than it does for, e.g., mail
payloads.   Precisely because of the comments you make above in
combination with the observation that there is a much more
extensive history of compromised servers (including those that
relay mail)than of compromises to the long-haul network, where
the latter is involved, I'm aware of only two alternatives:

	(i) Encryption of content on what the email community
	often describes as an end-to-end basis.
	
	(ii) More or less explicitly trusting every system
	involved in the transmission of the message.

In most cases, the second alternative should be treated with
derision.

As with packet headers at lower levels in the system, the above
does nothing to protect against those whose interest is in the
information about where traffic is originated and where it is
bound.

    john

---

From: [email-masked] (Martin Rex)
Date: Thu, 25 Feb 2016 09:07:25 +0100 (CET)

> for downgrade and other attacks against the vast majority of

I'm sorry, but this information is strange.

There exists *NO* downgrade vulnerability in TLS.

There is a well-known-stupid unprotected "downgrade dance" implemented
in a few web browsers, but that is something entirely different, and
not a property of TLS or SSLv3.

Btw. even SSLv3 still provides *ALL* the security properties officially
documented for TLSv1.2 in rfc5246 Appendix F.

What SSLv3 does not provide, however, is additional protection against
obvious abuses of the TLS protocol beyond its original security goals,
such as by ^SSL VPNs and Web Browsers.  For authentication-less
SMTP and programmatic clients, the original scope of TLS is sufficient,
and therefore SSLv3 a perfectly sensible option.

Disabling SSLv3 can not possibly provide any security benefit here,
but may cause interop problems and less security for a few old peers.

-Martin

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 25 Feb 2016 03:57:13 -0500

> On Feb 25, 2016, at 3:07 AM, Martin Rex <[email-masked]> wrote:
> 

Would you then go further and say that SMTP servers should leave SSLv2
and/or EXPORT ciphers or single-DES enabled?  If not, why not?

-- 
	Viktor.

---

From: Solarus <[email-masked]>
Date: Sat, 27 Feb 2016 00:02:58 +0100

> and/or EXPORT ciphers or single-DES enabled?  If not, why not?
No.
HTTPS, for exemple will fail if the client and the server have no
ciphers in common (cipher overlap).
But with SMTP, STARTTLS is an opportunistic encryption, if you don't
support the maximum of ciphers, the other server will send you mails in
cleartext.
And it's worse to receive and send mail in cleartext than with a weak
encryption.

Solarus

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 26 Feb 2016 18:46:46 -0500

> On Feb 26, 2016, at 6:02 PM, Solarus <[email-masked]> wrote:
> 

"No" as in they should not leave SSLv2/EXPORT/1DES enabled?

> And it's worse to receive and send mail in cleartext than with a weak

Your rationale seems to contradict the "No" response.

-- 
	Viktor.

---

From: Solarus <[email-masked]>
Date: Sat, 27 Feb 2016 01:09:36 +0100

> "No" as in they should not leave SSLv2/EXPORT/1DES enabled?

SSLv2 is no longer used or seen by MTA, so we can reasonably drop it's support.
But cleartext is still more used than SSLv3, so why would you drop SSLv3 support before forbidding cleartext inbound and outbound your MTA ?

As you said previously, it suits me better to ask postmasters to upgrade their MTA.

-Solarus

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 26 Feb 2016 20:11:15 -0500

> On Feb 26, 2016, at 7:09 PM, Solarus <[email-masked]> wrote:
> 

As I mentioned upthread, SSLv3 is also no longer used.  It makes
to not carry around useless baggage that increases the attack
surface and looks bad in audits.  No additional traffic is
protected by enabling SSLv3, the SSLv3-only MTAs are gone from
the public Internet (O.K. a negligible number may remain, but
this is no longer worth the penalty of keeping SSLv3 around).

-- 
	Viktor.