Hello all,

In light of the recent discussion about using SCSVs to protect against  
version rollbacks, I decided to write up my own proposal, which is already  
used in Opera.

This method uses the Renego Information (RI) extension as an indication  
that the server is version and extension intolerant, and require the  
client to only connect to the server using its highest supported TLS  
version and extensions when the RI extension is encountered, if necessary  
restarting the connection to do so.

This approach should, according to my testing, work with  more than 99.86%  
of Renego patched servers, using just one connection to establish the  
connection. Currently, 70% of servers are Renego patched.

With respect to the steps in the procedure, under normal conditions the  
client will be able to establish a connection on the first try with 95% of  
servers that are not patched for Renego, for the remaining servers (about  
1.5% of all servers), one or more attempts using older protocol versions  
will be needed.

If implemented, this method will naturally be obsoleted when clients  
change to only accept connections with Renego patched servers and  
remove/disable all code for performing version rollbacks.

------- Forwarded message -------
Subject: New Version Notification for  
draft-pettersen-tls-version-rollback-removal-00.txt
Date: Tue, 03 Jul 2012 09:49:54 +0200


A new version of I-D, draft-pettersen-tls-version-rollback-removal-00.txt
has been successfully submitted by Yngve N. Pettersen and posted to the
IETF repository.

Filename:	 draft-pettersen-tls-version-rollback-removal
Revision:	 00
Title:		 Managing and removing automatic version rollback in TLS Clients
Creation date:	 2012-07-03
WG ID:		 Individual Submission
Number of pages: 6
URL:
http://www.ietf.org/internet-drafts/draft-pettersen-tls-version-rollback-removal-00.txt
Status:
http://datatracker.ietf.org/doc/draft-pettersen-tls-version-rollback-removal
Htmlized:
http://tools.ietf.org/html/draft-pettersen-tls-version-rollback-removal-00


Abstract:
     Ever since vendors started deploying TLS 1.0 clients, these clients
     have had to handle server implementations that do not tolerate the
     TLS version supported by the client, usually by automatically
     signaling an older supported version instead.  Such version rollbacks
     represent a potential security hazard, if the older version should
     become vulnerable to attacks.  The same history repeated when TLS
     Extensions were introduced, as some servers would not negotiate with
     clients that sent these protocol extensions, forcing clients to
     reduce protocol functionality in order to maintain interoperability.

     This document outlines a procedure to help clients decide when they
     may use version rollback to maintain interoperability with legacy
     servers, under what conditions the clients should not allow version
     rollbacks, such as when the server has indicated support for the TLS
     Renegotiation Information extension.  The intention of this procedure
     is to limit the use of automatic version rollback to legacy servers
     and eventually eliminate its use.



-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: yngve@opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 23 69 32 60              Fax:    +47 23 69 24 01
********************************************************************