Subject: Re: [TLS] TLS Protocol Version

From: "Blumenthal, Uri - 0662 - MITLL" <[email-masked]>
Date: Wed, 18 Nov 2009 07:02:58 -0500

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: [email-masked] <[email-masked]>
To: [email-masked] <[email-masked]>
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 
[email-masked]
direct        905.501.3848
fax             905.507.4230
www.certicom.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yoav Nir
Sent: Wednesday, November 18, 2009 3:01 AM
To: [email-masked]
Cc: [email-masked] 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
> 
> [email-masked] 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 - [email-masked] 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
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Martin Rex <[email-masked]>
Date: Wed, 18 Nov 2009 22:42:43 +0100 (MET)

Blumenthal, Uri - 0662 - MITLL wrote:
> 
> 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.

This is definitely not about fooling around.
It is strictly about compressing the information in the
ServerHello.server_version field while it travels the network
in a fashion that the client will understand perfectly well.

I expect that we will want to make the protected renegotiation
part of the TLSv1.3 base spec, and will prohibit the use of the
unprotected TLS renegotiation if the protocol version TLSv1.3
is negotiated.

So it is actually the exact same position in the client code
(parsing of ServerHello) that will decide when secure renegotiation
is used there.

   if ( 0!=(ServerHello.server_version & PATCHED_RENEGO_FLAG) )
        || (ServerHello.server_version & ~PATCHED_RENEGO_FLAG) >= TLSv13 ) {
      s->use_secure_renegotiation = TRUE;
   }

So it is a very good and the most natural place.

We are definitely changing an essential part of the protocol.
But we are also changing it orthogonal to regular TLS-versioning,
i.e. were _NOT_ creating TLSv1.3, but instead we are creating
modified protocol versions of  SSLv3, TLSv1.0, TLSv1.1 and TLSv1.2

What exactly is you problem with sacrificing a bit of the
server_version network encoding(!) in order to signal a protocol
change that is orthogonal to TLS protocol versioning?

-Martin

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 19 Nov 2009 13:14:37 +1300

"Blumenthal, Uri - 0662 - MITLL" <[email-masked]> writes:

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

I've kept quiet so far but I have to venture an opinion at this point: having
followed the massive amount of information exchanged so far, I think the
magic-cipher-suite + modified-finished is far, far cleaner than the extension
Russian roulette option.

Peter.