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

From: Peter Gutmann <[email-masked]>
Date: Wed, 28 Jan 2015 08:06:32 +0000

Dave Garrett <[email-masked]> 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.

Peter.

---

From: Kurt Roeckx <[email-masked]>
Date: Thu, 29 Jan 2015 00:10:09 +0100

> 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

---

From: [email-masked] (Martin Rex)
Date: Thu, 29 Jan 2015 00:31:37 +0100 (CET)

Kurt Roeckx wrote:
> Peter Gutmann wrote:
>>
>> There's an awful lot of stuff outside of the browser world that can
>> move to 1.1 if it isn't there already,

The differences between TLSv1.0 and TLSv1.1 are marginal, and when
TLSv1.0 is used with 1/(n-1) record splitting, they provide essentially
the same security -- but TLSv1.1 is *MUCH* less interoperable.

That's not quite true.  There es little, if any stuff outside of the
browser world that could go to > extension-less TLSv1.0, because there
are still too many servers out there that will abort the handshake
when extensions are present or when the version is > TLSv1.0.

Adding insecure reconnect fallbacks, aka "downgrade dance" to each and
every application caller is a complete non-starter.

If there was a standardized fashion how to upgrade from an
extensionless TLSv1.0 ClientHello to an extension-bloated TLSv1.2
ClientHello that works in-band and is completely transparent to the
application caller, then I would gladly add this to both, our
clients and our servers.

> are a strange set of servers out there that support 1.0 and 1.2

Yes, I've seen those servers.  One of them is:

https://www.portaldasfinancas.gov.pt/

>From what I've been told, they're using an SSL accellerator.  Might be A10.
Will negotiate TLSv1.2 or TLSv1.0, but not TLSv1.1.

They run a few WebServices on related servers with similar configuration
for a legally required data exchange with the portuguese tax authorities.

-Martin

---

From: Hubert Kario <[email-masked]>
Date: Thu, 29 Jan 2015 11:18:44 +0100

On Thursday 29 January 2015 00:10:09 Kurt Roeckx wrote:
> > >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.
> 
> For

bug in openssl, SSL_OP_ALL from OpenSSL 1.0.0 did include SSL_OP_NO_TLSv1_1 
when run against OpenSSL 1.0.1:
https://rt.openssl.org/Ticket/Display.html?id=2802&user=guest&pass=guest

which you should know, given that you have submitted the above bug report ;)

-- 
Regards,
Hubert Kario

---

From: Kurt Roeckx <[email-masked]>
Date: Thu, 29 Jan 2015 19:18:50 +0100

> which you should know, given that you have submitted the above bug report ;)

I do know about that bug report.  The only people that should have
been affected by it were those that compiled against 1.0.1 and not
against ealier or later releases like any 1.0.0* or 1.0.1[a-l].

The sites that have this behaviour are also larger sites that
probably use some kind of accelator hardware, and I suspect it's
that hardware that doesn't do TLS 1.1.  At least 1 site I know
about that doesn't know TLS 1.1 but does TLS 1.2 is also
vulnerable to poodle in TLS, so they can't be using openssl.

Kurt

---

From: Hubert Kario <[email-masked]>
Date: Fri, 30 Jan 2015 11:32:31 +0100

On Thursday 29 January 2015 19:18:50 Kurt Roeckx wrote:
> probably use some kind of accelator hardware, 

well, one thing doesn't exclude the other - especially given the support for 
`engine` in OpenSSL

> and I suspect it's

interesting...
-- 
Regards,
Hubert Kario