Re: [TLS] OCSP must staple

Brian Smith <brian@briansmith.org> Wed, 11 June 2014 22:49 UTC

Return-Path: <brian@briansmith.org>
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 DF0791B28CB for <tls@ietfa.amsl.com>; Wed, 11 Jun 2014 15:49:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 v-BfP0s4GGb1 for <tls@ietfa.amsl.com>; Wed, 11 Jun 2014 15:49:55 -0700 (PDT)
Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB63E1A02EE for <tls@ietf.org>; Wed, 11 Jun 2014 15:49:54 -0700 (PDT)
Received: by mail-qc0-f177.google.com with SMTP id i17so723501qcy.8 for <tls@ietf.org>; Wed, 11 Jun 2014 15:49:54 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=JDVD96T7XY/Hq5C2wjHgxcvub6GuqdLAhZu7G9bDuNU=; b=LysCXpGVlYlkuHPl8Z3NRhR6E9z5er5sYkBu+QBa4Y6IxqMq8e/vsQQzOVHjpAkvaT eFXv2H9SZHBBeDM0MoxdN/YR/R8XdyokuEp2YcUyp94EZDpSOg92e8/0oxE7rF92DzXT tjjaS7lIDk5JJ0FOJOla65vK1hwUp4dvZyG5wwJjbhqGHTuO4tbZqBT8jDnOmRK4nRkP SPKOfZRBcngUnsQUXBhy1n9k+JZph+cjf+jm4175cy6YZjOjAkBudGIAeZmVaAvJBqp6 WCKdu5JmZQP8qr7y2EXIh4dmm3VAZDOlKdeFOW6D6eQmDREZEcCdTrnIVl5nYqG7ttl1 PySA==
X-Gm-Message-State: ALoCoQlkm75xVTRy/K8a/ppPtFC5iJ1ExX9y7AnOtt6OPhZq+rXjY5JbjvEmQk3JXbi9SRu04CRB
MIME-Version: 1.0
X-Received: by 10.140.89.202 with SMTP id v68mr17959599qgd.71.1402526993931; Wed, 11 Jun 2014 15:49:53 -0700 (PDT)
Received: by 10.224.212.3 with HTTP; Wed, 11 Jun 2014 15:49:53 -0700 (PDT)
In-Reply-To: <5390CA45.1050504@nthpermutation.com>
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> <5390B1D6.5010105@nthpermutation.com> <CAFewVt6Pr8yjV8EbYLp1HQJfYMgq2LJMt4uQqZWKChR6p12Wtg@mail.gmail.com> <5390CA45.1050504@nthpermutation.com>
Date: Wed, 11 Jun 2014 15:49:53 -0700
Message-ID: <CAFewVt6qfqHW2Df=aXhmo-Fucvn_PUzM8NVQV-aYiH9Ttfhjmw@mail.gmail.com>
From: Brian Smith <brian@briansmith.org>
To: Michael StJohns <msj@nthpermutation.com>
Content-Type: multipart/alternative; boundary=001a11c1182e432a3804fb9743dc
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/V55-l1-7vv8VT8h90ZS6KU3RuaU
Cc: "<tls@ietf.org>" <tls@ietf.org>
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: Wed, 11 Jun 2014 22:49:58 -0000

On Thu, Jun 5, 2014 at 12:51 PM, Michael StJohns <msj@nthpermutation.com>
wrote:

> On 6/5/2014 3:12 PM, Brian Smith wrote:
>
>> Is it really significantly easier for CAs to add new certificate policies
>> compared to adding new certificate extensions? I could see how that could
>> be the case, but I think it would be good to hear from CAs about this.
>>
>
> Mostly the "put a policy object in the ca certificate" reduces to
> "configure the text string of the OIDs you want to include".
> https://www.openssl.org/docs/apps/x509v3_config.html#Certificate_Policies_
> for example.
>
> The certificate policy extension is pretty well formed, which means that
> its pretty easy to specify in configuration language (e.g. xml,
> label=value) what you want to be included rather than having to go back and
> add new ASN1 encode/decode/translate to and from string logic.  Things like
> Dogtag and EJBCA support it via a gui


I have researched some of the pros and cons of Michael's policy-based
approach. I also implemented it in a private copy of mozilla::pkix and
Firefox. In particular, I made it so:

* When the extension is present in the end-entity certificate, that a valid
"Good" OCSP response must be provided in the TLS handshake,
* There will never be any fallback to OCSP fetching or CRLs or cache
lookups when the end-entity certificate has the must-staple policy.
However, additional certificate trust information (blacklists/CRLSet) are
still consulted.
* The modified mozilla::pkix will never build a path from an end-entity
certificate or sub-CA to a higher-level CA certificate where the
higher-level CA certificate has the Must-Staple policy but the end-entity
or lower-level sub-CA certificate doesn't have the Must-staple policy.
* My modified mozilla::pkix enforces a maximum OCSP response lifetime of 2
days + slop (1 day) = 3 days if Must-Staple is present, instead of 10 days.

The good news:
* In mozilla::pkix and Firefox, it is just as easy to implement Machael's
policy-based approach as it would be to implement the approach outlined in
the draft.
* As Michael said, most if not all CA software already supports custom
certificate policies, so there is *no* new code required on the CA side for
Machael's approach. This is a significant advantage, especially because
there are a lot of companies that have purchased sub-CA certificates that
chain to publicly-trusted CAs, which use closed-source software (e.g.
Microsoft's). Basically, with Michael's approach, everybody would be able
to use Must-Staple straight away, if they want to, without writing code.

The bad news:
* TLS intercepting proxies cause trouble. In particular, some (if not all)
versions of Microsoft Threat Management Gateway forge their fake
certificates by copying the certificate policies from the original
certificate that they are trying to impersonate. Yet, Microsoft TMG does
not support OCSP stapling or in fact any kind of OCSP. Consequently, it
will copy the Must-Staple policy into the forged certificate but it won't
staple a response. I imagine other TLS intercepting proxies will do the
same.
* It is unclear what TLS intercepting proxies do with certificate
extensions that they don't understand. I would guess that some copy those
extensions into their forged certificates and others do not.

The OK news:
* From what I've found, Microsoft TMG forges certificates that are very
short lived (24hrs). Thus, if we make an exception that short-lived
certificates (<= 48 hours) with the Must-Staple feature do not need to have
a stapled OCSP response even with Must-Staple, we can probably avoid a lot
of the issues with TLS intercepting proxies, regardless of how the
Must-Staple feature is encoded in the certificate.

Thus, for ease-of-deployment reasons, I prefer Michael's policy-based
approach + the short-lived certificate exception over the approach in the
draft that uses a new extension. Regardless of which of those two
approaches is taken, we'll need to do a lot of interop testing with various
kinds of TLS intercepting proxies.

Cheers,
Brian