Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance

[Marsh Ray <[e-mail]>]

Martin Rex wrote:

> If you lock down established identites, then I do not see a problem with this.

Really, it's the upper layers that define how 'identity' is to be
interpreted. TLS may know that the certs on one end or the other is the
same, but that is not the same as saying that the actual app-layer
identities are interchangeable.

>> I do see however, that data probably needs to stop flowing after sending
>> a Finished message until receiving the peer's Finished message, but
>> that affects only one direction and last for one round trip, not two.
> 
> Why Finished?  I think its everything following the ChangeCipherSpec.

For all the reasons that the Finished message was added to the protocol?

Hmmm, is app data allowed prior to the first finished message? No way,
couldn't happen.

> Sending an alert when that happens and closing the connection
> is fine with me.

Certainly preferable to passing something unexpected.

> I'm wondering whether there are application that actively abuse
> this feature and would break if the TLS implementation would exhibit
> semantics similar to those I outlined above and fail with an error
> if the TLS implementation would reject application data while
> performing the renegotiation handshake.

I believe that there are TLS library implementations that conduct
renegotiation transparently to the application code unless the app
specifically requests it.

Really there are a few missing letters in the plaintext alphabet.

Handshake - A marker, encodes identity info.
0x00 - 0xFF traditional data byte values.
EOD - End of data, like EOF.

Without that 'handshake' value actually there in the middle of the
plaintext buffered data coming out of the API, I don't know how
application code can get this right.

I haven't seen a TLS library API that defines things that way though.
Many provide a callback for the identity change, but it's unclear
what happens to buffered plaintext at the time it's called.

> What about the application data sent between the ChangeCipherSpec
> and the Finished messages?

Possibly Handshake is really two messages, HandshakeCCS and
HandshakeFinished.

If app data is prohibited before the first Finished, and the RI ext
strongly ties the sessions together, does this issue go away?

- Marsh