Subject: [TLS] OCSP Must Staple

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 23 Oct 2013 09:46:05 -0400

We have been discussing MUST staple for quite some time. The ADs would like
to know if there is support for adding this feature to certificates.

The draft I wrote is designed to be agile so that it covers all new OCSP
stapling like ideas rather than just being a one off. But it is pretty
simple:

http://tools.ietf.org/html/draft-hallambaker-tlsfeature-02

The advantage of MUST staple is that if a client receives a TLS cert chain
with MUST Staple and no OCSP token then it can refuse the connection and
hard fail rather than attempting to retrieve the token and soft failing.

This allows for a performance improvement and a security improvement.

-- 
Website: http://hallambaker.com/

---

From: Tom Ritter <[email-masked]>
Date: Wed, 23 Oct 2013 11:58:11 -0400

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.

-tom

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 28 Oct 2013 16:16:51 +0000

On 23/10/2013 14:46, Phillip Hallam-Baker wrote:
> We have been discussing MUST staple for quite some time. The ADs would 
> like to know if there is support for adding this feature to certificates.
>
> The draft I wrote is designed to be agile so that it covers all new 
> OCSP stapling like ideas rather than just being a one off. But it is 
> pretty simple:
>
> The advantage of MUST staple is that if a client receives a TLS cert 
> chain with MUST Staple and no OCSP token then it can refuse the 
> connection and hard fail rather than attempting to retrieve the token 
> and soft failing.
>

I read the draft and this work looks interesting to me.

---

From: Brian Smith <[email-masked]>
Date: Mon, 28 Oct 2013 12:35:30 -0700

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