Re: IETF mail server and SSLv3

mrex@sap.com (Martin Rex) Thu, 25 February 2016 08:07 UTC

Return-Path: <mrex@sap.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 DAEDB1A0419 for <ietf@ietfa.amsl.com>; Thu, 25 Feb 2016 00:07:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level:
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 qmpwpApsmota for <ietf@ietfa.amsl.com>; Thu, 25 Feb 2016 00:07:28 -0800 (PST)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E67241A040C for <ietf@ietf.org>; Thu, 25 Feb 2016 00:07:27 -0800 (PST)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id B9A2644B3F for <ietf@ietf.org>; Thu, 25 Feb 2016 09:07:25 +0100 (CET)
X-purgate-ID: 152705::1456387645-00003552-7ACF0236/0/0
X-purgate-size: 1496
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id AC40440AFF for <ietf@ietf.org>; Thu, 25 Feb 2016 09:07:25 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 822301A43E; Thu, 25 Feb 2016 09:07:25 +0100 (CET)
Subject: Re: IETF mail server and SSLv3
In-Reply-To: <20160204024001.GM19242@mournblade.imrryr.org>
To: ietf@ietf.org
Date: Thu, 25 Feb 2016 09:07:25 +0100
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20160225080725.822301A43E@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/1ZBAVUrATdtGNlyNEtHE70K4rh8>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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: Thu, 25 Feb 2016 08:07:30 -0000

Viktor Dukhovni wrote:
> On Tue, Feb 02, 2016 at 09:00:02PM -0500, Derek Atkins wrote:
> 
> > Have you disabled non-TLS SMTP transport, too?
> 
> That would clearly be premature.
> 
> > If not, isn't there a chance that disabling SSLv3 will cause *SOME*
> > 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 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