Re: IETF mail server and SSLv3

mrex@sap.com (Martin Rex) Tue, 01 March 2016 13:39 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 5A3A41B2C8D for <ietf@ietfa.amsl.com>; Tue, 1 Mar 2016 05:39:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.151
X-Spam-Level:
X-Spam-Status: No, score=-4.151 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, J_BACKHAIR_46=1, 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 QNIKHVhTNI85 for <ietf@ietfa.amsl.com>; Tue, 1 Mar 2016 05:39:29 -0800 (PST)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30A581B2C8B for <ietf@ietf.org>; Tue, 1 Mar 2016 05:39:28 -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 smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id D88362ACEB for <ietf@ietf.org>; Tue, 1 Mar 2016 14:39:26 +0100 (CET)
X-purgate-ID: 152705::1456839566-000073AB-08854AF1/0/0
X-purgate-size: 2000
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 CC1AB400A3 for <ietf@ietf.org>; Tue, 1 Mar 2016 14:39:26 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id A741B1A454; Tue, 1 Mar 2016 14:39:26 +0100 (CET)
Subject: Re: IETF mail server and SSLv3
In-Reply-To: <413C957A-FE3F-488F-9562-139724949A03@dukhovni.org>
To: ietf@ietf.org
Date: Tue, 1 Mar 2016 14:39:26 +0100 (CET)
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: <20160301133926.A741B1A454@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/Xgz-0CmZ4e8rpOxK35xWCZMxDPo>
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: Tue, 01 Mar 2016 13:39:31 -0000

Viktor Dukhovni wrote:
> 
>> Solarus <solarus@ultrawaves.fr> wrote:
>> 
>> 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 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).


This looks like an exxageration of what is not even a problem.


The issue was not about newly adding SSLv3 support to IETF mail
servers ("new baggage"), but about leaving something enabled that
_is_already_there_, has been there for quite a while, and does not
hurt the slightest bit.

You should know pretty well that there is provably ZERO additional
attack surface.  The SSLv3 handshake protocol protection ensures
that two TLS peers will always use TLS when both ends support it.

In the face of active attackers (man-in-the-middle), the attack
will succeed even with TLSv1.2 on both links client<->MitM<->server
due to the complete lack of authentication in SMTP with TLS.


"Looking bad in audits" is due to sending the wrong message and
obviously bogus audit checklists.  It would be preferable to get
the bogus audit checklists fixed, rather than creating an illusion
of security that provably doesn't exist here.

Even the (last) PCI 3.1 compliance standard got it correct in that
pretty much all of the alleged "vulnerabilities" known for SSLv3
and TLSv1.0 are non-practical for most programmatic SSLv3-protected
communication.  And when performing mutual cert-based authentication
the alleged weaknesses become pretty much irrelevant.


-Martin