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

[Martin Rex <mrex at sap.com>]

Marsh Ray wrote:
> 
> Nicolas Williams wrote:
> > On Mon, Nov 09, 2009 at 10:52:31PM +0100, Martin Rex wrote:
> >> I whish there was a constraint that an identity/certificate that has
> >> been established for a party during the TLS handshake MUST not change
> >> during re-negotiation,
> 
> Hmm, few questions about that plan:
> 
> Is this currently a defined concept in TLS: equivalence of identity?

blob_compare(current-cert-blob,new-cert-blob)

Everything more complicated should be an apps issue--provided that
the apps has provided "convincing arguments" to the TLS implementation
(i.e. correctly instrumented the relevant APIs)
that it is competent to perform such a re-authentication as a result
of an identity change during renegotiation.

> 
> Isn't that one of the major uses of renegotiation? To change identity?

I simply don't know.  Our server doesn't support renegotiation.
And I learned our client to do it several years ago since it was
used in certain configurations of MS IIS to ask for a client
certificate after having seen the request.


>
> That seems to be the entire point of the observed cases of renegotiation
> in https. Even if the only case we know of is a transition from an
> anonymous identity to a client-certified one, such a new constraint
> seems a bit pointless and likely to break someone.

This might not accurately describe the situation you have in mind.

A client that has not sent a certificate (usually because the server
didn't send a CertificateRequest) is definitely not an "established
anonymous identity".  It is simply the absence of an identity.

The use of a DH_anon ciphersuite, on the other hand, might be considered
to establish an anonymous identity for the server.  I do not like the
DH_anon ciphersuites and I'm wondering what TLS implementations do
that provide applications a callback for verification of the server
cert which is usually called while processing the ServerCertificate
handshake message when the server selects a DH_anon ciphersuite
(in which case there is no ServerCertificate handshake message).



-Martin