Subject: [TLS] Fwd: New Version Notification for draft-pettersen-tls-version-rollback-removal-00.txt

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Tue, 03 Jul 2012 18:37:36 +0200

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: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 23 69 32 60              Fax:    +47 23 69 24 01
********************************************************************

---

From: [email-masked] (Martin Rex)
Date: Wed, 4 Jul 2012 03:30:13 +0200 (CEST)

If there is anything worth considering that it would be an
approach which has

   (a) the highest possible likelyhood to succees the TLS handshake
      -- which pretty much means extension-less ClientHello with
      ClientHello.ClientVersion either {3,0} or {3,1}

   (b) and simultaneously succeding that very same initial handshake
       with the highest common protocol version supported by both peers
       -- which pretty much means that the client must convey his highest
       supported version through a cipher suite value and that the
       updated server will ignore/override ClientHello.client_version
       when it detects the SCSV-based version negotiation.

This will on the very first handshake even when the client does not
cache information about the server's capabilities, and it will work
without incuring failed TLS handshakes--an approach that for some
software stacks would require each and every application to implement
a reconnect fallback.

-Martin

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Wed, 04 Jul 2012 10:07:37 +0200

> software stacks would require each and every application to implement

An extension-less Client Hello would not be able to provide some of the  
information we will need to send to the server, even if the content in the  
extensions was frozen by a specification. Two examples: Server Name  
Indication and any new extensions that are added. A frozen extension set  
would require new SCSVs every time it was updated, or for every  
combination that one might want to use., which is rather impractical IMO.

This means that a Client Hello with extension are needed for any new  
functionality we want to add, which means one have to deal with extension  
intolerant servers.

According to my research, my approach will currently work on the first  
connection (Max version, TLS 1.2, plus extensions) for 98.5% of servers  
out there. That number is steadily increasing, 6 months ago it was 98.35%.

Most of the rest are extension intolerant for some, or all TLS 1.0 - 1.2  
versions, some (1.5% of the group) are just version intolerant, and will  
require one or more extra connections to complete a handshake, and would  
also require this for an SCSV scenario with extensions. 94% of them are  
not Renego patched.

I doubt that using an SCSV to indicate highest version will remove the  
need to do version rollbacks for servers that does not support the SCSV,  
or in case of a downgrade attack being attempted. Also, using the SCSV  
method would not result in the version rollback method ever being retired.

I also suspect that any server that is not being updated to fix the Renego  
issue will not be updated to support the SCSV method.

My proposal have the benefit of leveraging an existing protocol feature,  
adapts an already existing negotiating sequence in web browser clients,  
works on first connection for most servers, even when the client signals  
TLS 1.2 and extensions, and does not require updating servers with a new  
feature once they are patched for Renego, and it automatically becomes  
redundant and can be removed when all servers support Renego and clients  
require it.

---

From: [email-masked] (Martin Rex)
Date: Thu, 5 Jul 2012 09:39:11 +0200 (CEST)

Personally, I consider going through a handshake failure an no-go
for standardization, and would rather like to see a slight (fully
optional and fully backwards-compatible) protocol modification
to support a succcessul TLS handshake with the most desirable
common characteristics, ZERO extra crypto overhead and a further
reduction of failed TLS handshakes on the internet.

Although retrying a TLS handshake with different characteristics after
a TLS handshake failure may be an option for some implementations and
some types of clients (in particular with Browsers), there are
applications and environments, where this option simply does not exist.

One other possibility to avoid waste of crypto cycles and a handshake
failure would be to specify&standardize an SCSV that can be used to
restart the handshake.  Wasn't something like this done for the
Server-Gated Crypto hacks in SSL3?

So a client could start with a "conservative" extension-less
SSLv3 ClientHello and include that SCSV, and a server who supports
a higher version number than offered in ClientHello.client_version
and/or supporting extensions that would acctually affect the
characteristics of the resulting handshake, could return
a ServerHello with that SCSV as the "common cihper suite",
(and maybe a ServerHelloExtension describing features that
can be safely used and may have been avoided by a conservative
client (potentially including things like DHE cipher suites
because of the small subgroup goof of some servers),
an upon receiving a ServerHello with that SCSV, the client
would simply restart the handshake with a full-blown
ClientHello carrying all the features that the client supports
and may want to offer.

For proposed session resumes, the client would then already have
the info about what the server supports in the TLS session cache,
so there would be no overhead for handshakes with proposed TLS
session resumes (even when the server perform occasional full
handshakes, as long as it returns a TLS session id, so that
this feature remains transparent/invisible to client applications.

SNI might become a useful feature in a few years.  Today there
is still a significant number of clients which does not support SNI,
and the interop problem that would result from an SNI prerequisite
is at least a magnitude larger than TLS version intolerance and
TLS extension intolerance problems.

-Martin