Re: [TLS] TLS Protocol Version

[Michael D'Errico <mike-list at pobox.com>]

Blumenthal, Uri - 0662 - MITLL wrote:
> I am concerned of "overloading" fields and assigning an additional
> meaning to them that they did not have. Not a clean design or
> programming practice, and prone to causing people or code used to
> the "old" meaning to stumble.

The client will still only send the versions used today.  It is only
when the server sees the magic cipher suite that it flips one bit in
the server version returned to the  client.

Unpatched clients will not send the special cipher suite, so they will
not be confused.

Also the version used in the record layer would not change as a result
(you mask off the bit when setting it).

> Is it the only viable solution???

It is 100% reliable.  Using the server random allows for a small
possibility of an unpatched server randomly generating whatever signal
we come up with.

I don't think it would be wise to try to use the returned cipher suite
or compression method.  The session ID is limited to 32 bytes, but in
theory it could be up to 255, so it would be possible to do something
there, though it seems dangerous.  I prefer using a single bit in the
version.   Those are the only fields in the SSLv3 ServerHello.

Mike



> ----- Original Message -----
> From: Martin Rex <mrex at sap.com>
> To: Blumenthal, Uri - 0662 - MITLL
> Cc: tls at ietf.org <tls at ietf.org>
> Sent: Wed Nov 18 16:42:43 2009
> Subject: Re: [TLS] TLS Protocol Version
>
> 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
> _______________________________________________
> TLS mailing list
> TLS at ietf.org
> https://www.ietf.org/mailman/listinfo/tls