Re: [TLS] OCSP must staple

Viktor Dukhovni <viktor1dane@dukhovni.org> Sat, 07 June 2014 17:06 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 178FF1A00FA for <tls@ietfa.amsl.com>; Sat, 7 Jun 2014 10:06:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.4
X-Spam-Level:
X-Spam-Status: No, score=-101.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, USER_IN_WHITELIST=-100] 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 M1vKWck9gmDQ for <tls@ietfa.amsl.com>; Sat, 7 Jun 2014 10:06:27 -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 2656C1A00F8 for <tls@ietf.org>; Sat, 7 Jun 2014 10:06:27 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id B9E412AB221; Sat, 7 Jun 2014 17:06:19 +0000 (UTC)
Date: Sat, 7 Jun 2014 17:06:19 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20140607170619.GC27883@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> <20140605173223.GK27883@mournblade.imrryr.org> <20140607164945.GA23329@roeckx.be>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140607164945.GA23329@roeckx.be>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rprWS0EvgcxKUJLHqhwQjaPZNsE
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: Sat, 07 Jun 2014 17:06:28 -0000

On Sat, Jun 07, 2014 at 06:49:45PM +0200, Kurt Roeckx wrote:

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

If CAs start issuing "must staple" certificates, isn't that "forced"?

> 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 don't see much value in (especially) CRLs or (even) OCSP stapling
without a scalable effective revocation process.

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

CRLs don't scale, client initiated OCSP to CA leaks too much
sensitive data to the CA, and and fails open.  OCSP stapling is
the only revocation mechanism left standing, but some servers
will have difficulty supporting it.  Not all servers are HTTP
servers, and servers may lack "HTTP client" capabilities to
connect to the CA's OCSP responder.  Servers may be on networks
where they have to traverse various firewalls, proxies, ...
to get to the OCSP responder, the burden may be too high.

CRL's are a client-side issue I am prepared to "ignore" (would like
to see disappear).

-- 
	Viktor.