Re: [TLS] OCSP stapling problem

Viktor Dukhovni <> Wed, 19 December 2018 19:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 828B0130EBB for <>; Wed, 19 Dec 2018 11:15:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Qi6voTQYUF_6 for <>; Wed, 19 Dec 2018 11:15:19 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 08DAB130EBA for <>; Wed, 19 Dec 2018 11:15:18 -0800 (PST)
Received: by (Postfix, from userid 1001) id 0F3311913A; Wed, 19 Dec 2018 14:15:17 -0500 (EST)
Date: Wed, 19 Dec 2018 14:15:16 -0500
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <>
Subject: Re: [TLS] OCSP stapling problem
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Dec 2018 19:15:22 -0000

On Wed, Dec 19, 2018 at 01:40:43PM -0500, Viktor Dukhovni wrote:

> To that end, please post a "tshark" decode of a TLS 1.2 handshake
> (thus avoiding encrypted handshake records that make much of the
> TLS 1.3 handshake opaque, and your tshark may not yet support TLS
> 1.3).  With reference to that handshake explain what you'd like
> to see happen differently on either the client or server end.

That said, there is no mechanism for servers to request OCSP stapling
from clients in TLS 1.2 and below.  The TLS 1.2 CertificateRequest
message is a fixed structure with no room for extensions, such as
needed to request OCSP stapling from clients:

so if you're looking for an implementation of (and API to trigger)
the "status_request" extension for the TLS 1.3 CertificateRequest
message, that'd of course be specific to TLS 1.3, and would likely
be a new feature.

Support for OCSP stapling in OpenSSL is IIRC presently rather
anaemic.  An interface is provided for applications to examine and
validate OCSP messages, but nothing exists to ask the library to
do that internally.  The interfaces are subtle, and some applications
go through the motions, but get the details wrong.  IIRC curl (i.e.
libcurl) is one of the few places where the code looked right after
a cursory review.

So before the existing OCSP stapling support is extended in the
client-to-server direction, I'd rather see more robust support for
handling the OCSP status extension inside the library, so that
client applications can just ask for one of:

    * Mandatory OCSP stapling
    * Conditional OCSP stapling (based on must-staple in the certificate)
    * Ignore OCSP stapling (regardless of must-staple in the certificate)

and have all the details handled in the library.  Once that's done,
one might ask for the reverse direction in TLS 1.3.


P.S. personal soapbox:

FWIW, OCSP is IMHO too fragile for too little benefit, and I've
steered well clear of it in Postfix.  OCSP has and will likely for
some time continue to have insecure fallback modes (the attacker
won't ask for a must-staple certificate, and most CAs will not
refuse to issue certificates without must-staple).  So what you get
is more opportunities to fail, and little meaningful security gain.

What I'd rather see is automation of certificate rotation, and
increasingly (decreasingly?) short certificate lifetimes as
with Let's Encrypt.  I think that in practice that's more beneficial
than OCSP.