Re: [TLS] Consensus call for certificate URL extension

[Martin Rex <Martin.Rex at sap.com>]

Mike wrote:
> 
> >> We need to close this open issue.  I think there are two basic options
> >> that address the security issues that have been raised:
> >>
> >> A) Deprecate the current extension and create a similar new extension
> >> with the hash mandatory.
> >>
> >> B) Make the hash mandatory in the current extension.  This should not
> >> cause deployment problems because there are no known deployments that
> >> make the hash optional.
> 
> The problem with either of these options is that it gives the impression
> that adding the hash improves security.  As I mentioned before, if all a
> client does to determine the hash is download the certificate and compute
> its value, then it may just be validating a bogus certificate.
> 
> Making the hash mandatory prevents a client from effectively saying, "I
> have no idea if the certificate you are about to download is valid."  It
> would be much better to leave the hash as optional and to add that a
> client MUST NOT send a hash unless it has been configured with it by some
> other means.

I disagree with this description.

The purpose of the ClientCertificate message is to assert an identity,
The purpose of the CertificateVerify message is to prove that assertion.

If the certificate URL extension is used, the client NO LONGER asserts
an identity, it asserts an URL to *something*.

The purpose of the Hash is to enable the server to verify that he is
looking at the same *something* as the client.

If the client creates this hash by downloading the cert, computing
the hash over the cert and then sending the hash, then this looks
completely insecure and entirely useless to me.

If requiring the hash to be including results in TLS clients to
be just doing that, then we are creating a more complex and much
worse situation than we have now -- because many people will believe
it's more secure because of the required hash, whereas in fact,
a mere download and hash computation on the client side *without*
any further authentication/verification of the download cert
on the client side is just as insecure as not sending the hash.

Currently, there is no explicit requirement for the client to check
himself whether the ClientCertificate sent by the client really
asserts the identity that the client *WANTS* to assert (and neither
wether the CertificateVerify message checks out OK with that cert,
and this is mainly because we assumed that the client will hold
his key and his cert in a locally trusted fashion.

If the client is in posession of his client cert, it is IMHO
a bad idea to NOT send it and instead send a certificate URL
plus hash (because of the huge increase of complexity and
the resulting vulnerabilities for the server).


Now my understanding was that the client cert URL extension
should allow for clients that are unable to hold their cert
for whatever reason.  The resulting security problem for TLS
is now, how can we SECURELY ensure that the "offshored" certificate
is really the identity that the client *WANTS* to assert.

If you add up the resources that you need to SECURELY ensure
that the offshored certificate is the one that the clients
wants to assert plus the URL that the client needs to send,
you end up requiring more than for storage of an average client
cert -- Oooops!

If you leave out the means for the client to SECURELY verify
that the certificate described by the URL does in fact refer
to the identity that the client *WANTS* to assert, then you
have created a big security problem!


Unless a renegotiate is used, the client certificate is transfered
in the unprotected plaintext part of the handshake--just as the
CertificateURL and the hash.  The TLS finished MAC that protects
the entire handshake can only be verified at the end of the
entire SSL/TLS handshake, so it WILL NOT protect the processing
of the client certificate by the server during the handshake
if there is an MITM attacker.  The attacker won't be able to
get a TLS session established, but if all the attacker wants
is to insert a certificate of his choosing into the certification
path validation performed by the server, then he can do so
and the presence or absence of the certificateURL hash
will not have any effect.


However, the thing that really bothers me big time is the outlook
that those "constraint clients" that are summoned as motivators
for this extension are extremely like to fail badly on SECURELY
verifying that the identity asserted by the URL is really the
one that they *WANT* to assert (actually that it is the identity
that the owners/holders of the constrained clients want them
to assert), and mandating the hash for the CertificateURL
extension by itself does not address that vulnerability at all.


The only thing that this hash give us is protection against
the possibility that an attacker could get a cert issued for
the same public key by a trusted CA that the server will accept,
when the attacker listens to the SSL handshake and intercepts
or MITMs the servers certificate download request that results
from this handshake.  Or the same problem if the valid owner
of the key(pair) obtained different certs for the same public
key and sends the wrong URL.  Depending on how the client
acutally computes the certificate hash (blindly download
and hash the cert), this latter problem will remain completely
unsolved!



No matter how I look at this extension, I don't like it.

If anything, we should add a requirement that the client must
SECURELY verify that the identity asserted by the URL is the
one that the client intends to assert.  Only then the hash
will provide value, otherwise it is pure security theater.
But IHMO, such a sensible requirement might kill some of
the originally conceived "constrained clients" that
are quoted as motivators for this extension (but only because
they were broken and insecure from the beginning).


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