Re: [TLS] OCSP Must Staple

Brian Smith <brian@briansmith.org> Mon, 28 October 2013 19:35 UTC

Return-Path: <brian@briansmith.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8337921E8095 for <tls@ietfa.amsl.com>; Mon, 28 Oct 2013 12:35:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YbafYk4yyKt for <tls@ietfa.amsl.com>; Mon, 28 Oct 2013 12:35:37 -0700 (PDT)
Received: from mail-qe0-f42.google.com (mail-qe0-f42.google.com [209.85.128.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC7711E82BD for <tls@ietf.org>; Mon, 28 Oct 2013 12:35:30 -0700 (PDT)
Received: by mail-qe0-f42.google.com with SMTP id gc15so4327766qeb.29 for <tls@ietf.org>; Mon, 28 Oct 2013 12:35:30 -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=mKtltJBQUCUeItGnFJfjf44m6TjZOMKWkndYcMHWYic=; b=mG0TrCJyBFGvC27OnmIgQBKU/KnhgKTRs0xzINn1aafEPOm4OZU3aqxKJX099haK8A jUBdNebQ2boFjQ5pdIiElia3Do6v1FtyYNlAcnPR4audONzu6a7y7pEEf3L1Kly9dbKB MkYxsZ9zI23cLWHcYEprWm1KoUxZj5x6WGk0Dl4inHgx5efc+5jQN/1hrTXu/FCHvVW9 a4LPPfJnQATB99xQizp4qs72OXFu/vR8hihvJQPRQviGIDYhwwEjq2KA/i34Bao+wLKw 3w89+lT4CeFMPOBDgEqth8KUKltoN3WHezYP7YaC2BZWDh7jzaJ1/Z5KuVC+yovAsrQM yL5A==
X-Gm-Message-State: ALoCoQkJkKFvglfTDDGX/6YpW9WJOUz/Zj5xebidRgTJwWEcHWKjT4Zmj2RtABlTghgP5/EaWvkW
MIME-Version: 1.0
X-Received: by 10.49.39.161 with SMTP id q1mr31434357qek.66.1382988930322; Mon, 28 Oct 2013 12:35:30 -0700 (PDT)
Received: by 10.224.38.5 with HTTP; Mon, 28 Oct 2013 12:35:30 -0700 (PDT)
X-Originating-IP: [63.245.219.54]
In-Reply-To: <CA+cU71nnf6-bPbQ-=OBHf2txttO0Ev3hfNwMc57aByZj=m0LnQ@mail.gmail.com>
References: <CAMm+LwhG9FVEhRBUO5EqKUzGGLb3h3ZzxzgJobrAborn6Me83w@mail.gmail.com> <CA+cU71nnf6-bPbQ-=OBHf2txttO0Ev3hfNwMc57aByZj=m0LnQ@mail.gmail.com>
Date: Mon, 28 Oct 2013 12:35:30 -0700
Message-ID: <CAFewVt5Ug-t6nSiaq_56wM9TzA3TqG1mP7WSHN7n9O_phO04cA@mail.gmail.com>
From: Brian Smith <brian@briansmith.org>
To: Tom Ritter <tom@ritter.vg>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] OCSP Must Staple
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: Mon, 28 Oct 2013 19:35:53 -0000

On Wed, Oct 23, 2013 at 8:58 AM, Tom Ritter <tom@ritter.vg>; wrote:
> I support this.  I would also like to seek to have it added to the
> HTTP Strict Transport Security header as an option (same as
> includeSubdomains), so that it can pin to the domain as well as the
> certificate - although that may need to wait until this is
> standardized and identifiers solidified.

FWIW, I am working on a draft that is almost exactly that, but with a
separate header named "Must-Staple." It has basically has the same
syntax and similar semantics as Strict-Transport-Security (including
includeSubDomains), with the additional qualification that it must be
ignored unless it was received on a connection that stapled an OCSP
response. This is complementary with the work that PHB is doing and it
can be done independently. In fact, I'm planning to have Firefox
support this Must-Staple header before it supports the X.509
extension, since we don't know what OID to use for the X.509 extension
yet. I also intend for us to support the X.509 extension.

We designed our normal OCSP stapling implementation with this in mind.
In Firefox (beta) right now, if you staple an OCSP response then it
must be a valid "Good" response or the connection fails.
Unfortunately, we've seen servers stapling expired OCSP responses, so
we're probably going to temporarily make an exception: If you staple
an otherwise-valid "Good" response that is expired, then we'll do the
fetching over OCSP with "hard fail" semantics. Then, the additional
semantics of "Must-Staple" become "Fail the connection if there is no
OCSP response stapled."

PHB: I am happy to help with the "OCSP Stapling Required" X.509 draft
too, if you would like. There are several editorial issues that should
be addressed. If people are interested, we could set up a side
discussion in Vancouver to go over these things, so that we can have a
new, unexpired draft to finish up soon.

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)