Re: [TLS] matching identity, by default

[Marsh Ray <[e-mail]>]

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

There's more to identities than certificates. Is there not more to
"Martin Rex" than his driver's license?

> continuity-of-identity is _ONLY_ possible if you lock down the
> certificates of the peers during renegotiation.

No, even anon-anon sessions have identity. Why do you think they call it
a "session identifier"? Isn't resuming such a session different than
establishing a new one? If not, why do you still have to prove you know
the master_secret?

> That is _not_
> part of the TLS renegotiation fix.

In the case of HTTPS client certs for example, an anonymous-client
session was established and transferred data. Then the connection was
renegotiated to provide a client cert, and the data from the previous
session was authenticated retroactively.

This was not a design error! It was entirely reasonable for the HTTPS
designers who had worked with SSLv2 in the past to expect that SSLv3
would not degrade on any of its basic guarantees, even if the new
feature of renegotiation was used.

The mistake was that the SSLv3 designers thought that by ensuring
continuity-of-encryption (the new handshake is encrypted with the
connection state of the old) they were also providing
continuity-of-authentication. Or else they thought, like Martin, that an
anonymous endpoint had no identity whatsoever, and a
certificate-authenticated identity would be re-validated on the handshake.

The reality is that that initial "anonymous" session does in fact have a
very important identity: he's "the party that sent me the data that I am
now authenticating with this client certificate". In order to do this
securely, you have to prove that he is the same party as the one now
sending you the certificate. In other words, you have to authenticate
the anonymous client as being the certified client, and the certified
client as being the anonymous client!

The way we accomplish this in draft-ietf-tls-renegotiation is by having
each side present something in the current connection state that
unambiguously states their belief about the previous session state. In
this way they cooperate to enforce the continuity-of-authentication, but
this only works because both the client and server systems have an
interest in seeing that this is done securely.

Once our fix reestablishes continuity-of-authentication between
connection states, it ensures that the actual party remains the same. It
does this regardless of certificates (or lack thereof). This has a
dramatic effect: it changes the auth model from
independent-authentication-per-connection-state to
cumulative-over-entire-connection! 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!
(whatever that means for the specific application protocol)

> 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.

There's nothing in the TLS spec that says such a thing.

> 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.

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!

They are separate credentials though. Whether or not they are treated as
equivalent is extremely context-dependent.

> 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.

I have been working in the authentication business for a few years now
and have learned a lot. I have seen plenty of subtle bugs and security
issues caused by imprecise definitions and mismatching assumptions about
identity. There is in fact an entire sub-industry dedicated to "Identity
Management Solutions" which makes products for these problems.

I'm not saying this to convince you how much I know about it, but to say
that I am sure that I don't know much about it at all. Identity is an
extremely deep concept with many context-dependent perspectives and
opportunities for error. Authentication is a fundamental human activity
(and for other animals as well), so most of us are experts in it at some
biological level. We also tend to vastly oversimpify issues of identity
and underestimate our capacity for error. "Social engineering" is one
whole category of examples, the concept of "identity theft" is another.

The TLS specs were very wise to defer these issues elsewhere, especially
since it deals with a rich mixture of cipher suites and credential types.

So riddle me this, Batman: How can someone reading this know that this
is the authentic "Marsh Ray" emailing with the authentic "Martin Rex"?
In particular, how can we know that you or I were not accidentally
switched at the hospital shortly after birth? Do "birth certificates"
represent the answer?

We should maybe follow this up off-list.

- Marsh