Re: [TLS] OCSP must staple

Kurt Roeckx <kurt@roeckx.be> Sat, 07 June 2014 17:36 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 EA9E61A0107 for <tls@ietfa.amsl.com>; Sat, 7 Jun 2014 10:36:29 -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 iQ-LyI4X5Ig4 for <tls@ietfa.amsl.com>; Sat, 7 Jun 2014 10:36:29 -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 0C9451A0104 for <tls@ietf.org>; Sat, 7 Jun 2014 10:36:29 -0700 (PDT)
Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 153221C20F3 for <tls@ietf.org>; Sat, 7 Jun 2014 19:36:21 +0200 (CEST)
Received: by intrepid.roeckx.be (Postfix, from userid 1000) id E572F1FE0266; Sat, 7 Jun 2014 19:36:20 +0200 (CEST)
Date: Sat, 7 Jun 2014 19:36:20 +0200
From: Kurt Roeckx <kurt@roeckx.be>
To: tls@ietf.org
Message-ID: <20140607173620.GA24909@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> <20140607164945.GA23329@roeckx.be> <20140607170619.GC27883@mournblade.imrryr.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140607170619.GC27883@mournblade.imrryr.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2Scg72KbuQCZnnu-HPyAu1xgtu4
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 17:36:30 -0000

On Sat, Jun 07, 2014 at 05:06:19PM +0000, Viktor Dukhovni wrote:
> 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"?

This will only add the posibility to do so.  And CAs may wish to
enforce this on some (high traffic) sites.  But it's not because
you make this posibile that they will do this for all
certificates.

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

So are you saying that if a CA wants to use "must staple" it must
also do something about it's revocation process?

I think that if you think there is something wrong with the
revocation process you should try to address that problem
independant of how we check the revocation status.

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

What is the difficulty in supporting it?

> Not all servers are HTTP
> servers, and servers may lack "HTTP client" capabilities to
> connect to the CA's OCSP responder.

If it can already to TLS, I would think that being an HTTP client
to get an OCSP response can't be that hard.  An HTTP server isn't
special in being able to act as HTTP client.

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

If it's too high for the server, it's most likely to high
for the clients to and you should consider using an internal
CA instead.


Kurt