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

[[e-mail] (Martin Rex)]

Jean-Marc Desperrier wrote:
>
> 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.

Nope.  When intermediate CAs have no OCSP, no OCSP check will be performed.

Personally, I would never do CRL processing on a client during Online
authentication, because CRL processing is so completely screwed in
the standards (CRLs offers tons of complex features that have a guidance
-- if you don't understand this, get another CRL ...).

In terms of processing it, OCSP responses are a magnitude more reasonable
than CRLs (except that expecting the cert receiver instead of the cert
owner to shop around, that's a problem inherited from CRLs).


>
> >  - 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 use of the CRL to verify the server cert is to protect against the
*network peer* being the attacker.  Since the network peer in the case
of OCSP stapling is the source of these CRLs, this argument does not apply.


> 
> >  - 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.

I'm also slightly confused.  For the sake of robust and deterministically
predictable behaviour, either the conveyed stapled data ought to be used,
or the handshake aborted with an error.  Overriding data sent by the
server with stuff already in the cache or ignoring a fraction of them
and newly obtaining them sounds like a recipe for breaking this feature
badly, resulting in a user experience "works for some peers, but not
for others", similar to the transvalid server certificate nonsense
resulting from browser re-sorting and adding missing certs to the
certification path of the servers Certificate handshake message
instead of reporting a broken Server-side SSL/TLS implementation
that is clueless about reasonably managing PKI credentials and
correctly implementing TLS, and a server configuration that does
not accommodate for such brokenness of the SSL/TLS implementation of
the server.



> 
> >  - 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.


I believe it is not as bad as you describe it.  When two communication
peers perform lots of TLS handshakes with each other in short time,
they should be using the abbreviated TLS handshake aka "TLS session resume",
in which case the server should not send any stapled OCSP responses in
the ServerHello at all.

If there is a problem with SSL session caching&resume, then that
problem should be taken care of and fixed.


> 
> 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 ?

Huh?

For a constrained client, not having to implement OCSP/CRL chasing
(= wget/curl) would be a great savings, if revocation does matter at all.


-Martin