Re: [TLS] simplistic renego protection

[Michael D'Errico <[e-mail]>]

Nasko Oskov wrote:
> 
> It was indicated that some implementations use random value for the
> timestamp part of the random values exchanged. If this is correct and there
> are no interop issues with it, then we can use the timestamp as place to
> include a few bits as well. If we reserve the top 4 bit of the most
> significant byte, we can set them to predefined values to signal what we
> want. The side effect will be forwarding time enough in the future to allow
> us to move a newer version of the protocol:
> 
> $ date -d @`echo "ibase=16; F0000000" | bc`
> Mon Aug  5 01:04:00 PST 2097
> $ date -d @`echo "ibase=16; E0000000" | bc`
> Tue Feb  1 03:39:44 PST 2089
> 
> The benefit of using the timestamp is that it will be the same signal both
> ways. We don't have to alternate between cipher suites and other methods on
> the other way. I believe this will also be easier to implement, since new
> alert messages and unexpected server extensions will requre a lot more code
> change and case specific logic.
> 
> Using two values allows both client and server to maintain the calculation
> of the finished message intact, but have knowledge if the handshake is
> expected to be initial or renegotiated. If expectations don't match,
> handshaking is terminated.
> 
> Just an idea for signaling, since we are enumerating ideas.

Since there are implementations that randomize the timestamp, then with only
4 bits, there is a 1-in-16 chance that these implementations will randomly
generate one of the patterns.  If the full 32 bits were used, the odds go
down considerably.  Two specific dates could be used, one for client and one
for the server.

Though personally I prefer using the cipher suite and server version (just an
opinion).

Mike