IETF Logo Mail Archive

Re: [TLS] Deprecating SSLv3

Nikos Mavrogiannopoulos <nmav@redhat.com> Fri, 21 November 2014 15:43 UTC

Return-Path: <nmav@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 B74D11AD4EC for <tls@ietfa.amsl.com>; Fri, 21 Nov 2014 07:43:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.496
X-Spam-Level:
X-Spam-Status: No, score=-9.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, 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 5DSACOlTcMNx for <tls@ietfa.amsl.com>; Fri, 21 Nov 2014 07:43:46 -0800 (PST)
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 A87B81A1A4D for <tls@ietf.org>; Fri, 21 Nov 2014 07:43:30 -0800 (PST)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sALFhSc7019425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 21 Nov 2014 10:43:28 -0500
Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sALFhP68028731 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 21 Nov 2014 10:43:27 -0500
Message-ID: <1416584605.18312.21.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Alfredo Pironti <alfredo@pironti.eu>
Date: Fri, 21 Nov 2014 16:43:25 +0100
In-Reply-To: <CALR0uiLfH-p9EbGF_=J8XMEuMczMsZJMfECKDt5E0Q9BBEpDOQ@mail.gmail.com>
References: <CABkgnnWw9zsrqQzHVU0vXLJM+HBK3QYxJAZE+0kgGkEQEzwS=w@mail.gmail.com> <5462714E.5020201@polarssl.org> <CABkgnnUm=6TriH9UU-Uv8_rWt_CEvW1Xy8P_955ryFCvn3mWOA@mail.gmail.com> <1193984696.9333579.1416162106243.JavaMail.zimbra@redhat.com> <CALR0uiLfH-p9EbGF_=J8XMEuMczMsZJMfECKDt5E0Q9BBEpDOQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xovf_NLVnHdn35InjTRiytuK5ig
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Deprecating SSLv3
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: Fri, 21 Nov 2014 15:43:54 -0000

On Sun, 2014-11-16 at 23:22 +0100, Alfredo Pironti wrote:


> Yes, I agree this is a fair point. I'll complete the wording tomorrow
> in the pending PR, and these ideas will get into the updated version.

Some additional comments:
1. It has quite awkward structure. The main body of the document is at
the introduction section.

2. The text "Negotiation of SSLv3 from any version of TLS MUST NOT be
permitted."
Not sure I understand what it means. Does it mean that fallback to SSL
3.0 from any version of TLS MUST NOT be permitted?

3. The document doesn't provide any instructions for clients that have
no other way to communicate with a server that only supports SSL 3.0.
MUST NOT is nice in theory, but can only be enforced on the systems one
has control on, and if the advise is followed to the letter legacy
systems (not talking of web) will be only be accessible in plaintext.
I'd expect prohibiting the fallback dance instead, and requiring that
SSL 3.0 is negotiated only if TLS 1.0 or later are advertised in the
clientHello.

regards,
Nikos

v2.14.0 | Report a Bug | By Email