Re: IETF mail server and SSLv3

ned+ietf@mauve.mrochek.com Fri, 05 February 2016 03:12 UTC

Return-Path: <ned+ietf@mauve.mrochek.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2318A1B3130 for <ietf@ietfa.amsl.com>; Thu, 4 Feb 2016 19:12:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlPZtRojq2uK for <ietf@ietfa.amsl.com>; Thu, 4 Feb 2016 19:12:06 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) by ietfa.amsl.com (Postfix) with ESMTP id 8DED01B312F for <ietf@ietf.org>; Thu, 4 Feb 2016 19:12:06 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PWAPWC8T28000R72@mauve.mrochek.com> for ietf@ietf.org; Thu, 4 Feb 2016 19:07:10 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: TEXT/PLAIN; CHARSET="us-ascii"
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PW7P38X61C00008P@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf@ietf.org; Thu, 04 Feb 2016 19:07:01 -0800 (PST)
From: ned+ietf@mauve.mrochek.com
Message-id: <01PWAPWAKLJI00008P@mauve.mrochek.com>
Date: Thu, 04 Feb 2016 19:00:44 -0800
Subject: Re: IETF mail server and SSLv3
In-reply-to: "Your message dated Thu, 04 Feb 2016 17:59:40 -0500" <08CEE02F-74DF-4C5E-A116-AB66FD8516FA@dukhovni.org>
References: <F38A9FEF-7DBB-4F40-860E-6CB425E5EEE3@ietf.org> <sjmvb66r1st.fsf@securerf.ihtfp.org> <20160204024001.GM19242@mournblade.imrryr.org> <C9624BB55C713BCF83E4A552@7AD4D3FB4841A5E367CCF211> <08CEE02F-74DF-4C5E-A116-AB66FD8516FA@dukhovni.org>
To: Viktor Dukhovni <ietf-dane@dukhovni.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/aCxLESILR-hL86nR8CUje_hWBMA>
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Feb 2016 03:12:08 -0000

> > On Feb 4, 2016, at 11:22 AM, John C Klensin <john-ietf@jck.com> 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.

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

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

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

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

				Ned