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)
- [TLS] OCSP Must Staple Phillip Hallam-Baker
- Re: [TLS] OCSP Must Staple Tom Ritter
- Re: [TLS] OCSP Must Staple Alexey Melnikov
- Re: [TLS] OCSP Must Staple Brian Smith