Re: [TLS] Protocol version bit to use,

[Martin Rex <mrex at sap.com>]

Bill Frantz wrote:
> 
> mike-list at pobox.com (Michael D'Errico) on Thursday, November 19, 2009 wrote:
> 
> >My suggestion is to set the upper bit of the minor version field.
> >This provides a clear and unmistakable signal to the client, and is
> >completely contained within the 0x03 major version number space.  Is
> >it a "hack", yeah, but it's entirely reasonable.
> 
> If I understand the minor version field correctly, there are 5 or 6 bits
> that are always sent as zero by all current versions of TLS/SSL. Any of
> them would be suitable as a S->C signal.
> 
> There may be advantages to using bits other than the 0x80 bit. For example,
> if the 0x04 bit is available, then it could be used for the signaling
> requirement, leaving 0x08 and higher available for future versions of TLS.
> This approach would still leave a simple ordered compare available for
> selecting the "most recent" protocol version both ends support.


I would _strongly_ prefer if the ServerHello.server_version field
would NOT be used in < or > comparisons while still carrying
the S->C signal.

The change in the handshake message hash algorithm for renegotiation
handshakes in order to provide secure renegotiation is a protocol
change that is orthogonal to the regular protocol versioning.

The signal should only be used for the network encoding and
the client should seperate the S->C signal from the protocol
version and store them in seperate variables.

In case there is another emergeny tomorrow (which I do NOT hope)
and we need to fix once again severa protocol versions into the past,
then shaving another bit may collide with such comparisons.

Otherwise people start wondering:
      is { 0x83,0x00 }  better or newer than { 0x03,0x03 } ?
   or is { 0x83,0x01 }  better or newer than { 0x03,0x04 } ?

Please, don't!


-Martin