Re: [TLS] OCSP must staple

Kurt Roeckx <kurt@roeckx.be> Sat, 07 June 2014 16:49 UTC

Return-Path: <kurt@roeckx.be>
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 A29161A0084 for <tls@ietfa.amsl.com>; Sat, 7 Jun 2014 09:49:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Level:
X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, SPF_HELO_PASS=-0.001] autolearn=no
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 nIsWqIQ6u3Lk for <tls@ietfa.amsl.com>; Sat, 7 Jun 2014 09:49:54 -0700 (PDT)
Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 214A31A0081 for <tls@ietf.org>; Sat, 7 Jun 2014 09:49:54 -0700 (PDT)
Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 66C211C20F3 for <tls@ietf.org>; Sat, 7 Jun 2014 18:49:45 +0200 (CEST)
Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 484311FE0266; Sat, 7 Jun 2014 18:49:45 +0200 (CEST)
Date: Sat, 7 Jun 2014 18:49:45 +0200
From: Kurt Roeckx <kurt@roeckx.be>
To: tls@ietf.org
Message-ID: <20140607164945.GA23329@roeckx.be>
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> <20140605173223.GK27883@mournblade.imrryr.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140605173223.GK27883@mournblade.imrryr.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bJkSBmdGpDsINGmUyt_1V-_ZWik
Subject: Re: [TLS] OCSP must staple
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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/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: Sat, 07 Jun 2014 16:49:55 -0000

On Thu, Jun 05, 2014 at 05:32:23PM +0000, Viktor Dukhovni wrote:
> 
> I would like to see
> CAs stop publishing CRLs entirely (solving the scaling issue for
> mass revocations as with Heartbleed)

CRLs are useful.  And I wish all CAs published them.  But I do not
recommend them to check that the certificate is revoked or not at
the time of a connection.

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

I do not understand what you're really trying to say here.

I think we all agree that we want everybody to do OCSP.  I think
we also want everybody to do OCSP stapling by default when
possible.  But that doesn't mean we want everybody be forced to
do OCSP stapling.

I fail to see how this relates to revocation process.  If there is
a problem in the revocation process having CRL, OCSP, OCSP
stapling, or OCSP must staple will all have the same effect.

I am curious about your use case for servers that can't refresh
the OCSP response.  And is this any different in the case of CRLs?
Or are you just happy to ignore the non-existence of the CRLs?


Kurt