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

Martin Rex <mrex@sap.com> Fri, 26 March 2010 21:39 UTC

Return-Path: <mrex@sap.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 1CC233A6993 for <tls@core3.amsl.com>; Fri, 26 Mar 2010 14:39:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.386
X-Spam-Level:
X-Spam-Status: No, score=-8.386 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_HI=-8]
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 LisKczJTwLfi for <tls@core3.amsl.com>; Fri, 26 Mar 2010 14:39:04 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id E9AB83A6895 for <tls@ietf.org>; Fri, 26 Mar 2010 14:39:03 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o2QLdQ6J005083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Mar 2010 22:39:26 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201003262139.o2QLdP5W023393@fs4113.wdf.sap.corp>
To: yngve@opera.com (Yngve N. Pettersen)
Date: Fri, 26 Mar 2010 22:39:25 +0100 (MET)
In-Reply-To: <op.u95kjftmkvaitl@lessa-ii> from "Yngve N. Pettersen" at Mar 26, 10 03:15:05 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal07
X-SAP: out
Cc: 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
Reply-To: mrex@sap.com
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 21:39:05 -0000

Yngve N. Pettersen 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.
> 
> 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.

possible solutions:
  - define that clients should not accept OCSP responses sent
    within the handshake with the "producedAt" XX hours in the past
  - require servers to refresh their OCSP responses every XX hours
    so that "producedAt" is at most XX hours into the past
  - have the client send an explicit requirement for the "producedAt"
    in the ClientHello extension, so that the server can determine
    whether his cached OCSP responses are sufficiently fresh to
    be acceptable to the client -- it would not make much sense
    to send OCSP responses to the client that the client will
    ignore anayway.

Nothing of this requires you to adjust nextUpdate times of
CRLs or OCSP responses.

-Martin