Subject: Re: [TLS] TLS Protocol Version

From: "Blumenthal, Uri - 0662 - MITLL" <[email-masked]>
Date: Wed, 18 Nov 2009 16:57:52 -0500

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.

Is it the only viable solution???

----- Original Message -----
From: Martin Rex <[email-masked]>
To: Blumenthal, Uri - 0662 - MITLL
Cc: [email-masked] <[email-masked]>
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

---

From: Martin Rex <[email-masked]>
Date: Wed, 18 Nov 2009 23:49:32 +0100 (MET)

> Is it the only viable solution???

I am open to suggestions and improvements.

It is the best one that _I_ have found in the SSLv3/TLSv1.0
ServerHello PDU (there are not that much elements to choose from).

Since this signal is security relevant, *I* strongly prefer
that old servers are extremely unlikely to create this value by accident.

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

In principle, I tend to agree.

However, we are actually changing several past revisions of a protocol
in a significant and purposely non-interoperable fashion -- because
that interoperability turned out to be a security problem.

I will try to provide sufficiently clear guidance to implementors
what this particular change means -- and only code which implements
the fix will ever be confronted with this changed semantics that
should _only_ be visible in the network transfer encoding.

It is really just method to compress an extra bit of information
representing a protocal change orthogonal to existing protocol
versions into the network transfer encoding of the
server_version element in the ServerHello PDU.

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 18 Nov 2009 15:17:51 -0800

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

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>