Subject: [TLS] Next steps for Client Certificate URL

From: <[email-masked]>
Date: Fri, 28 Mar 2008 16:13:42 +0200

Hi,

We've seen two replies from people who have implemented the Client
Certificate URL extension (Certicom SSL-C toolkit and IAIK iSaSiLk).

Given that using this feature -- at least on client side -- probably
requires that the application specifically asks for it (and supplies
the URL in some API call), I would also guess that most applications
that use those two libraries don't actually use this particular
feature.

Given this, would everyone be OK with updating the existing
client_certificate_url extension so that including the hash is
mandatory (client MUST send, server MUST NOT accept without hash)?
This behavior would be independent of the negotiated TLS version.

(One obvious alternative would be to deprecate current
client_certificate_url, and allocate a new extension number.)

Best regards,
Pasi
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Russ Housley <[email-masked]>
Date: Fri, 28 Mar 2008 15:22:26 -0400

This integrity protection is important.  I support the suggestion.

Russ

---

From: Nelson B Bolyard <[email-masked]>
Date: Fri, 28 Mar 2008 13:28:02 -0700

> This behavior would be independent of the negotiated TLS version.

I'm trying to understand the attack against which this hash is going
to protect, that is not already adequately protected without it.
Can someone outline that attack here?

Presumably, the attack involves substituting a different certificate
than the one intended by the client.  To succeed the substitute cert
must bear a public key that will verify the client's signature in the
Certificate Verify message, and must bear a signature verifiable with
the public key from some CA trusted by the server for issuing client
auth certs.  That would seem to necessitate CA key compromise, or
client key compromise, or CA collusion with the attacker.  The hash
would not protect against client key compromise.

Is this hash intended to detect CA key compromise and/or collusion?

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sat, 29 Mar 2008 12:15:20 +0200

> Can someone outline that attack here?

Usually even if you do not have an attack at hand, it might be good to 
prove that a modification to a security protocol makes it no less 
secure. By adding the hash (and considering it ideal) it is not hard to 
prove that the modified scheme is as strong as by sending the 
certificate itself.

regards,
Nikos

---

From: Nelson B Bolyard <[email-masked]>
Date: Sat, 29 Mar 2008 08:21:58 -0700

> prove that the modified scheme is as strong as by sending the 

Given two protocols of equivalent security, the one with less overhead is
preferable in the marketplace.  If the best thing that can be said about
the addition of the hash is that it makes the protocol no less secure,
that is hardly a compelling reason to make it mandatory, as Pasi proposed.

In answer to Pasi's question, quoted above, I object to making purely
redundant processing required for client cert URLs in TLS.  It suffices
to be available. If a need for it arises, then it can be used.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 29 Mar 2008 08:26:53 -0700

At Fri, 28 Mar 2008 13:28:02 -0700,
> Is this hash intended to detect CA key compromise and/or collusion?

Why do you think it requires CA key compromise or collusion?

-Ekr

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sat, 29 Mar 2008 19:48:50 +0200

> that is hardly a compelling reason to make it mandatory, as Pasi proposed.

At least for me it is not obvious that the two protocols have equivalent 
security (but I cannot really say I have thoroughly studied them).

regards,
Nikos

---

From: <[email-masked]>
Date: Mon, 31 Mar 2008 10:45:09 +0300

This issue was originally raised by Ray Perlner from NIST:
http://www.ietf.org/mail-archive/web/tls/current/msg00881.html

Basically, without the hash, the client and the server could have
different idea on what client identity was authenticated, if there
exists several certificates containing the same public key. Note 
that all those certificates can be totally valid, and the situation 
doesn't assume key compromise or CA misbehavior.

Best regards,
Pasi

> -----Original Message-----
> From: ext Nelson B Bolyard [mailto:[email-masked]] 
> Sent: 28 March, 2008 22:28
> To: Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: [email-masked]
> Subject: Re: [TLS] Next steps for Client Certificate URL
>