Re: [TLS] Possible revocation delay issue with TLS stapling

[Nicolas Williams <[e-mail]>]

[Why not pile on?  I think there's an angle not covered.]

As others have pointed out this is nothing new, nor special about OCSP
versus CRLs, and they have pointed out the workaround for RPs that care.

The more interesting point, I think, is that instantaneous revocation is
like password synchronization: hard.  You can get down to a window of
minutes.  But instantaneous revocation?  I don't believe that's feasible
in real world deployments.  Also, revoking certs is not enough if you
want instantaneous revocation!  You'd also want to slam existing
connections, and yet we have no protocol for doing that.

However, quick revocation has much higher costs than quick password
synchronization.  That's because making it possible to revoke certs
quickly means making more frequent use of online infrastructure, and
more frequent validation of signatures, whereas with password synch you
need only push changes as quickly as possible to a relatively few
servers.  Nowadays that extra cost may be in the noise, but it's not
nothing, and it's the reason that we have the ability to have OCSP
responses without nonces.

Think of OCSP as a Kerberos-like ticketing facility, with certs+OCSP
being like TGTs with long renewable lifetimes (corresponding to the
certs' notAfter) but short lifetimes (corresponding to OCSP response
freshness requirements / nextUpdate).  If you care about quick
revocation then you can just tune down the OCSP response freshness
requirements such that they fall within a time window whose size is
comparable to the time needed for revocation notices to reach all the
relevant OCSP responders.  The trick is to find just the right setting.

Nico
--