Subject: [TLS] CertificateRequest

From: "Dieter Bratko" <[email-masked]>
Date: Wed, 21 Nov 2007 17:06:06 +0100

Hi all,

recently we have observed problems with SSL/TLS servers that send
large numbers of certificate authorities wihtin their CertificateRequest
message. For instance, one server sent 152 CA names (21613 bytes), 
another sent 164 (29293 bytes) within one record without fragmentation...
The client may have to check if any of its keys is appropriate for any 
of these 164 CAs received from the server. There is no way for the
client to tell the server to do not send or limit the number of certificate
authorities in the CertificateRequest message.
Have there ever been thoughts about, or would this group support a 
proposal for an extension allowing the client to first announce the 
DNs of the CAs for which it is able to fulfill a CertificateRequest? 
Usually a client only has a few number of keys (for instance 1 or 2)
to may be used for client authentication. The client could use an 
extension to send the DNs of these few CAs to the server who then 
-- if it is configured to request client authentication -- may include only
one (or some) of these few CA names in its CertificateRequest message
(instead of sending all its trusted CAs). 

Regards,
Dieter 
---------
Dieter Bratko, SIC/IAIK - Graz University of Technology
Inffeldgasse 16a, 8010 Graz, Austria, http://jce.iaik.tugraz.at/

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

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 22 Nov 2007 22:08:38 +1300

"Dieter Bratko" <[email-masked]> writes:

>recently we have observed problems with SSL/TLS servers that send large
>numbers of certificate authorities wihtin their CertificateRequest message.
>For instance, one server sent 152 CA names (21613 bytes), another sent 164
>(29293 bytes) within one record without fragmentation... The client may have
>to check if any of its keys is appropriate for any of these 164 CAs received
>from the server.

My suspicion is that this is just a pathological implementation that's
iterating through all the CAs it knows of (the count seems to be in the
ballpark of the set of automatically trusted CAs for Windows, depending on
which root cert updates have been applied).  I can't imagine that any server
would really trust 160 different CAs to authorise access.  To support this,
I've seen servers that send out cert requests without the admins even knowing
that they're doing it, and the servers certainly don't want or even know what
to do with a client cert when they send the request.

>Have there ever been thoughts about, or would this group support a proposal
>for an extension allowing the client to first announce the DNs of the CAs for
>which it is able to fulfill a CertificateRequest? Usually a client only has a
>few number of keys (for instance 1 or 2) to may be used for client
>authentication.

I've found that simply ignoring the contents of the cert request seems to work
pretty well.  Since there are servers sending out nonsensical requests, the
safest thing to do is just record that a request for a cert exists.  If you
have a cert, send it and let the server sort it out.  If you don't, send a no-
cert response, which deals nicely with servers that send out bogus requests.

Peter.

---

From: "Dieter Bratko" <[email-masked]>
Date: Thu, 22 Nov 2007 17:27:42 +0100

>  is just a pathological implementation that's
Unfortunetely not in these cases.

> ballpark of the set of automatically trusted CAs for Windows,
> depending on which root cert updates have been applied).
That's what I have done to simulate the behaviour (since the
servers have not been publicly accessible): I installed
IIS on my machine, requested client authentication with
default trust settings and IIS sent all the certificates in one
large record.

> I can't imagine that any server would really trust 160 different CAs
> to authorise access.
Yes, but as you say below it also may occur unintentionally.
For the client -- at the time when receiving a large list --
it makes no difference if the server has sent it because of
misconfiguration or because he actually trusts 160 or more
CAs :-)

> I've seen servers that send out cert requests without the
> admins even knowing that they're doing it
You are right. And also the trust pool -- and with it the list sent
within the CertificateRequest message -- may grow automatically
without interaction and knowing of the admins. In one of the cases
(where already over 200 certificates have been sent) it helped to
contact the admin and ask him to remove certificates from the list.
However, you won't do this anytime you find large list of CAs.
We were asked if there is a way for the client to tell the server to
not send all its CAs, but this is not possible.

> I've found that simply ignoring the contents of the cert request
> seems to work pretty well.  Since there are servers sending out
> nonsensical requests, the safest thing to do is just record that a
> request for a cert exists.  If you have a cert, send it and let the
> server sort it out.  If you don't, send a no-cert response, which
> deals nicely with servers that send out bogus requests.
It might require additional configuration options on the client side,
but you are right again. However, just when doing so a (large) CA
list sent by the server is not required at all and only waste of bandwith,
which especially may be of concern in constrained environments.

Regards,
Dieter

----- Original Message ----- 
From: Peter Gutmann
To: [email-masked] ; [email-masked]
Cc: [email-masked]
Sent: Thursday, November 22, 2007 10:08 AM
Subject: Re: [TLS] CertificateRequest

My suspicion is that this is just a pathological implementation that's
iterating through all the CAs it knows of (the count seems to be in the
ballpark of the set of automatically trusted CAs for Windows, depending on
which root cert updates have been applied).  I can't imagine that any server
would really trust 160 different CAs to authorise access.  To support this,
I've seen servers that send out cert requests without the admins even 
knowing
that they're doing it, and the servers certainly don't want or even know 
what
to do with a client cert when they send the request.

>few number of keys (for instance 1 or 2) to may be used for client

I've found that simply ignoring the contents of the cert request seems to 
work
pretty well.  Since there are servers sending out nonsensical requests, the
safest thing to do is just record that a request for a cert exists.  If you
have a cert, send it and let the server sort it out.  If you don't, send a 
no-
cert response, which deals nicely with servers that send out bogus requests.

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 23 Nov 2007 21:56:39 +1300

"Dieter Bratko" <[email-masked]> writes:

>However, just when doing so a (large) CA list sent by the server is not
>required at all and only waste of bandwith, which especially may be of
>concern in constrained environments.

Hmm, I see the potential for a nasty catch-22 here: Any server that's stupid
enough to send a list of 150-200 CAs in its request probably isn't going to
know about, or honour, the "Don't send me a huge long list of junk" extension
from the client :-).

Peter.

---

From: "Dieter Bratko" <[email-masked]>
Date: Fri, 23 Nov 2007 17:48:28 +0100

> Hmm, I see the potential for a nasty catch-22 here: Any server
> that's stupid enough to send a list of 150-200 CAs in its request
> probably isn't going to know about, or honour, the "Don't send 
> me a huge long list of junk" extension from the client :-).

Do not call the poor server stupid - it is just doing what it has been
configured to do :-). The same server  -- if (by default) supporting such
an (obviously remaining hypothetical :-) extension -- with the same
(maybe careless) configuration settings would not send the long list.

Regards,
Dieter