Re: [TLS] interop for TLS clients proposing TLSv1.1

Martin Rex <mrex@sap.com> Wed, 21 September 2011 22:22 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7171F0CFC for <tls@ietfa.amsl.com>; Wed, 21 Sep 2011 15:22:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.051
X-Spam-Level:
X-Spam-Status: No, score=-10.051 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjxsIXBwRIrQ for <tls@ietfa.amsl.com>; Wed, 21 Sep 2011 15:22:25 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id ADED81F0CF1 for <tls@ietf.org>; Wed, 21 Sep 2011 15:22:24 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p8LMOfV2009822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Sep 2011 00:24:46 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201109212224.p8LMOemO019618@fs4113.wdf.sap.corp>
To: ynir@checkpoint.com (Yoav Nir)
Date: Thu, 22 Sep 2011 00:24:40 +0200 (MEST)
In-Reply-To: <6FE09637-CE95-43E8-A3C0-9516E757DDBA@checkpoint.com> from "Yoav Nir" at Sep 22, 11 00:47:14 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] interop for TLS clients proposing TLSv1.1
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
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, 21 Sep 2011 22:22:27 -0000

Yoav Nir wrote:
> 
> Yngve N. Pettersen (Developer Opera Software ASA) wrote:
> >
> > Martin Rex <mrex@sap.com> wrote:
> > >
> > > Does anyone (SSL Labs, Opera, others) have any figures/stats about the
> > > current "TLSv1.1 version (in)tolerance" for TLS servers on the public
> > > internet?
> > 
> > This week's test of 609726 servers gave these numbers:
> > 
> >   * 1.145% of the probed servers were version intolerant for at least one  
> > of the current TLS versions (1.0, 1.1, 1.2)
> >   * 1.742% were extension intolerant for the same versions
> >   * 1.136% belonged in both groups
> > 
> > This gives an estimated total of 1.751% that are either version and/or  
> > extension intolerant for the currently defined TLS versions.
> > 
> > These numbers have been decreasing during the past year and a half, around  
> > January 2011 it was 1.951% just for the version intolerant, 2.657% in may  
> > 2010 (the extension numbers are not as detailed for those runs).
> > 
> > Most of the version intolerant are intolerant for TLS 1.1 and TLS 1.2, but  
> > some are SSLv3 only servers that are also intolerant for TLS 1.0. There is  
> > even a 0.007% share that support TLS 1.1 (quite a lot of which has "vpn"  
> > as the hostname).
> 
> By "version intolerant" do you mean that you're sending a TLS 1.1
> or 1.2 handshake message and the server rejects it?

> 
> If you send a TLS 1.0 handshake message, with the version field of the
> ClientHello showing 1.2, what portion of the servers would reject that
> (rather than just replying in TLS 1.0)?

The latter is what I'm actually interested in
(but seem not have been sufficiently clear about).

Sending TLSv1.1 or TLSv1.2 in the Record Layer for ClientHello
constitutes a version-intolerant client (or more appropriately
it indicates a client that is unwilling to talk TLSv1.0).

Other than a very last resort in trying to get a TLS handshake succeed
I see little value in sending a value above TLSv1.0 in the protocol
version field of the SSL3 Record carrying the initial ClientHello
on a connection.


> 
> If the portion is very low, it could be feasible to implement a
> client without fallback behavior.

Since "fallback behaviour" is dumped entirely on the app calling
the TLS implementation, I expect "clients without fallback behaviour"
to be the norm for programmatic clients.

The version intolerance stats for public servers on the internet
is not really representative.  I expect a significant amount of
version-intolerant servers to not be publicly accessible.


I'm seeing a desire to raise the number of TLS peers use TLSv1.1
with CBC-based cipher suites and explicit IVs, and I'm also
seeing a residual, non-negligible number of version intolerant
TLS servers interfering with original design of TLS protocol
version negotiation.

I would appreciate a solution for decoupling of these two
issues so that clients without fallback capabilities
become able to use TLSv1.1 right away, while neither facing
new interop problems or having to wait 5+ years for sufficient
of the version intolerant TLS servers to die.


-Martin