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

[Eric Rescorla <[e-mail]>]

At Fri, 27 Nov 2009 17:34:20 +0100 (MET),
Martin Rex wrote:
> 
> Eric Rescorla wrote:
> > 
> > At Fri, 27 Nov 2009 16:27:03 +0100 (MET),
> > Martin Rex wrote:
> > > 
> > > That problem can be trivially fixed.
> > > 
> > > We just memorize the non-encrypted Client.Finished and Server.Finished
> > > handshake messages in full, rather then just the contained verify_data.
> > 
> > Woah, that's scary....
> > 
> > We're going to take the exact messages that previously appeared on the
> > wire and inject them into the handshake hashes in order to *reduce*
> > ambiguity in the hash input stream? I mean, maybe that's OK, but it
> > sure isn't obviously OK.
> 
> What we would be doing is limiting the ambiguity with something
> arbitrary to the ambiguity with a very well-defined handshake
> message (actually, two of them).  

Hmm...

Thinking about this some more, consider the case of a client which
(improperly) ignores handshake messages which come out of sequence,
but still hashes them into handshake hashes.

In the simple attack where the server thinks there is a rehandshake
and the client thinks it is the initial handshake, what if the 
attacker between the client and the server injects the
replayed Client.Finished and Server.Finished messages into the message
stream going towards the client. The client would then ignore but hash
the messages with the result that the data hashed by the client being
the is the same as the data being hashed by the server and the attack
succeeds. Am I missing something here?

Obviously, one could just say that the client is misbehaving here
and so this doesn't matter (though I would note that others have expressed
concerns about what happens with implementation errors, and this is only
requires an error by one side, not both). However, I think it's illustrative
that we need to be pretty careful about introducing ambiguity between
messages that are on the wire and those that are merely hashed.

-Ekr