Re: [TLS] History of extensions

[Martin Rex <[e-mail]>]

Nicolas Williams wrote:
> 
> And I should add that the re-negotiation channel binding can be achieved
> _without_ ServerHello extensions!  If that means improved odds for
> interop, then you should consider it.

They could have, from the beginning of SSLv3...


With other words:

Currently  Finished is defined for both, initial and renegotiate as:

      struct {
          opaque verify_data[verify_data_length];
      } Finished;

      verify_data
         PRF(master_secret, finished_label, Hash(handshake_messages))
            [0..verify_data_length-1];

      finished_label
         For Finished messages sent by the client, the string
         "client finished".  For Finished messages sent by the server,
         the string "server finished".


If the original design had instead distinguished initial and
renegotiation like this, the problem would not exist:


      verify_data for initial handshakes:
         PRF(master_secret, finished_label, Hash(handshake_messages))
            [0..verify_data_length-1];

      verify_data for renegotiation handshakes:
         PRF(master_secret, finished_label, verify_data_of_previous_session,
             Hash(handshake_messages)) [0..verify_data_length-1];


The whole effort with the TLS RI extension is to securely distinguish old from
updated communication peers--provided they do not choke on TLS extensions.

Forward signaling client->server that the client is updated through a
special ciphersuite ID in the ciphersuite list of the ClientHello
is still fairly easy and probably quite interoperable.

Backwards signaling server->client that the server is updated is
a little more difficult because one would have to repurpose an element
of the ServerHello.  If there really are SSL implemenations that fill
the unix_gmt_time with all random data (instead of just fuzzing the
lower bits of it), then that part requires a less "pure" approach.

Maybe by confiscating a currently unused bit of the more tightly
controlled value ranges of other members of the ServerHello handshake
message (server_version.major, cipher_suite or compression_method).

Of course, the server would then only signal back to use the
secure finished message calculation for renegotiation handshakes,
for which the client had indicate to understand that protocol
change by including that special ciphersuites ID in the
cipher_suites list of the ClientHello handshake message.


...but actually, we wanted to Last Call Eric's proposal, didn't we? 

-Martin