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

Nicolas Williams <> Fri, 26 March 2010 18:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6F21F3A6C15; Fri, 26 Mar 2010 11:18:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.411
X-Spam-Status: No, score=-3.411 tagged_above=-999 required=5 tests=[AWL=-0.957, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SKV7YAyV6JKj; Fri, 26 Mar 2010 11:18:24 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C9A693A6B5E; Fri, 26 Mar 2010 11:18:20 -0700 (PDT)
Received: from ( []) by (Switch-3.4.2/Switch-3.4.2) with ESMTP id o2QIIfdA027652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 26 Mar 2010 18:18:43 GMT
Received: from ( []) by (Switch-3.4.2/Switch-3.4.1) with ESMTP id o2QIIc22005807; Fri, 26 Mar 2010 18:18:38 GMT
Received: from by with ESMTP id 120204041269627441; Fri, 26 Mar 2010 11:17:21 -0700
Received: from Sun.COM (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 26 Mar 2010 11:17:20 -0700
Date: Fri, 26 Mar 2010 13:17:16 -0500
From: Nicolas Williams <>
To: "Yngve N. Pettersen" <>
Message-ID: <20100326181716.GG21244@Sun.COM>
References: <op.u95kjftmkvaitl@lessa-ii>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <op.u95kjftmkvaitl@lessa-ii>
User-Agent: Mutt/1.5.20 (2010-03-02)
X-Source-IP: []
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090208.4BACFA81.0062,ss=1,fgs=0
Cc: "" <>, "" <>
Subject: Re: [TLS] Possible revocation delay issue with TLS stapling
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 Mar 2010 18:18:25 -0000

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