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

"Miller, Timothy J." <tmiller@mitre.org> Fri, 26 March 2010 13:02 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 C50423A67A6; Fri, 26 Mar 2010 06:02:07 -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 oV3RINs7fdBL; Fri, 26 Mar 2010 06:02:06 -0700 (PDT)
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 844533A6782; Fri, 26 Mar 2010 06:02:06 -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 o2QD2TMY012362; Fri, 26 Mar 2010 09:02:29 -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 o2QD2Tes012354; Fri, 26 Mar 2010 09:02:29 -0400
Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Fri, 26 Mar 2010 09:02:29 -0400
From: "Miller, Timothy J." <tmiller@mitre.org>
To: "'Jean-Marc Desperrier'" <jmdesp@free.fr>, "pkix@ietf.org" <pkix@ietf.org>, "tls@ietf.org" <tls@ietf.org>
Date: Fri, 26 Mar 2010 09:02:28 -0400
Thread-Topic: [pkix] Possible revocation delay issue with TLS stapling
Thread-Index: AcrMyGyPIaq3Dy28QGCMd5Uv0+IDhQAHAwgQ
Message-ID: <17FD76C1ECD0AB49817637E21809ABF907FAA70D1B@IMCMBX2.MITRE.ORG>
References: <op.u95kjftmkvaitl@lessa-ii> <4BAC5C33.8020509@seantek.com> <4BAC80FD.4060603@free.fr>
In-Reply-To: <4BAC80FD.4060603@free.fr>
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: "dev+ietf@seantek.com" <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 13:02:07 -0000

Clients concerned with OCSP response freshness can always insist on nonces, and fall back on CRLs if the OCSP service won't support them.

-- Tim


>-----Original Message-----
>From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of
>Jean-Marc Desperrier
>Sent: Friday, March 26, 2010 4:40 AM
>To: pkix@ietf.org; tls@ietf.org
>Cc: dev+ietf@seantek.com
>Subject: Re: [pkix] Possible revocation delay issue with TLS stapling
>
>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.
>_______________________________________________
>pkix mailing list
>pkix@ietf.org
>https://www.ietf.org/mailman/listinfo/pkix