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

["Yngve N. Pettersen (Developer Opera Software ASA)" <[e-mail]>]

On Wed, 04 Jul 2012 03:30:13 +0200, Martin Rex <[e-mail]> wrote:

> 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.

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.



-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: [e-mail]
Opera Software ASA                   http://www.opera.com/
Phone:  [phone]              Fax:    [phone]
********************************************************************