Re: [TLS] TLS document status update

[Nelson B Bolyard <nelson at bolyard.com>]

Eric Rescorla wrote, On 2008-04-29 17:37 PDT:
> [...] the attacker is presenting a certificate with
> Alice's public key and Alice is doing the signing. Remember
> that the key to the attack is that the attacker is able to
> get a cert for a name of his choice but with Alice's public
> key.

I call that CA malfeasance, having issued a cert without proof of
key possession.  Perhaps a server that trusts such a CA gets what it
deserves.

Given the usual assumptions of the improbability of key collisions, upon
which digital signature systems depend, I claim that in the absence of
- CA malfeasance,
- CA collusion,
- CA key compromise,
- EE (victim) key compromise,
- TLS server malfeasance (failing to verify signature on cert, or
  client's certificate verify message), and
- server application malfeasance (failure to verify authorization of
  the verified identity),
the worst the attacker can do is to substitute a certificate that causes
a denial of service.

In the unlikely event that the attacker is able to find a valid cert
with the same public key as the victim's, issued by one of the CAs trusted
by the server for client auth, it is very unlikely that the identity on
that cert is one of the attacker's choosing or under the control or even
influence of the attacker.  The probability that the attacker finds a
key collision for a valid cert with an identity that he controls (or from
which he directly benefits) is essentially the same as (equivalent to?) the
probability that he possesses or controls the victim's private key, which is
effectively EE key compromise, which I excluded above.  Substitution of a
"random" client cert (whose identity is not under the attacker's control or
to his benefit) is likely to result in no more than denial of service, for
the reasons stated.

But denial of service can be accomplished in many other more trivial ways.
The hash doesn't protect against it.

>> In any case, maybe the data that needs to be sent is not the
>> hash of the certificate, but rather the identity the client
>> wants to authenticate as.  This could be the subject DN, or
>> SAN from the certificate.  An advantage of using that is that
>> it is invariant even as the actual certificate is periodically
>> reissued.

Yes, I could accept that, too.  That appears to address the concern that
Eric (and others) have stated without imposing unnecessary limitations
and difficulties.  I agree with Martin's point that the client needs to
assert an identity, which the signature merely verifies.

A hash protects against some of the conditions I excluded above, but so
does an identity assertion.

> Perhaps yes, but that would require an actual change to the syntax of
> the protocol, whereas this is just a new requirement to use the
> existing syntax.

Yes, but perhaps it's worthy of undertaking to make that change.
Use of the extension could require either a hash or a GeneralName.

/Nelson
_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls