IETF Logo Mail Archive

Re: [TLS] Prohibiting SSL 3.0

Hubert Kario <hkario@redhat.com> Wed, 29 October 2014 10:44 UTC

Return-Path: <hkario@redhat.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 430111A1ADA for <tls@ietfa.amsl.com>; Wed, 29 Oct 2014 03:44:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level:
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 mMgVc9ifZpwS for <tls@ietfa.amsl.com>; Wed, 29 Oct 2014 03:44:07 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D83A1A8545 for <tls@ietf.org>; Wed, 29 Oct 2014 03:44:07 -0700 (PDT)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9TAi1Qn024125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 29 Oct 2014 06:44:01 -0400
Received: from pintsize.usersys.redhat.com (dhcp-0-150.brq.redhat.com [10.34.0.150]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9TAhxo3006921 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2014 06:44:00 -0400
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Wed, 29 Oct 2014 11:43:58 +0100
Message-ID: <5997229.rIz4Dkd6bP@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.1 (Linux/3.16.6-200.fc20.x86_64; KDE/4.14.1; x86_64; ; )
In-Reply-To: <877fzka1bf.fsf@mid.deneb.enyo.de>
References: <BLU177-W4981235CC3AA2325B8CC01C39F0@phx.gbl> <877fzka1bf.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/cSooWKYuNEnaTCOqdnEBpcxcyrA
Cc: Florian Weimer <fw@deneb.enyo.de>
Subject: Re: [TLS] Prohibiting SSL 3.0
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Oct 2014 10:44:10 -0000

On Tuesday 28 October 2014 12:19:48 Florian Weimer wrote:
> * Yuhong Bao:
> > I hope that a Internet-Draft prohibiting SSL 3.0 will be next.
> 
> RFC 6101 already has status “HISTORIC”.  I'm not sure what else the
> IETF can do.  The cryptographically protected version negotation means
> that there is no actual harm in supporting SSL 3.0 along with TLS.
> (Same for supporting earlier TLS versions.)

Even the TLS 1.3 draft says that a client SHOULD NOT send a SSLv2 compatible 
client hello with server support being stated as MAY. Similarly, the value for 
SSL 3.0 for record layer in client hello is mentioned as the backwards 
compatible option with no mention of recommendation against it.

I'd say an RFC that updates them to a MUST NOT/SHOULD NOT (respectively for 
SSLv2 and SSLv3, at the very least) is not entirely out of scope...

-- 
Regards,
Hubert Kario

v2.23.0 | Report a Bug | By Email