Re: [TLS] simplistic renego protection

[Nasko Oskov <[e-mail]>]

Michael D'Errico wrote:
>The whole point of RI is to get the previous handshake's verify_data into
>the handshake messages of the current session.  This can be done without
>extensions and does not require any fallback logic.
>
>You just need three things:
>
>   1) a client-to-server signal
>   2) a server-to-client signal
>   3) somehow incorporate the previous verify_data in the handshake
>
>(1) can be achieved by simply incorporating a magic cipher suite in the
>ClientHello.  Since that is the *only* change to the handshake, it has zero
>possible interoperability problems.  Extensions are known to be
>problematic; web browsers have extremely complicated logic including
>reconnecting and falling back to not using extensions to try to accommodate
>the various server implementations.  This magic cipher suite signal would
>be used in all handshakes since it can not cause any problems.  Existing
>browser fallback logic would not get any more complicated.
>
>(2) can be done many ways but I think Martin came up with a better idea
>than the alert message I proposed.  It is to toggle the upper bit of the
>low-order byte of the version in the ServerHello.  For SSLv3, 0x0300 would
>become 0x0380; TLS 1.0, 0x0301 would become 0x0381, etc.  This is
>forward-compatible too; the next version of TLS would be 4.0, 0x0400.  This
>signal would be used in all handshakes from
>SSLv3 through TLS 1.2.  The version in the record layer would NOT change.
>
>(3) can be done in a variety of ways.  RI sends the data over the wire, but
>this is unnecessary since both the client and server know it already.  EKR
>doesn't like the idea of a "virtual" handshake message, but this is an
>easier way to incorporate the data than requiring changes to three PRF
>computations (SSLv3, TLS 1.0/1.1, and TLS 1.2).
>
>I'm open to suggestions for a better (3) or even better (1) and (2), though
>those seem sufficiently simple.

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.

Nasko