Re: [TLS] Verify data in the RI extension?

[Martin Rex <[e-mail]>]

Eric Rescorla wrote:
> 
> This isn't to say that one couldn't design a mechanism that didn't
> carry the signaling data over the wire--one obviously could. 
> However, when I look back over the 50 or so messages that were
> sent to the list yesterday, a large fraction of them are various
> tweaks on exactly how incorporate that data, which suggests to
> me that this approach isn't at all easy to reason about.

We just carry the original handshake messages and be done with it.

As David outlined stripping the original message header from
the verify_data wasn't such a good idea, because it opens a
theoretical possibility of an attack.  Fine, we leave the
header on.

Messing around with the PRF, that is ideas from implementors
that never came in contact with FIPS 140-2 and interfaces to
crypto hardware and requirements around that.

And it would make everything much more complicated because of
the differences between SSLv3 and TLS. 

Adding the previous Finished messages at the very beginning of
the handshake message hash is less straight-forward.

When the client sends the renegotiation ClientHello, it must
have previously sent the Client.Finished, so we could add that,
however it may have not yet received the Server.Finished from
the previous handshake, so this must go into the handshake
message hash after ClientHello in order to be on the safe side.


-Martin