Re: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00

Kurt Roeckx <kurt@roeckx.be> Wed, 28 January 2015 23:10 UTC

Return-Path: <kurt@roeckx.be>
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 B2BDE1A1BFC for <tls@ietfa.amsl.com>; Wed, 28 Jan 2015 15:10:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 DwafkeugG6_u for <tls@ietfa.amsl.com>; Wed, 28 Jan 2015 15:10:15 -0800 (PST)
Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) (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 264571A1C04 for <tls@ietf.org>; Wed, 28 Jan 2015 15:10:12 -0800 (PST)
Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id D992D1C2140; Thu, 29 Jan 2015 00:10:09 +0100 (CET)
Received: by intrepid.roeckx.be (Postfix, from userid 1000) id A6FFA1FE0108; Thu, 29 Jan 2015 00:10:09 +0100 (CET)
Date: Thu, 29 Jan 2015 00:10:09 +0100
From: Kurt Roeckx <kurt@roeckx.be>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Message-ID: <20150128231009.GA25284@roeckx.be>
References: <9A043F3CF02CD34C8E74AC1594475C73AAF694DD@uxcn10-tdc05.UoA.auckland.ac.nz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAF694DD@uxcn10-tdc05.UoA.auckland.ac.nz>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/rlATnGm1epJvPAMoF_PciXMTpBk>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00
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, 28 Jan 2015 23:10:23 -0000

On Wed, Jan 28, 2015 at 08:06:32AM +0000, Peter Gutmann wrote:
> Dave Garrett <davemgarrett@gmail.com> writes:
> 
> >Is it at all practical to publish an TLS RFC stating intent to deprecate TLS
> >1.0/1.1 within some fixed timeframe? I think everyone would rather phase it
> >out then have to "be the hitman" each time.
> 
> I'm happy to have 1.0 phased out, but I'd make the baseline 1.1, not 1.2.  1.1
> fixes the major issues with SSL (no support for extensions, no per-message IV)
> without being a major rewrite like 1.2 is.  There's an awful lot of stuff
> outside of the browser world that can move to 1.1 if it isn't there already,
> but that's going to take a long, long time to move to 1.2 if it ever does.
> Killing 1.0 (which is really just SSL IETF-ised) is a pretty straightforward
> step if you're already getting rid of SSL because it has most of the same
> problems, but deprecating 1.1 is going a bit too far.

TLS 1.1 and 1.2 have only seen widespread adoption recently
because the major libraries only implemented it recently.  For
some reason 1.2 actually seems to better support than 1.1.  There
are a strange set of servers out there that support 1.0 and 1.2
but not 1.1.

Here is an overview of when I know they get implemented:
library  | TLS 1.1 | TLS 1.2
---------+---------+--------
openssl  | 2012-03 | 2012-03
nss      | 2012-10 | 2013-06
gnutls   | 2004-02 | 2006-11 (like 2 years before they got published)
schannel | 2009-07 | 2009-07

But was is more important I think is when they actually got
enabled by default in applications:
application | TLS 1.1 | TLS 1.2
------------+---------+--------
firefox     | 2013-09 | 2013-09
chrome      | 2012-09 | 2013-08
ie          | 2013-10 | 2013-10
safari      | 2013-10 | 2013-10
opera       | 2013-07 | 2013-10

On the server side it's a little harder to tell since I guess they
just get enabled but not used and servers don't get upgraded that
much.  But there we can instead just try to connect to it and see
the progress.  We're now between 50% and 70% that support TLS 1.2
depending on who you ask.  But there is also still around 10% that
support SSLv2.

My best guess is that around 85% of the clients support TLS 1.2 by
now, but I guess there are some people here who can do better then
guess.  It's unfortunate that we see this monthly stats for
servers but not for clients.

My current expectation is that it's most likely going to take
until 2020 to actually get TLS 1.2 support to the level we now see
for TLS 1.0 (around 99.5%) for both client and server.


Kurt