Re: [TLS] OCSP must staple

"Jeremy Rowley" <jeremy.rowley@digicert.com> Sun, 08 June 2014 04:02 UTC

Return-Path: <jeremy.rowley@digicert.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 CA8921A02B4 for <tls@ietfa.amsl.com>; Sat, 7 Jun 2014 21:02:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.953
X-Spam-Level:
X-Spam-Status: No, score=-4.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 wDPRg4NsZPka for <tls@ietfa.amsl.com>; Sat, 7 Jun 2014 21:02:44 -0700 (PDT)
Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA5F1A02B2 for <tls@ietf.org>; Sat, 7 Jun 2014 21:02:44 -0700 (PDT)
Received: from JROWLEYL2 (c-67-166-110-179.hsd1.ut.comcast.net [67.166.110.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id CF0037FA482; Sat, 7 Jun 2014 22:02:36 -0600 (MDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1402200157; bh=fzmJ845I+OV9JtqWpszm4TGzza/jEWlVV11L2r5eAZI=; h=From:To:References:In-Reply-To:Subject:Date; b=yKubcaQZoMxqUfJqikvMSxGeYcwPUpBYdwQRI18rLyVT9hOJnJYbBjTE6VVFe/pze KrTqEvcZbG6SmUJmuYylAdue6TTOHTYhNgLInDUVPHyJnhwn41pagzRaelYop8RY7d QU/R21y7j4Q+woeC0dvM8DfvOlGGbw1GyeoHsMBU=
From: "Jeremy Rowley" <jeremy.rowley@digicert.com>
To: "'Salz, Rich'" <rsalz@akamai.com>, <tls@ietf.org>
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> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7D@USMBX1.msg.corp.akamai.com>
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7D@USMBX1.msg.corp.akamai.com>
Date: Sat, 7 Jun 2014 22:02:38 -0600
Message-ID: <155f01cf82ce$7cfa8360$76ef8a20$@digicert.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJxv6HtmB9uk8Yt5wEeFHdRD1knoQEt2WjqAP+sMUYCHog9/QJH2PNTApX9AA0COSwKkwNalKqnAp4CcngB5F3w/QJ8kG4OAaygmc2ZZtBTsA==
Content-Language: en-us
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/76EcPO8ZuNU-0wU7dleTpFHKXm8
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: Sun, 08 Jun 2014 04:02:46 -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. 

Any standard "trusts" that the implementers will do the right thing.  Not
sure that's an argument against adoption.  CA OCSP responder availability
isn't a concern with stapling, especially considering uptimes typically
exceed 99.99% (http://ocspreport.x509labs.com/). We already have people
interested in using must staple upon adoption so this shouldn't be a factor
in the adopting the draft. 

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

Non-compliance by certain CAs is really irrelevant to whether OCSP Must
Staple should be adopted as a standard. Must staple is about letting server
operators dictate whether stapling is required, not on improving CA
certificate profiles. That should be addressed in a separate RFC by those
concerned with current practices. 

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

Again, irrelevant to whether MUST Staple is adopted. CT does not preclude
MUST Staple and vice versa.  All security is a layered approach.  This is
just one more tool available to server operators to increase their level of
security. Best of all, MUST staple doesn't necessarily require a change in
current server software. Only a change in the browser to recognize the
extension.

Jeremy