Re: [TLS] [pkix] Possible revocation delay issue with TLS stapling
"Miller, Timothy J." <tmiller@mitre.org> Fri, 26 March 2010 12:58 UTC
Return-Path: <tmiller@mitre.org>
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 37B363A67A6; Fri, 26 Mar 2010 05:58:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.469
X-Spam-Level:
X-Spam-Status: No, score=-5.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 uTbd1tQJUDiZ; Fri, 26 Mar 2010 05:58:28 -0700 (PDT)
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id BB7083A6782; Fri, 26 Mar 2010 05:58:28 -0700 (PDT)
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o2QCwp7h008044; Fri, 26 Mar 2010 08:58:51 -0400
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o2QCwpuV008011; Fri, 26 Mar 2010 08:58:51 -0400
Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Fri, 26 Mar 2010 08:58:51 -0400
From: "Miller, Timothy J." <tmiller@mitre.org>
To: "'Yngve N. Pettersen'" <yngve@opera.com>, "pkix@ietf.org" <pkix@ietf.org>
Date: Fri, 26 Mar 2010 08:58:51 -0400
Thread-Topic: [pkix] Possible revocation delay issue with TLS stapling
Thread-Index: AcrMijuSFlXENLDYTTqW0a4OtMX64QAWCZPQ
Message-ID: <17FD76C1ECD0AB49817637E21809ABF907FAA70D19@IMCMBX2.MITRE.ORG>
References: <op.u95kjftmkvaitl@lessa-ii>
In-Reply-To: <op.u95kjftmkvaitl@lessa-ii>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "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 12:58:30 -0000
This is already covered in the 2560 Security Note. """ The use of precomputed responses allows replay attacks in which an old (good) response is replayed prior to its expiration date but after the certificate has been revoked. Deployments of OCSP should carefully evaluate the benefit of precomputed responses against the probability of a replay attack and the costs associated with its successful execution. """ It's worth noting that this is a general problem, not specific to stapling, and the OCSP service can simply reduce the validity window if replay of stale-but-valid responses is a concern. Further, clients are also free to reject a stapled OCSP response and fetch their own if they're not happy with the any of the producedAt, thisUpdate, or nextUpdate times. I'd support broadening the security note, but I don't see a need for a new extension. Also I'd point out that in many deployments OCSP is typically fed by CRLs anyway, so the determining time factors are set in CRL production not OCSP response production. IOW, rejecting a stapled response in favor of a new response or CRL is probably equally likely to get you the same result as it is to get you a fresher result. -- Tim >-----Original Message----- >From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >Yngve N. Pettersen >Sent: Thursday, March 25, 2010 9:15 PM >To: pkix@ietf.org >Cc: tls@ietf.org >Subject: [pkix] Possible revocation delay issue with TLS stapling > > > >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 >******************************************************************** >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix
- [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.