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

"Miller, Timothy J." <tmiller@mitre.org> Mon, 29 March 2010 13:13 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 AEFEE3A6A1A; Mon, 29 Mar 2010 06:13:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.149
X-Spam-Level:
X-Spam-Status: No, score=-5.149 tagged_above=-999 required=5 tests=[AWL=0.320, 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 7tnavvHKlVPz; Mon, 29 Mar 2010 06:13:40 -0700 (PDT)
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 0649A3A67FF; Mon, 29 Mar 2010 06:13:39 -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 o2TDE7ZM017570; Mon, 29 Mar 2010 09:14:07 -0400
Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o2TDE7Si017567; Mon, 29 Mar 2010 09:14:07 -0400
Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Mon, 29 Mar 2010 09:14:07 -0400
From: "Miller, Timothy J." <tmiller@mitre.org>
To: "'Yngve N. Pettersen'" <yngve@opera.com>, "pkix@ietf.org" <pkix@ietf.org>
Date: Mon, 29 Mar 2010 09:14:06 -0400
Thread-Topic: [pkix] Possible revocation delay issue with TLS stapling
Thread-Index: AcrNK4YIBZ+TXVLfSSiIWZLv/SVipgCFPNTQ
Message-ID: <17FD76C1ECD0AB49817637E21809ABF907FAA70D24@IMCMBX2.MITRE.ORG>
References: <op.u95kjftmkvaitl@lessa-ii> <17FD76C1ECD0AB49817637E21809ABF907FAA70D19@IMCMBX2.MITRE.ORG> <op.u9610i13kvaitl@lessa-ii>
In-Reply-To: <op.u9610i13kvaitl@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: Mon, 29 Mar 2010 13:13:41 -0000

>> """
>>    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.
>> """

>Similar language is not included in the TLS Extension document
>(RFC4366-bis)

Sounds to me like it should be added.

>Yes, it is general and inherent in the system. However, in the case of
>"stapling" you have a situation where an authorized intermediate may
>turn malicious; we are not dealing with a normal MITM situation. The question
>is how to limit the damage potential?

A client concerned with this shouldn't rely on the stapled response.  However, I'd quibble that stapling presents a unique situation.  In any protocol (PKI-related or not), one should assume that *either* party can turn malicious at any time.

>Having the issuer define the lifetime of stapled OCSP responses based on
>their update policies is IMO better than having the clients setting an
>essentially arbitrary freshness limit. To facilitate a reduced lifetime
>for stapled responses the issuer must either globally reduce the
>lifetime (which probably first require critical stapling support mass), or some
>way for the responder to distinguish the request for a stapling response or
>a normal client request.

Clients already have unique freshness requirements.  I know of validation engines that won't accept CRLs beyond nextUpdate, and I know of equally many that will, and another number that let the user decide (and that's leaving out the implementations that simply don't treat revocation status as critical at all).  I know of validation engines that attempt to freshen CRLs at every validation, and those that only try to freshen once at the expiry of nextUpdate, and everywhere in between.  In addition, both clients and network proxies cache responses (OCSP and CRL), making the situation even more complex.

Which throws us back on "If you *really* care, insist on nonces."

-- Tim