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

Adam Langley <agl@imperialviolet.org> Fri, 26 March 2010 02:37 UTC

Return-Path: <alangley@gmail.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 B44B03A69C3; Thu, 25 Mar 2010 19:37:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.197
X-Spam-Level:
X-Spam-Status: No, score=0.197 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_92=0.6]
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 RYUwVHK+D-I3; Thu, 25 Mar 2010 19:37:40 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 9DA223A6803; Thu, 25 Mar 2010 19:37:40 -0700 (PDT)
Received: by vws12 with SMTP id 12so1756356vws.31 for <multiple recipients>; Thu, 25 Mar 2010 19:38:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:received:message-id:subject :from:to:cc:content-type; bh=2GrHCSoqne7fR5UOSpzrFKulxy7TATfVNM4WJHGmbTI=; b=ZvJke6CBmHjJv+UrnOxR7qhNUtWae2nwCNwZDzx4JRTJwWXuNQeKMdZNuCd0iW6puZ 0GtuaM9h7rZ9o8sCk8MJUeQ8PsNxEigLY4WhGCacwsW8GA8NDqzszk5BW1HErh0xTQ8+ Tn7xXJ43K7n9kl9l5QxnUDQodx3yil8veSbxE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=lMsyqjPADxNflM+Yq6tkL1YHXEG+v1D5IC+WeDIwMbj8m3tBHUHFdDRb+WxhdWf5Fo Kwjrw+eyfrkTCKCAqO6y9VPcagP2p8DBJRqb3/vFFFvPyS3tD7CbMVviGRWz987eyoJ3 PKNc+36VcF6Xl5K1Qx57vzHLWV79lPXNvcF+M=
MIME-Version: 1.0
Sender: alangley@gmail.com
Received: by 10.220.65.214 with HTTP; Thu, 25 Mar 2010 19:38:00 -0700 (PDT)
In-Reply-To: <op.u95kjftmkvaitl@lessa-ii>
References: <op.u95kjftmkvaitl@lessa-ii>
Date: Thu, 25 Mar 2010 22:38:00 -0400
X-Google-Sender-Auth: 51e7915fc4d40cd6
Received: by 10.220.122.220 with SMTP id m28mr171925vcr.122.1269571080213; Thu, 25 Mar 2010 19:38:00 -0700 (PDT)
Message-ID: <396556a21003251938l3dd17cdbx4e77aa40185c442f@mail.gmail.com>
From: Adam Langley <agl@imperialviolet.org>
To: "Yngve N. Pettersen" <yngve@opera.com>
Content-Type: text/plain; charset=UTF-8
Cc: "pkix@ietf.org" <pkix@ietf.org>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [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:37:41 -0000

On Thu, Mar 25, 2010 at 10:15 PM, Yngve N. Pettersen <yngve@opera.com> wrote:
> 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.

This is nothing new, but nor does your proposal really address it.

Consider an attacker, who holds a compromised key for x and who can
hijack your TCP connect to that host. They can choose not to support
status_request, wait for the HTTP connection to the OCSP responder and
substitute the longer term OCSP response which they cached previously.
Your design would only protect against the case where the attacker can
only hijack some TCP connections. Typically that would be done with
DNS poisoning, but that gives them everything. So it would have to be
the case that the client is resolving correctly, but the attacker is
sufficiently close to the real servers to be able to intercept their
traffic. It seems like a small case.

The current OCSP validity (typically 7 days) probably results from the
OCSP responder not wanting too much load. If OCSP stapling starts to
happen then the real solution is for the certificate holder to agree
with the issuer that they'll support stapling (thus reducing the load)
and the issuer won't ever issue responses valid for more than some
number of hours.

(Which reminds me: we should include CertificateStatus in cached info.)


AGL

-- 
Adam Langley agl@imperialviolet.org http://www.imperialviolet.org