[TLS] Possible revocation delay issue with TLS stapling

["Yngve N. Pettersen" <[e-mail]>]

Hi,

While considering aspects of my multiple certificate status suggestions a
few days ago I realized that TLS stapling (the TLS Certificate status
Extension)of OCSP exacerbates the inherent "delay problem" when a
certificate is revoked, depending on how long the OCSP response is valid.

A malicious server that have its certificate revoked will still be able to
use an old unexpired OCSP response in its stapled status reports to the
clients for quite a while after the revocation, since the response will
usually be valid for several days.

The problem with this delay, which is inherent in the current revocation
system, is manageable when clients are requesting the OCSP response
directly, since new visitors will be protected when the OCSP responder is
updated; old visitors have likely already been attacked.

But with stapling the client have to rely on the server to provide a valid
and up-to-date OCSP response. A malicious server won't do that, it will
continue to use a valid, but obsolete and incorrect status indication.

My proposal is to create a new OCSP extension for stapled responses:

       - Servers must include this extension in requests to the OCSP
responder
       - The responder must include this extension in responses requested
this way, and must issue them with a shorter validity time, probably
associated with the turnaround for CRL/OCSP updates
       - Clients check for the extension in the stapled responses and  
discard
them if they do not have the extension and fetch the revocation
information direct instead (OCSP for site, CRL for intermediates)

The OCSP responders should be able to prefabricate the responses with the
new extension (in addition to the normal responses), and might even be
able to map them for GET requests, depending on how predictable the server
requests are.


Reducing the validity period for stapled OCSP responses will reduce the
window of opportunity for a malicious server operator. We can never
completely eliminate a revocation delay, but we should be able to reduce
it as much as possible.

Adding this will require updates of servers, OCSP responders and clients,
and can possibly be associated with my proposed update for Multiple OCSP
stapling.

I would also suggest that the TLS WG RFC4366-bis draft add an entry in the
CertificateStatus security considerations about this issue. My suggestion
(as a starting point) would be something like this:

"Certificate status entries have a validity period. A server can continue
to send the entry to clients as long as the entry is valid, even if the
server's certificate has been revoked since the entry was originally
created, according to a direct and up-to-date query to the issuer's
repository."

-- 
Sincerely,
Yngve N. Pettersen

********************************************************************
Senior Developer                     Email: [e-mail]
Opera Software ASA                   http://www.opera.com/
Phone:  [phone]              Fax:    [phone]
********************************************************************