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

"Yngve N. Pettersen" <yngve@opera.com> Mon, 26 September 2011 23:09 UTC

Return-Path: <yngve@opera.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 A47BF21F8D2A for <tls@ietfa.amsl.com>; Mon, 26 Sep 2011 16:09:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.562
X-Spam-Level:
X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 xvL4flqbj0xi for <tls@ietfa.amsl.com>; Mon, 26 Sep 2011 16:09:55 -0700 (PDT)
Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 008C921F8D0D for <tls@ietf.org>; Mon, 26 Sep 2011 16:09:54 -0700 (PDT)
Received: from lessa-ii (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p8QNCU49028821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Sep 2011 23:12:32 GMT
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
To: "Florian Weimer" <fweimer@bfk.de>, "Martin Rex" <mrex@sap.com>
References: <201109261427.p8QERf9g008042@fs4113.wdf.sap.corp>
Date: Tue, 27 Sep 2011 01:12:34 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: "Yngve N. Pettersen" <yngve@opera.com>
Organization: Opera Software ASA
Message-ID: <op.v2fuq8d4kvaitl@lessa-ii>
In-Reply-To: <201109261427.p8QERf9g008042@fs4113.wdf.sap.corp>
User-Agent: Opera Mail/10.62 (Win32)
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
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: Mon, 26 Sep 2011 23:09:56 -0000

On Mon, 26 Sep 2011 16:27:41 +0200, Martin Rex <mrex@sap.com> wrote:

> It seems that no TLS client that propose TLSv1.1 or higher today
> would want to do so without a reconnect fallback facility in place.
> The problem of the reconnect fallback is, that it precludes a protected
> negotiation of the TLS version.

As long as there is no way to tell if a server is negotiating version  
correctly, then we do need a fallback mechanism.

It is, however, a mechanism that for HTTPS, at least, is becoming less  
needed, as I indicated earlier in this thread.

I also think we have a mechanism now that can be used as an indicator that  
the server can negotiate version in the required fashion, without needing  
a fallback system: The Renegotiation Indication Extension.

The Renego specification contain a reminder about version and extension  
tolerance being required. (Yes, I lobbied for the inclusion of that  
particular text).

My testing indicates that the tolerance is included in most Renego patched  
servers. The failure rate in my sample is 0.092% up to and including TLS  
1.2, mostly extension intolerance. The version intolerance for version  
code 3.x >= 3.4 is 0.049%. There is some problems with the 4.x+ range,  
though, due to a missing patch at at least one vendor.

(To compare the numbers, this is slightly less than the number of servers  
that may break if the patch suggested for the BEAST issue is implemented,  
according to my testing.)

My suggestion is that clients that use a fallback policy to an older  
version than their highest supported version, in case negotiation fails,  
should always negotiate with their highest version indicated if the server  
is detected as having been Renego patched, and then not fall back in case  
negotiation fails.

That would essentially eliminate the version rollback potential, at least  
without a weakness being discovered in the protocol integrity check itself.

One way to implement such a policy is that the client starts with TLS 1.0  
+ extensions, and only upgrade to TLS 1.1 or TLS 1.2 if it detects that  
the server is renego patched.

Alternatively (and I prefer this), the client can start with a higher  
version, and fall back as needed (currently for 1.8% of the sites), but go  
back up if the server is detected as Renego patched. This would have the  
benefit that the client saves time when connecting to 98+% of the servers,  
by not needing a fallback or an upgrade in a new connection.

Currently, 30% (463) of the (max) TLS 1.1 servers are not renego patched  
servers, only a single of the 133 registered TLS 1.2 servers isn't  
patched. This group is 0.2% of the unpatched servers (39.9%).

I doubt that any other mechanism will work better, and deployment will be  
at least 3 years behind the Renego curve, and will probably have a lower  
server deployment rate than Renego.

Let's see if we can work with what we have, before we design a new  
mechanism.

-- 
Sincerely,
Yngve N. Pettersen

********************************************************************
Senior Developer                     Email: yngve@opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************