[TLS] Possible revocation delay issue with TLS stapling
"Yngve N. Pettersen" <yngve@opera.com> Fri, 26 March 2010 02:14 UTC
Return-Path: <yngve@opera.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 F05E13A694F; Thu, 25 Mar 2010 19:14:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.269
X-Spam-Level:
X-Spam-Status: No, score=-2.269 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-4]
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 i6lmycXEi+Ge; Thu, 25 Mar 2010 19:14:49 -0700 (PDT)
Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id 6D6723A6949; Thu, 25 Mar 2010 19:14:47 -0700 (PDT)
Received: from lessa-ii (dhcp-wireless-open-abg-25-33.meeting.ietf.org [130.129.25.33]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o2Q2F2qD006083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 Mar 2010 02:15:05 GMT
Content-Type: text/plain; charset="iso-8859-15"; format="flowed"; delsp="yes"
To: "pkix@ietf.org" <pkix@ietf.org>
Date: Fri, 26 Mar 2010 03:15:05 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
From: "Yngve N. Pettersen" <yngve@opera.com>
Organization: Opera Software ASA
Message-ID: <op.u95kjftmkvaitl@lessa-ii>
User-Agent: Opera Mail/10.50 (Win32)
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: [TLS] 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 02:14:57 -0000
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: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ********************************************************************
- [TLS] Possible revocation delay issue with TLS st… Yngve N. Pettersen
- Re: [TLS] Possible revocation delay issue with TL… Adam Langley
- Re: [TLS] [pkix] Possible revocation delay issue … Sean Leonard
- Re: [TLS] [pkix] Possible revocation delay issue … Miller, Timothy J.
- Re: [TLS] [pkix] Possible revocation delay issue … Miller, Timothy J.
- Re: [TLS] [pkix] Possible revocation delay issue … Kemp, David P.
- Re: [TLS] [pkix] Possible revocation delay issue … Jean-Marc Desperrier
- Re: [TLS] [pkix] Possible revocation delay issue … Santosh Chokhani
- Re: [TLS] Possible revocation delay issue with TL… Nicolas Williams
- Re: [TLS] [pkix] Possible revocation delay issue … Yngve N. Pettersen
- Re: [TLS] Possible revocation delay issue with TL… Martin Rex
- Re: [TLS] [pkix] Possible revocation delay issue … Miller, Timothy J.
- Re: [TLS] [pkix] Possible revocation delay issue … Miller, Timothy J.
- Re: [TLS] [pkix] Possible revocation delay issue … Santosh Chokhani
- Re: [TLS] [pkix] Possible revocation delay issue … Kemp, David P.
- Re: [TLS] [pkix] Possible revocation delay issue … Miller, Timothy J.
- Re: [TLS] [pkix] Possible revocation delay issue … Miller, Timothy J.