Re: [TLS] TLS Protocol Version

["Blumenthal, Uri - 0662 - MITLL" <uri at ll.mit.edu>]

After following this discussion for a while, I can say that I too am against fooling around with protocol version number (or with re-purposing an existing field). A clean extension-based solution is what's needed. And if SSLv3 can't/won't support it - so be it.


----- Original Message -----
From: tls-bounces at ietf.org <tls-bounces at ietf.org>
To: tls at ietf.org <tls at ietf.org>
Sent: Wed Nov 18 06:18:47 2009
Subject: Re: [TLS] TLS Protocol Version

Me too. I am against doing anything that involves modifying the protocol version. 

-- 
Robert Dugal		Senior Software Developer
Certicom Corp.		A Subsidiary of Research In Motion 
rdugal at certicom.com
direct        905.501.3848
fax             905.507.4230
www.certicom.com


-----Original Message-----
From: tls-bounces at ietf.org [mailto:tls-bounces at ietf.org] On Behalf Of Yoav Nir
Sent: Wednesday, November 18, 2009 3:01 AM
To: mrex at sap.com
Cc: tls at ietf.org list
Subject: Re: [TLS] TLS Protocol Version

I'm very much against that.

The protocol version is something everyone looks at: clients, servers and middleboxes. 

OTOH the server_random field is treated as random. Yes, even the timestamp part.

I really believe that's the place for the server to signal.

As for the client signal, the fake ciphersuite is clean and not-elegant-but-ok.  However, for no reason other than aesthetics, the client signal should be similar to that of the server. And I'd use two magic values:
 - SUPPORT - (client or server) will use new calculation of Finished message
 - SAFE - (server only) Renegotiation is disabled. This allows a quicker fix. Not sure if this is really needed, though.

Then you just add the old verify_data to the Finished message, and there's no need for extensions.


On Nov 18, 2009, at 6:48 AM, Martin Rex wrote:

> I'm sorry for the confusion of the various discussions going on.
> 
> My idea is to use a bit in the server_version field of the ServerHello 
> PDU to transfer a signal from Server to Client only after the client 
> has indicated to understand this signal.
> 
> This signal bit is _NOT_ supposed to be used for 
> ClientHello.client_version _NOT_ for record layer version tagging and 
> neither for the version indicate in the TLS session state (because it 
> might confuse existing code), it is purely for transfer over the network.
> 
> -Martin
> 
> peter.robinson at rsa.com wrote:
>> 
>> There have been several posts which have discussed the possibility of 
>> re-using existing fields, rather than use the TLS extension 
>> mechanism. Using a field for anything but its intended purpose is 
>> fraught with danger. In particular, there has been discussion of re-purposing of bits of the TLS Protocol Version.
>> 
>> Our server code uses the TLS Protocol Version as a numeric value to 
>> negotiate the TLS version. If a client offers TLS 1.0 (3,1) and the 
>> server can do TLS
>> 1.2 (3,3), the server determines that TLS 1.0 (3,1) is less than TLS 
>> 1.2 (3.3), and then chooses TLS 1.0 (3,1).
>> 
>> If the decision was to signal via the top bit of the protocol 
>> version, then an updated client might offer TLS 1.0 patched (0x83, 1) 
>> and a not updated server can do TLS 1.2 (3,3), the server determines 
>> that TLS 1.0patched (0x83,1) is greater than TLS 1.2 (3,3), and then chooses TLS 1.2 (3,3)!
>> 
>> 
>> ------------------------------------------------
>> Peter Robinson - peter.robinson at rsa.com Engineering Manager RSA, The 
>> Security Division of EMC - http://www.rsa.com/ Level 32, Waterfront 
>> Place, 1 Eagle Street, Brisbane, Queensland 4000, AUSTRALIA.
>> Phone: +61 7 3227 4427, Mobile: +61 407 962 150, Fax: +61 7 3227 4400.


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls