DoS from unbounded outstanding CERTIFICATE_REQUESTs

[davidben]

The secondary certificates draft separates CERTIFICATE_REQUEST from CERTIFICATE_NEEDED. This seems needlessly complex and introduces a DoS on the receiver with client certificates.

Clients which prompt the user on client certificate decisions need a request binding before acting on a certificate request. Even without a prompt, cross-name pooling means that, without that request binding, the client doesn't even know which origin requested the certificate!

However, secondary certificates splits the request and the binding into two separate frames. There are no rules preventing a server from queuing up unboundedly meany CERTIFICATE_REQUEST frames to be matched with CERTIFICATE_NEEDED later. This means the server can easily DoS such a client by sending unboundedly many CERTIFICATE_REQUESTs.

Why is there a split in the first place? If they are associated with a stream, this neatly bounds the certificate requests by the bound of open streams and also means that, if a stream is canceled, any outstanding certificate requests on that stream may be aborted.

[mnot]

Closing, as we're no longer working on secondary certs.