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

[Bodo Moeller <[e-mail]>]

On Nov 27, 2009, at 8:27 PM, Eric Rescorla wrote:

> 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.

While this looks a little far-fetched to me, many security issues  
found in practice seem far-fetched if you don't know that they're real  
-- what you're writing here is enough to convince me that if there's  
one canonical way to solve the security problem, it's with including  
explicit verify_data in renegotiation handshake hello extensions.

The one thing I don't agree with in draft-ietf-tls- 
renegotiation-01.txt regarding the extensions is having the  
ServerHello concatenate the client and server verify_data.  That's  
pointless given that the client sends its one verify_data in its  
extension -- the server should only send its own verify_data.



I have one more concern with draft-ietf-tls-renegotiation-01.txt:

The ID says
"By default, TLS implementations conforming to this document MUST  
verify that once the peer has been identified and authenticated within  
the TLS handshake, the identity does not change on subsequent  
renegotiations. For certificate based cipher suites, this means  
bitwise equality of the end-entity certificate. If the other end  
attempts to authenticate with a different identity, the renegotiation  
MUST fail. If the server_name extension is used, it MUST NOT change  
when doing renegotiation."
It makes sense to require this when a party conforming to this  
specification falls back to compatible mode, when it has determined  
that according to the handshake the peer does not conform to the  
specification.  However, if the client and server *both* confirm to  
the specification and thus have secure channel binding across  
renegotiations, there's no point in forbidding "identity" changes  
(which may not be really identity changes, but other create and yet  
valid uses of TLS renegotiation -- for example, consider a server that  
uses a particular ciphersuite [requiring a special certificate] only  
with authenticated clients [and thus in a renegotiation handshake], to  
name just one example).  There's no 1-to-1 mapping between certificate  
and "identities" -- at best a certificate is a particular "name", but  
a single entity can legitimately use multiple names.

Bodo