Re: [TLS] OCSP must staple

Viktor Dukhovni <viktor1dane@dukhovni.org> Mon, 09 June 2014 05:54 UTC

Return-Path: <viktor1dane@dukhovni.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A471B27E9 for <tls@ietfa.amsl.com>; Sun, 8 Jun 2014 22:54:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2ztIkchSSEE for <tls@ietfa.amsl.com>; Sun, 8 Jun 2014 22:54:15 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0C341B27E5 for <tls@ietf.org>; Sun, 8 Jun 2014 22:54:15 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5F4BD2AB26D; Mon, 9 Jun 2014 05:54:14 +0000 (UTC)
Date: Mon, 9 Jun 2014 05:54:14 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20140609055414.GP27883@mournblade.imrryr.org>
References: <CAFewVt4p4rJ738Yo=XQm6T_jyvG3TnJsSQ5HDZDrqAkyNDa7tg@mail.gmail.com> <20140605173223.GK27883@mournblade.imrryr.org> <20140607164945.GA23329@roeckx.be> <20140607170619.GC27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7A@USMBX1.msg.corp.akamai.com> <20140607184737.GD27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7D@USMBX1.msg.corp.akamai.com> <155f01cf82ce$7cfa8360$76ef8a20$@digicert.com> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434FB5@USMBX1.msg.corp.akamai.com> <539549A8.1040008@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <539549A8.1040008@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/MC5Oxxua3kXtUnGCtRG3CiGGM2g
Subject: Re: [TLS] OCSP must staple
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
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/options/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, 09 Jun 2014 05:54:17 -0000

On Sun, Jun 08, 2014 at 10:44:08PM -0700, Kyle Hamilton wrote:

> On the other hand, I think that relying on a stapled response is perhaps
> shortsighted, as it potentially opens a window of vulnerability.  Say
> the OCSP response is valid for 7 days (the maximum time that EV cert
> OCSP responses can be valid for)

The CA may well generate new CRLs (and associated OCSP responder
state) once every 7 days.  Otherwise the OCSP response TTL should
be shorter, we should address the "right" problem.

That said there is no "right" upper bound for revocation latency.
Whatever "acceptable" limit you set, someone will always present
an argument along the lines of:

> if the cert is revoked on day 2,
> that's still 5 and change days of potential validity.  This is the kind
> of vulnerability that clients can use the OCSP nonce extension to
> protect themselves from, but it only works if it's used and queried from
> the OCSP responder by the client itself.  Thus, the proposal to prevent
> clients from checking OCSP from the source in the presence of an "OCSP
> must staple" extension is harmful to user security and thus wrong-minded.

One must be willing to accept some risk, and buy certificates from a
CA whose OCSP response validity interval poses an acceptable risk.

We can debate whether 7 days for EV certs is too long or not, and
whether it should be adjusted down to 2 days or 2 hours, but the
fundamental problem remains, and is independent of "must staple".

-- 
	Viktor.