Re: [TLS] 1.0 or else (was Re: Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00) (Martin Rex) Thu, 29 January 2015 18:00 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 91EE11A1B4F for <>; Thu, 29 Jan 2015 10:00:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.55
X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eIE52pF2N21M for <>; Thu, 29 Jan 2015 10:00:36 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 96E431A1B6C for <>; Thu, 29 Jan 2015 10:00:35 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 48DAB3A3BF; Thu, 29 Jan 2015 19:00:33 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTP id 3D57342157; Thu, 29 Jan 2015 19:00:33 +0100 (CET)
Received: by (Postfix, from userid 10159) id 332D71B137; Thu, 29 Jan 2015 19:00:33 +0100 (CET)
In-Reply-To: <>
To: Martin Thomson <>
Date: Thu, 29 Jan 2015 19:00:33 +0100
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <>
Archived-At: <>
Cc: "<>" <>
Subject: Re: [TLS] 1.0 or else (was Re: Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00)
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 29 Jan 2015 18:00:38 -0000

Martin Thomson wrote:
> Martin Rex <> wrote:
>> 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.
> Our limited survey thus far has identified only a small number (0.27%)
> of sites [1][2] that can't handle our TLS 1.2 handshake [3], even
> though they will tolerate our TLS 1.0 handshake.  In contrast,
> disabling SSL3 affected more than twice this amount.

For our TLS client and our customers, the amount of public Websites
with TLS extension or TLS version intolerance is not very meaningful.

We do _not_ provide a browser.  Our customers are using our TLS client
for programmatic data exchange scenarios.  Historically most was PKCS7,
but newer scenarios often use WebService/SOAP.  However, we know very
little about our customers' usage scenarios, except that we are
not permitted to break it with software updates.

A while ago I mentioned this site:

which uses TLS-protected data exchange, authenticated by SSL client certs,
on the following endpoints:

both of these (TLSv1.0) services are TLS version tolerant,
but will abort the handshake with a fatal unexpected_message alert
when the ClientHello contains *any* TLS extensions.

This server/service became known to me only by coincidence.  For a short
time, the service seems to have been selecting a TLS cipher suite that
our TLS client did not propose.  A customer reported the interop problem
because it affected a production scenario. But when I analyzed the
scenario, I could no longer reproduce that handshake failure with our

Reproducing handshake failures with OpenSSL is trivial, though.
It seems impossible to have the openssl 1.0.1 s_client send an
extension-less TLS ClientHello. (only 0.9.8 s_client with "-no_ticket").

We will not be able to ship any substantial change in client behaviour
as default behaviour, but will have to limit it to "explicit customer opt-in"
-- which means that the vast majority of customers will not use it.

Substantial changes that are well known to cause interop problems are
 - use of TLS extensions in initial ClientHello
 - use of ClientHello.client_version > (3,1) for initial ClientHello
 - use of record layer protocol version other than (3,0) or (3,1)
   for initial ClientHello

adding a small number of TLS cipher suites IDs to ClientHello creates
only a manageable risk (rfc5746 did not cause any interop problems).

This is why I would really appreciate a mechanism bein standardized
similar to the one described in this message:

One additional round-trip is a completely negligent price for
full interop.  Heavily used communication links see a
ratio of session resumes vs full handshakes of 10:1 to 50:1,
so most of the time, the additional round trip on a clean
initial handshake will not matter anyway.  With the information
stored in the existing regular client-side TLS session cache,
the fall-forward strategy can also be avoided.  No additional
heuristics nor additoinal per-server caching of meta-data necessary.