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

Jean-Marc Desperrier <jmdesp@free.fr> Fri, 26 March 2010 09:40 UTC

Return-Path: <jmdesp@free.fr>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4520C3A6812; Fri, 26 Mar 2010 02:40:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.131
X-Spam-Level: *
X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gP8OSoWs+0l9; Fri, 26 Mar 2010 02:40:24 -0700 (PDT)
Received: from smtp-ft3.fr.colt.net (smtp-ft3.fr.colt.net [213.41.78.205]) by core3.amsl.com (Postfix) with ESMTP id ED0EB3A67B3; Fri, 26 Mar 2010 02:40:23 -0700 (PDT)
Received: from smtp-ex3.fr.colt.net (smtp-ex3.fr.colt.net [213.41.78.196]) by smtp-ft3.fr.colt.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o2Q9ehgR030279; Fri, 26 Mar 2010 10:40:43 +0100
Received: from host.104.92.68.195.rev.coltfrance.com ([195.68.92.104] helo=[172.30.24.37]) by smtp-ex3.fr.colt.net with esmtp (Exim) (envelope-from <jmdesp@free.fr>) id 1Nv620-00083M-0A; Fri, 26 Mar 2010 10:40:44 +0100
Message-ID: <4BAC80FD.4060603@free.fr>
Date: Fri, 26 Mar 2010 10:40:13 +0100
From: Jean-Marc Desperrier <jmdesp@free.fr>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10pre) Gecko/20100321 SeaMonkey/2.0.5pre
MIME-Version: 1.0
To: "pkix@ietf.org" <pkix@ietf.org>, "tls@ietf.org" <tls@ietf.org>
References: <op.u95kjftmkvaitl@lessa-ii> <4BAC5C33.8020509@seantek.com>
In-Reply-To: <4BAC5C33.8020509@seantek.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Warning: IP [195.68.92.104] is listed at dnsbl.sorbs.net (127.0.0.10: Dynamic IP Addresses See: http://www.sorbs.net/lookup.shtml?195.68.92.104)
X-ACL-Warn: 4/4 recipients OK.
X-Mailman-Approved-At: Fri, 26 Mar 2010 07:39:19 -0700
Cc: dev+ietf@seantek.com
Subject: Re: [TLS] [pkix] Possible revocation delay issue with TLS stapling
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Mar 2010 09:40:25 -0000

Sean Leonard wrote:
> 2.(a) Your suggestion says that "servers" must include this extension in
> requests. How does the OCSP responder verify that the requester is a
> "server"? It cannot. So, if the CA is concerned about the staleness
> problem, why not just update OCSP information for all OCSP requests on a
> shorter interval?

The operational cost of the short interval is higher.

So with that extension the server is saying : I'm highly sensitive *and* 
I'll optimize your network load, therefore trying to optimize your costs 
by giving me a long lived response is not the optimal strategy. Please 
give me a truer response of when you'll really be able to have fresher info.

What you write in details later is true, this is just an optimization, 
different strategy could be used to not need it, and it will work only 
if the client checks this extension.

One thing I can confirm is that, as often the next CRL is generated 
earlier that the next update in the CRL, I've seen one actual CA case 
where the policy is such that getting the latest CRL *could* get you a 
fresher info than getting an OCSP token.
So this is a specific case where the CA could make sure the staple OCSP 
request always hits the very latest CRL, whereas there's an interval 
where standard OCSP request are not yet updated to it, and using a still 
trustworthy (earlier than next update) CRL but not actually the very 
latest produced CRL.

So the question is just, is this sufficiently useful to deserve being 
added to the standard ?

Just one more thing, I'm thinking now that one strategy for the server 
can be to guarantee a 20 ms response delay on standard requests, but 
have a 1 or 2 seconds delay for a staple ready answer. It's then up to 
the client to decide if he wants slow but best, or fast but maybe less 
fresh.