Re: [TLS] matching identity, by default

[James Manger <[e-mail]>]

Marsh,

> In other words, an endpoint could
> renegotiate an anonymous connection ten times to provide ten different
> certificates, and the other party can securely treat all data sent over
> that connection as having been authenticated to all ten certificates!


This point about all data being authenticated by all certs is a good point to emphasis.
Unfortunately, it does not mean typical applications wont get confused (ie have vulnerabilities) when they hadn't explicitly anticipated that 10 certs could be renegotiated.

> I have a driver's license issued by Kansas and a passport issued by the
> US Dept of State, yet I do not assume two different identities.
> Sometimes, I am even requested to provide both!

Consider turning up to a Whitehouse check point, showing your credentials to a guard, and "renegotiating" whenever you like by showing another credential. A controller talking to the guard on the phone asks:
[controller] What is the name on the credential?
[guard] Marsh Ray
[controller] Type of credential?
[guard] passport
now you show the guard your driver license
[controller] Issuer of credential?
[guard] Kansas

The controller thinks he has authenticated Marsh Ray with a passport issued by Kansas.
If you happen to have a library card under a fake name and you showed that first, the controller might think he has authenticated Bugs Bunny with a Passport from the US Dept of State. Ouch! That might allow the wrong person into a Whitehouse party ;-)

In this analogy, the guard is a TLS library, the controller is an application, your cards are certificates, and the protocol of showing your cards is TLS (with the fix!).

Is the error the controller's fault or the guards fault? The application's or the TLS library's (or the protocol's for not providing sufficient guidance)?


This suggests another way for a TLS library to ensure it doesn't confuse an application that doesn't explicitly stated it is prepared for renegotiations.
A library could tell the application only about one peer identity it authenticates (probably the first it authenticates).
For instance, Java's HttpsURLConnection.getServerCertificates() method could return the same set of certificates for the life of the object (the life of the TLS connection), and simply not tell the application about any different certificates from renegotiations. The TLS library could still renegotiate and switch to new sessions, but the application would be blissfully unaware -- and still secure.

Somehow this behaviour doesn't feel quite right, but I think it would be ok. It might be easier to implement than comparing identities across negotiations, and it would cope with those (somewhat unbelievable) niche cases of renegotiating with a re-issued certificate etc.

-- 
James Manger