Subject: [TLS] TLS Renegotiation Indication by adding some meaning to radom values

From: Badra <[email-masked]>
Date: Fri, 4 Dec 2009 00:35:05 +0100

Hi,

Some of TLS parameters are opaque values, but if we provide them some
meaning or structuration, they may help processing the Server <--> Client
signaling in ServerHello and ClientHello.

I think the random values (or the session identifier) may help to
cryptographically bind renegotiation handshakes to the enclosing TLS
channel. IMO, there is no security concerns if, during the initial
handshake, a client generates a random value - using RFC 4086 (recommanded
by RFC5246) - removes the higher 2 bytes from the value and then delimits
the result (26-byte_random_value) with a special character SP (1 octet), so
the client replaces the generated 28-byte_random_value with
SP|26-byte_random_value|SP (| denotes concatenation).

A patched server must parse the client random value to check if it is
delimited and if then it must repeat the same way as the patched client to
generate its random value. Therefore, the patched client is able to parse
the random value and to detect whatever the server in face is patched or
not. if then both the client ad the server will use, during the
renegotiation handshake, the verify_data from Finished messages as random
values.

But random values are 28 octes (ignoring the GMT time for now). Three cases
are possible:

- the length of the verify-data is less 28 bytes: some computation is needed
to extend it to become 28 (using PRF for example)
- the length is more than 28: truncated value of 28-byte length should be
used
- the length is 28, do no computation.

Best regards,
Badra

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 3 Dec 2009 17:39:25 -0600

> Subject: Re: [TLS] TLS Renegotiation Indication by adding some meaning to radom values

If there are any other, better options, then IMO: no way, no, no, never
:)

So far I think there are better ways.

Nico
--