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

Sean Leonard <dev+ietf@seantek.com> Fri, 26 March 2010 07:03 UTC

Return-Path: <dev+ietf@seantek.com>
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 E796B3A67A1; Fri, 26 Mar 2010 00:03:31 -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 X3B9lCrE07CW; Fri, 26 Mar 2010 00:03:31 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id 072DB3A68E0; Fri, 26 Mar 2010 00:03:30 -0700 (PDT)
Received: from [192.168.123.150] (unknown [67.174.48.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 08F6922E254; Fri, 26 Mar 2010 03:03:46 -0400 (EDT)
Message-ID: <4BAC5C33.8020509@seantek.com>
Date: Fri, 26 Mar 2010 00:03:15 -0700
From: Sean Leonard <dev+ietf@seantek.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3
MIME-Version: 1.0
To: "Yngve N. Pettersen" <yngve@opera.com>
References: <op.u95kjftmkvaitl@lessa-ii>
In-Reply-To: <op.u95kjftmkvaitl@lessa-ii>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Fri, 26 Mar 2010 01:37:55 -0700
Cc: "pkix@ietf.org" <pkix@ietf.org>, "tls@ietf.org" <tls@ietf.org>
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 07:03:32 -0000

On 3/25/2010 7:15 PM, Yngve N. Pettersen wrote:
>
>
> Hi,

Hi Yngve,

Thanks for the e-mail. I think that your idea has merit. However, I have 
three general questions/concerns that perhaps you could think about and 
respond to:

1. Technically, neither OCSP responses nor CRLs expire. Both have 
thisUpdate and nextUpdate fields--see RFC 2560 and RFC 5280. While one 
can causally refer to OCSP responses or CRLs expiring, think about the 
implications. If a certificate is identified as "revoked" in an OCSP 
response or appears in a CRL without a reason code or with any reason 
code other than "certificateHold", that is it for the certificate--the 
certificate is dead forever. nextUpdate is basically just a 
recommendation about when new information should be available.

As a thought exercise, consider having a CRL (or OCSP response) at time 
t > nextUpdate date. You look for a certificate c, and c's serial number 
appears on the list/in the response as "revoked" due to 
"privilegeWithdrawn". You try to fetch a new CRL or OCSP response. No 
dice--network down. What should you do? Validation of c should fail, 
because it has been revoked (specifically, it has been revoked at least 
as of the thisUpdate date, and possibly earlier). The fact that the CRL 
or OCSP response is "old" does not mean that it should be ignored.

(Note that if the OCSP response is "old" and the OCSP response says 
"good", you may want to ignore that response, effectively treating it 
like expiration. But see point 3 below.)

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?

2.(b) Technically your proposal addresses the security issue (where a 
malicious server would just find a "long", good response by lying about 
whether it's a server) by modifying the client's behavior to check for 
the proposed extension, and if it's not present, then fetch a response 
directly from the responder. But if the OCSP responder (run by the CA or 
on behalf of the CA) is so concerned about load, it can just increase 
the delay time back to the interval that it used to use, and put the 
extension in. The net effect is that we wouldn't see much change.

3. As a practical matter, most OCSP responders rely on a master CRL 
list, which is published with the same frequency as OCSP responder 
thisUpdate and nextUpdate fields. If you are so concerned about the 
delay problem, it may make more sense for the CA to update all 
revocation information sources more often.

Thanks,

Sean