Re: [TLS] OCSP must staple

Viktor Dukhovni <viktor1dane@dukhovni.org> Thu, 05 June 2014 17:32 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 19FBE1A0123 for <tls@ietfa.amsl.com>; Thu, 5 Jun 2014 10:32:32 -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 ZDYoILr8SDs6 for <tls@ietfa.amsl.com>; Thu, 5 Jun 2014 10:32:30 -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 6E1D91A00EA for <tls@ietf.org>; Thu, 5 Jun 2014 10:32:30 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 9F49B2AAB4F; Thu, 5 Jun 2014 17:32:23 +0000 (UTC)
Date: Thu, 5 Jun 2014 17:32:23 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20140605173223.GK27883@mournblade.imrryr.org>
References: <20140528184735.GA20602@roeckx.be> <097101cf7aa7$17f960a0$47ec21e0$@digicert.com> <4AA8E7B7-A19D-4E65-AF18-C4D02A513652@ieca.com> <538EF79B.3000506@cs.tcd.ie> <CAMm+LwgTnva9jJgVfkaOZ1qP0Rk3w-mFfepnubosgtrCEARv=g@mail.gmail.com> <539069CC.5010304@cs.tcd.ie> <CAFewVt4p4rJ738Yo=XQm6T_jyvG3TnJsSQ5HDZDrqAkyNDa7tg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAFewVt4p4rJ738Yo=XQm6T_jyvG3TnJsSQ5HDZDrqAkyNDa7tg@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/oxAjcY7ujbCKtAHdLR5a0CPW95w
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: Thu, 05 Jun 2014 17:32:32 -0000

On Thu, Jun 05, 2014 at 10:05:22AM -0700, Brian Smith wrote:

> I read the document. I disagree with the documented semantics of the
> extension when it appears in a CA certificate.

[ Apologies if my understanding of how the revocation process works
in practice is a bit stale, perhaps things are better now than the
last time I looked. ]

This extension introduces a requirement to implement OCSP stapling
predicated on the assumption, that we have usable revocation
mechanisms, and that all that remains is for clients to learn in
a reasonably timely manner that a certificate has been revoked.

It also assumes that servers are generally deployed in environments
where periodically obtaining OCSP responses from the server's CA
for stapling is practical.

There at this time to my knowledge no standard companion protocol
for OCSP that allows the holder of a key pair (when the private
key is not lost) to sign a request to the CA to revoke the
certificate.  Instead, it is my impression, that we have "challenge
phrases" that are often not set or lost, and CA-specific interfaces
to activate revocation.

If, this is indeed the case, then I claim that mandatory OCSP
stapling is putting the cart before the horse.  Only a tiny fraction
of certificates can be effectively revoked.  I would like to see
CAs stop publishing CRLs entirely (solving the scaling issue for
mass revocations as with Heartbleed), implement only OCSP, and
provide a standard zero-cost revocation protocol when the private
key is available (or when a miracle happens and the "challenge"
password is actually known).

Once revocation is a scalable working process, then we can benefit
from insisting on OCSP stapling, provided we figure out what to do
with servers that don't have any way to reach out and refresh OCSP
responses for stapling, nor support interface for an agent to
obtain the response on the server's behalf and push it into the
server's configuration.

-- 
	Viktor.