Re: [TLS] OCSP must staple

Kyle Hamilton <> Mon, 09 June 2014 05:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 89F6B1B27E4 for <>; Sun, 8 Jun 2014 22:44:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uity7YBfhpEL for <>; Sun, 8 Jun 2014 22:44:11 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CBD791B27E5 for <>; Sun, 8 Jun 2014 22:44:10 -0700 (PDT)
Received: by with SMTP id v10so4437568pde.23 for <>; Sun, 08 Jun 2014 22:44:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=0NhdskUNmnhf4INhGnTGnDAuGLX26yAYIpo028ckb4Q=; b=YukgBkKawB7UDkzAKDkZS4eWdZ6On4M/z7xS/atvx0tmt92eMHhoxIwxmQ/BRtyZLA 536LDrSUiMQV5pX1wSXJyTBl5RPf6cjOxM3HmSoCVYiP+aLxtwIcstomxxOHDOFOCfkp aY8rhMesfZKjCALxAASHMP9Vnhk7tVOPuyr8DXEOmdcaLRmGidRLDqiVwgZUoGKegFaw oTsdmoMHPIW/DgFJqDIYOBxaW2laiieyBn1iiVgHIo5zt9jx3mpPzth6c6UP2+ZgoFDv LpAM41Z1espvDILO1xuoHI/hDGQT8Zctv4wF9QLgxhLUiNTHZSsUr4ECc5bdAVjvZfZ5 YAZQ==
X-Received: by with SMTP id td8mr2283101pac.103.1402292650452; Sun, 08 Jun 2014 22:44:10 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id ir10sm61771721pbc.59.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 08 Jun 2014 22:44:09 -0700 (PDT)
Message-ID: <>
Date: Sun, 08 Jun 2014 22:44:08 -0700
From: Kyle Hamilton <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: "Salz, Rich" <>,
References: <097101cf7aa7$17f960a0$47ec21e0$> <> <> <> <> <> <> <> <> <> <> <> <155f01cf82ce$7cfa8360$76ef8a20$> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070709080107030001060507"
Subject: Re: [TLS] OCSP must staple
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 09 Jun 2014 05:44:12 -0000

On 6/8/2014 6:51 PM, Salz, Rich wrote:
>> We already have people interested in using must staple upon adoption so this shouldn't be a factor in the adopting the draft.
> That's interesting you have customers interested in I, and that point is as valid as mine saying I don't think our customers will be.  But I didn't say it to forestall adoption of the draft, sorry if I gave you that impression.
>> Non-compliance by certain CAs is really irrelevant to whether OCSP Must Staple should be adopted as a standard.
> I didn't say that, either :)  I was just describing what I saw as a bigger issue. And yes, it's completely orthogonal to OCSP; sorry if I wasn't clear.
> 	/r$

I've had people tell me that they honestly believe that they're paying
the CA for the OCSP and revocation bandwidth.  This kind of viewpoint
undermines any kind of mandate for any kind of "must staple". 
Personally, I think this view is moderately short-sighted, as it relies
on a third party to be available at all times (particularly with
Firefox's "security.OCSP.require" configuration option).  When I write
protocols I include stapling as par for the course.

On the other hand, I think that relying on a stapled response is perhaps
shortsighted, as it potentially opens a window of vulnerability.  Say
the OCSP response is valid for 7 days (the maximum time that EV cert
OCSP responses can be valid for): if the cert is revoked on day 2,
that's still 5 and change days of potential validity.  This is the kind
of vulnerability that clients can use the OCSP nonce extension to
protect themselves from, but it only works if it's used and queried from
the OCSP responder by the client itself.  Thus, the proposal to prevent
clients from checking OCSP from the source in the presence of an "OCSP
must staple" extension is harmful to user security and thus wrong-minded.

-Kyle H