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

[Michael D'Errico <[e-mail]>]

Bodo Moeller wrote:
> 
> 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.

In addition, a TLS 1.2 server may have two certificates for the *same* name;
one signed with SHA-1 and another signed with SHA-256.

Mike