Subject: [TLS] Consensus call for certificate URL extension

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 22 Sep 2008 21:52:59 -0700

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.

In either case, we can include hash agility as described in
http://trac.tools.ietf.org/wg/tls/trac/ticket/46. If there is support in
the working group for the use case where the certificate is updated
offline then we can possibly work on a new extension in a new document
that incorporates ideas expressed on the list.

Please express you preference on the list for one of these options by
10/6/2008.

Thanks,

Joe
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Yoav Nir <[email-masked]>
Date: Tue, 23 Sep 2008 09:49:00 +0300

(B)

I can live with A, but I don't like having deprecated extensions if we  
can avoid them.

---

From: Martin Rex <[email-masked]>
Date: Tue, 23 Sep 2008 08:57:18 +0200 (MEST)

> Please express you preference on the list for one of these options by

My position is

C)  leave as is, with hash optional
    (and recommend against implementing or deprecating this TLS extension)

Personally, I don't like this extension, because it creates a lot
of additional complexity and serious vulnerabilities for the server
(DoS of the Server being the mildest aspect).

Why do I NOT like making the hash mandatory?

If a client is able to provide the hash matching the certificate
found under that URL, it should equally be able to include the
certificate itself in the handshake instead of the URL and remove
all problems and vulnerabilities of this extension entirely.

I do NOT want to see that extension being pushed any further,
and making one with the hash mandatory would make it an encoragement.

-Martin

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Tue, 23 Sep 2008 07:27:07 -0400

I agree with Yoav and vote for B.

On 9/23/08 02:49 AM, "Yoav Nir" <[email-masked]> wrote:

(B)

--
Regards,
Uri
<Disclaimer>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 23 Sep 2008 06:47:08 -0700

At Mon, 22 Sep 2008 21:52:59 -0700,

(B)

-Ekr

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 23 Sep 2008 20:38:51 +0300

> cause deployment problems because there are no known deployments that

My preference is (B).

---

From: Mike <[email-masked]>
Date: Tue, 23 Sep 2008 11:03:02 -0700

>> cause deployment problems because there are no known deployments that

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.

Mike

---

From: Yoav Nir <[email-masked]>
Date: Tue, 23 Sep 2008 22:23:26 +0300

> its value, then it may just be validating a bogus certificate.

I would hope that the client downloads the certificate, and verifies  
that the private key that it holds matches the public key in the  
certificate before calculating the hash.

Whether the client does or does not hold the certificate, it must hold  
the private key.
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Martin Rex <[email-masked]>
Date: Tue, 23 Sep 2008 21:26:51 +0200 (MEST)

> client MUST NOT send a hash unless it has been configured with it by some

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

---

From: <[email-masked]>
Date: Wed, 24 Sep 2008 11:41:46 +0300

<not wearing any hats>

I'd be fine with (B), or with just deprecating the whole
extension (without creating a new extension to replace it).

Given the amount of use this extension has received so far 
(i.e. none), I don't think creating a new extension, or
otherwise adding more functionality (such as Alfred's
proposal for hash agility in #46) would be useful. 

Best regards,
Pasi 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of ext Joseph Salowey (jsalowey)
> Sent: 23 September, 2008 07:53
> To: [email-masked]
> Subject: [TLS] Consensus call for certificate URL extension
>

---

From: Mohamad Badra <[email-masked]>
Date: Wed, 24 Sep 2008 14:27:58 +0200

> Please express you preference on the list for one of these options by

My preference is B.
Best regards,
Badra

---

From: Nelson B Bolyard <[email-masked]>
Date: Wed, 24 Sep 2008 12:14:37 -0700

> that address the security issues that have been raised:

I vote for (A),  or for just deprecating the whole extension
(without creating a new extension to replace it, Pasi's suggestion),
for the reasons that Pasi gave.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 25 Sep 2008 09:24:25 +0200

If the assumption in (B), that there are no known deployments of this
extension, is correct, my preference is to deprecate the extension,
without creating a new extension with different properties.

The way I am reading the replies so far imply that few if anyone really
needs this extension.  If that is the case, I don't see why we need to
spend time on it.

/Simon

---

From: Yoav Nir <[email-masked]>
Date: Thu, 25 Sep 2008 12:07:09 +0300

> needs this extension.  If that is the case, I don't see why we need to

Well, somebody went to the trouble of writing it...

I can see the value of this for a protocol such as IKE, because there  
you need to send the whole cert (sometimes a chain, sometimes also a  
CRL) within one UDP packet. With TLS, I guess there is much less value  
there.

---

From: Magnus Nyström <[email-masked]>
Date: Thu, 25 Sep 2008 15:10:03 +0200 (W. Europe Daylight Time)

I do not know if this extension still has value or not, but as one of the 
authors of the original RFC 3546, I just wanted to provide some background 
...

This extension came about a long time ago when the WAP Forum (today: Open 
Mobile Alliance) was looking at introducing support for TLS in their 
architecture. Given bandwidth-constraints in the mobile networks at the 
time, it made sense to devise a way for clients to not having to send 
their certificates (or chains) but rather have the servers pick them up 
somewhere. Clearly, today's networks are more capable.

-- Magnus

On Thu, 25 Sep 2008, Yoav Nir wrote:

> I can see the value of this for a protocol such as IKE, because there you 
> need to send the whole cert (sometimes a chain, sometimes also a CRL) within 
> one UDP packet. With TLS, I guess there is much less value there.
>
>

---

From: Martin Rex <[email-masked]>
Date: Thu, 25 Sep 2008 21:50:05 +0200 (MEST)

> somewhere. Clearly, today's networks are more capable.

Avoiding XML where it isn't necessary will save magnitudes more than
an average SSL client cert (except maybe for CAs that abuse certs
as digital junkyards), and SSL session caching will not only save
bandwidth, but also computing power, especially on thin clients.

The client should not need to send any chain certificates besides
its own End-Entity (EE) cert if the CA which signed the clients EE cert
has been announced by the server in the certificate_authorities
list of the CertificateRequest message.

We should have fixed the wording of the TLS specs 1.0/1.1/1.2 
in this regard...  The certificate_list is originally defined in
7.4.2 in the Server Certificate message--where the server doesn't
know anything about the trust anchors known to the client and
therefore sending the entire chain is appropriate.

The structure is then referenced/reused in 7.4.6. Client Certificate,
but it fails to account for the fact that the client has been sent
a list of acceptable trust anchors by the Server in the CertificateRequest
message and ought therefore be perfectly capable to verify a reduced
chain up to one of the announced trust anchors from the
certificate_authorities list, not only a full chain up to a self-signed root.

-Martin