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

[Yoav Nir <[e-mail]>]

Martin Rex wrote:
> 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.

I think it's enough to blob-compare the subject DN. As long as both certificates validate, and the subjects are the same, it's enough for "equivalence of identity". I guess applications may introduce more relaxed rules of identity equivalence (such as matching CN), but matching DN should be enough even for the TLS protocol.

An API for the application to determine if old identity is equivalent to the new identity sounds good, but I don't think it would be used correctly in practice. The rule for matching two different certificates for the same EE may not be product-specific or implementation-specific, but may be specific for the installation. A certain organization gave everyone one certificate for their identity, and another for their job.  Matching the two certificates involved querying a directory to find our whether this individual actually had that position. It's an abuse of PKIX, and no product would be ready to employ such logic, unless it was written locally by the IT department of that organization. 

So I think as much of the logic as possible should be in the TLS layer, rather than the application.