Re: [TLS] Deprecating SSLv3

Nikos Mavrogiannopoulos <nmav@redhat.com> Sat, 22 November 2014 10:40 UTC

Return-Path: <nmavrogi@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 01E501A0180 for <tls@ietfa.amsl.com>; Sat, 22 Nov 2014 02:40:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.495
X-Spam-Level:
X-Spam-Status: No, score=-7.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_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 0fRu7nH-c5Gt for <tls@ietfa.amsl.com>; Sat, 22 Nov 2014 02:40:32 -0800 (PST)
Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C0E41A017A for <tls@ietf.org>; Sat, 22 Nov 2014 02:40:32 -0800 (PST)
Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id sAMAeSxB015598; Sat, 22 Nov 2014 05:40:28 -0500
Date: Sat, 22 Nov 2014 05:40:27 -0500
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Martin Thomson <martin.thomson@gmail.com>
Message-ID: <1052358743.2229177.1416652827952.JavaMail.zimbra@redhat.com>
In-Reply-To: <CABkgnnUsOh=4FFiahH4__SGj8ke39g2x0DJBTRruuNFgNHqY5Q@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> <1416584605.18312.21.camel@dhcp-2-127.brq.redhat.com> <CALR0ui+1e8pm+67Pn3LV_Pw2Ma1K7c2egWf=m7amDck9fAn62A@mail.gmail.com> <CABkgnnUsOh=4FFiahH4__SGj8ke39g2x0DJBTRruuNFgNHqY5Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.5.82.6]
X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF31 (Linux)/8.0.6_GA_5922)
Thread-Topic: Deprecating SSLv3
Thread-Index: Qg0fCCTwTi2j/rPt+QvNosGJAKaVvg==
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/u_3rMfYLJAfojTTt9emqQh18Z8Q
Cc: tls@ietf.org, Alfredo Pironti <alfredo@pironti.eu>
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: Sat, 22 Nov 2014 10:40:34 -0000

----- Original Message -----
> Yes, I would be sad if we couldn't say anything more definitive about
> the use of TLS on the big 'I' Internet.  People are of course welcome
> to use rot13 to protect their proprietary communications, noting that
> they won't remain proprietary long if they do.  The same applies here.
> I merged Alfredo's text, and though I've proposed some minor
> grammatical changes, you can see the results live here:
>   https://unicorn-wg.github.io/sslv3-diediedie/

I believe that comparison is way out of proportion, for the following reasons:
* First SSL 3.0 is still in use - at least my experience shows many
SSL 3.0 only services on a typical network (it did only take few hours to get
the first bug report when SSL 3.0 was disabled in the development branch of Fedora),
* there is no new attack on SSLv3 (the attack poodle uses on SSLv3 was already known 10
years ago), and the TLS protocol negotiation is still considered secure enough to
negotiate the latest version supported between two parties
* SSLv3 is orders of magnitude better than plaintext (or rot13).

The latter shows the actual dilema many face at the moment, which is not whether to replace 
SSL 3.0 with TLS 1.2, but what to do to interoperate with the services that can only use 
SSL 3.0 or plaintext. You may choose to ignore them of course but that would also render
that draft not applicable to them.

Note here that I am not advocating the use of SSL 3.0, but it would be beneficial for 
everyone if that draft also described a path which leads to the abolishment of SSL 3.0
in a secure way, for the ones that cannot avoid its use. That highlights the main difference 
with SSL 2.0 and rfc6176; there were no SSL 2.0-only services when it was published.

regards,
Nikos