Re: [TLS] CRL Stapling? (was Re: I-D Action: draft-ietf-tls-multiple-cert-status-extension-00.txt)

[Jean-Marc Desperrier <[e-mail]>]

On 04/06/2012 06:31, Yngve N. Pettersen (Developer Opera Software ASA) 
wrote:
> Like Martin Rex, I am concerned that this would significantly increase 
> the complexity of the system:
>  - The servers would have to download both, and then decide which to use.
Not necessarily, the extension is still very useful if the servers 
systematically downloads the OCSP where available, and CRL when the 
intermediate CA have no OCSP. Or has been initially configured to do 
only one of the two.

The biggest problem with the OCSP only mode is that in many cases 
intermediate CA do not have OCSP responders, so that in practice, either 
the client doesn't check intermediate levels, or it will still have to 
do several network requests when using multi.

>  - Clients might need to associate the CRL data with the relevant CRL 
> URL in their cache (in case the client can use it later), but this 
> might lead to cache poisoning (the CRL might be valid, but it has been 
> obsoleted by a newer CRL revoking some cert).
>
Sounds valid until you realize that the CRL protocol currently does 
*nothing* to try to protect against outdated CRL poisoning.
It is not an aim, and if it were to become one, there would be a lot of 
other things to change.

They are many different strategy an attacker can currently use to poison 
the CRL cache with outdated entries, or to send a large scale attack 
target that will work against all victims that have their cache loaded 
with an old version of the CRL.

>  - The record format would have to be adapted, possibly including a 
> datatype for each entry in the list, alternatively a completely new 
> record (which would assume just one datatype was used for the 
> intermediates)
It makes sense to try to keep this as simple as possible and not handle 
too many different cases.

This could be done by adding just one additional status_type for the 
response, that includes the same  OCSPResponseList format as ocsp_multi, 
but where all level except the end entity one are defined to contain CRL 
entries.
And maybe making it a MUST for client to also accept this format when 
they request a multi-cert status.

>  - Each server having a cert from the same CA would each send the CRL 
> from that CA, which might require duplicate resolving if the CRL is 
> newer than the one currently cached.
I'm sorry I don't get what you mean exactly here. Duplicate resolving of 
what ? Duplicate downloading maybe.

>  - This is not suitable for the cached info extension for caching 
> across multiple servers: There might be a lot of these entries, 
> increasing handshake size, and it might be abused to learn which sites 
> the user have visited, since the extension must be sent before we know 
> which certificate the site will present.
Right now the cached info extension draft defines caching of only 
certificates path and trusted CA, not revocation info. Sending a lot of 
cached info entries quite defeats the purpose of the extension IMO. They 
are a few sites that use multiple certificates under separate 
hierarchies for the same dns name, but I don't really get how multi with 
CRL makes the situation actually worse as compared to the current case 
with OCSP only.

And also the best path would be not to implement support for this case 
in the constrained clients that are the target of thecached information 
extension and evangelize the concerned sites to just not do that. If the 
site really has many different certificates, won't this overflow the 
cache capacity of the constrained client anyway ?

> All in all, this adds so much complexity that I don't think it would 
> be worth the effort.
It would be nice to have also the opinion of other implementers.
And of the CAs for which emitting new intermediate certs with OCSP 
information, and managing the added OCSP responder is a significant 
burden. It would not be nice if the end result is that cert multi is of 
no use with them since they don't provide the intermediate OCSP anyway. 
Let's be honest, it's the small CAs that are the most significant 
security risk.