Re: [TLS] OCSP must staple

"Salz, Rich" <rsalz@akamai.com> Sat, 07 June 2014 20:12 UTC

Return-Path: <rsalz@akamai.com>
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 C864E1A0083 for <tls@ietfa.amsl.com>; Sat, 7 Jun 2014 13:12:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham
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 GNuL3LDuRCuC for <tls@ietfa.amsl.com>; Sat, 7 Jun 2014 13:12:45 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 79C4A1A0073 for <tls@ietf.org>; Sat, 7 Jun 2014 13:12:45 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 11D2A47504 for <tls@ietf.org>; Sat, 7 Jun 2014 20:12:38 +0000 (GMT)
Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 060A5474B8 for <tls@ietf.org>; Sat, 7 Jun 2014 20:12:38 +0000 (GMT)
Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id ED35D2026 for <tls@ietf.org>; Sat, 7 Jun 2014 20:12:37 +0000 (GMT)
Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Sat, 7 Jun 2014 16:12:37 -0400
From: "Salz, Rich" <rsalz@akamai.com>
To: "tls@ietf.org" <tls@ietf.org>
Date: Sat, 7 Jun 2014 16:12:35 -0400
Thread-Topic: [TLS] OCSP must staple
Thread-Index: Ac+CgPo0EQsrCFWsSdGIITUhRv6y7wACmHhw
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7D@USMBX1.msg.corp.akamai.com>
References: <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> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7A@USMBX1.msg.corp.akamai.com> <20140607184737.GD27883@mournblade.imrryr.org>
In-Reply-To: <20140607184737.GD27883@mournblade.imrryr.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/otfC27reUvnLDrD-dRJcAo_-15k
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 20:12:47 -0000

> Well, if the server *is* OCSP stapling capable, there is little harm in having a "must staple" certificate.

Except that they are depending on the CA's OCSP responder, and trusting (worrying is a more accurate term) that the browsers will do the right thing, whatever that is.  I'll be pretty surprised if the "select few," as you put it, will want must-staple certificates. 

> but larger problem lies upstream, working revocation for the masses.

Which masses?  For what? We're going through an exercise of checking the SSL certs on the true origins of many of our customers.  You'd be sadly surprised how many of them are expired, have wrong SAN fields, unknown CA's, and so on.  And even sadder if you knew how many said "we'll deal with it later, if at all."  And yet, the web commerce still marches on.

I  think the general public is put more at risk by erroneously-issued certificates, whether by accident or malicious or "national security."  Luckily, it appears that Certificate Transparency seems likely to narrow that window of exposure down to a fairly short time.

	/r$

--  
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: rsalz@jabber.me; Twitter: RichSalz