Re: [TLS] matching identity, by default

[Martin Rex <[e-mail]>]

Marsh Ray wrote:
> 
> > The TLS renegotiation vulnerability allowed to pass along the
> > TLS endpoint during renegotiation freely, an in particular to
> > unsuspecting TLS peers.
> > 
> > The secure renegotiation will ensure that the endpoint of
> > a renegotiated TLS session will be tied securely to the
> > endpoints of the enclosing TLS session.
> 
> Yes, it will be possible for authentication credentials/certificates to
> change. That's one of the primary purposes of renegotiation.
>
> It ensures continuity-of-identity of the client and server across all
> the [unnamed things between handshakes] on the connection.

I'm sorry, but these two things are mutually exclusive.
The TLS renegotiation fix addresses only the TLS endpoint thing,
it does absolutely nothing about the identities.


continuity-of-identity is _ONLY_ possible if you lock down the
certificates of the peers during renegotiation.  That is _not_
part of the TLS renegotiation fix.

Any notion of identity related to attributes in the certificate that
was used to carry the public key around is out-of-scope for TLS.
Two certs that differ in at least one bit refer to seperate
identies, as far as TLS is concerned.

It may be that an application considers a Server certificate for
CN=www.foo.com issued by VeriSign and another one with the
same CN=www.foo.com issued by GlobalSign to be interchangeable,
but they _DEFINITELY_ are completely different identities.

If you have an end user cert and a renewed end user cert
(same public key, same CA, but different validity), then
these might refer to the same Identity in your PKI, but
for TLS these are definitely distinct identities.


-Martin