Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3

[Marsh Ray <[e-mail]>]

Rob P Williams wrote:
> By changing the way the Finished message is calculated - you can make
> SSLv3 safer.

I think this is a good idea for SSLv3. (the proposed extension is better
for TLS)

> Approach:
> 
>     For initial handshakes - keep the calculation the same.
> 
>     For subsequent handshakes - 
>         append extra information to 'handshake_messages' before being
> hashed.
>         This could be as simple as a counter. 
>         This could be the finished data from the previous handshake.

It has to be something that MITM cannot prep the client or server into
matching. A 'renegotiating' bit is not sufficient, even a counter may
not be (M just renegotiates that same number of times before splicing).

Is it possible to define this in terms of what already exists? E.g.
simply "don't reset the handshake MAC state for renegotiations" ?

> 	I've attempted to draw a table of what would happen when
> renegotiating;
> 
> 	OC = old client
> 	NC = new client
> 	OS = old server
> 	NS = new server
> 
> 
>             OS   | NS
>            ------+-----
>       OC  |  .   | fail
>       NC  | fail | good
> 
> 
> OC-NS failure - is useful - 
>     it shows the attack being mitigated.
> NC-OS failure - is ALSO useful.
>     By attempting to renegotiate - you can verify if you are talking to
> an OS or NS.

Well, if the remote endpoint allows you to initiate a renegotiation. MS
IIS for example responds with a TCP RST, other implementations may be
less direct.

- Marsh