Re: [TLS] simplistic renego protection

[Yair Elharrar <[e-mail]>]

Michael D'Errico wrote:
> Nasko Oskov wrote:
>>
>> 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.

A few days ago I suggested using 'INIT' and 'RNEG' as fake timestamps for server-to-client signaling of the current session state. Both [fake] dates have passed so it's highly unlikely that they'll ever be used for anything else.


--

This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.

If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message