Re: [TLS] TLS document status update

[Eric Rescorla <ekr@xxxxxxxxxxxxxxxxxxxx>]

At Tue, 29 Apr 2008 20:54:52 -0700,
Nelson B Bolyard wrote:
> 
> 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.

Then I encourage you to take that up with PKIX, since it seems
clear to me that this is explicitly allowed (RFC 3280 S 3.1.):

   This confidence is obtained through the use of public key
   certificates, which are data structures that bind public key values
   to subjects.  The binding is asserted by having a trusted CA
   digitally sign each certificate.  The CA may base this assertion upon
   technical means (a.k.a., proof of possession through a challenge-
   response protocol), presentation of the private key, or on an
   assertion by the subject.  A certificate has a limited valid lifetime

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

The above material seems to be premised on the assumption that CAs
who issue certificates without PoP are acting improperly, but as
indicated above, I don't think that's at all clear, so I don't
really subscribe to the conclusion either.


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

Well, this would require creating an entirely new extension,
since the client_certificate_url extension has no way of 
indicating whether hash (or anything else) will be indicated
in the CertificateURL message, so the client can't safely
provide a GeneralName value without potentially sending
something the server can't handle. Not saying you shouldn't
propose such an extension, but I don't see how that's an
argument against requiring hash with this one.

-Ekr

_______________________________________________
TLS mailing list
TLS@xxxxxxxx
https://www.ietf.org/mailman/listinfo/tls