921907 - Enable OCSP must-staple feature

Status: RESOLVED FIXED

(Core :: Security: PSM, defect)

Description

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

+++ This bug was initially created as a clone of Bug #901698 +++

OCSP must-staple requires us to be certain that we do PKIX path building correctly, so this depends on bug 915930.

OCSP must-staple also requires us to be certain that we never fall back to SSL 3.0 for any site that is must-staple, and the work to do that depends on bug 839310 to avoid conflicts.

Comment 1

[Klemens Baum]

What's still preventing this from being implemented?

Bug #901698 seems to be more about the HSTS-style Must-Staple, not the x509v3 extension. That work seems to be stalled, because it suffers from the first-connection problem or scalability issues if Must-Staple preload lists have to be distributed.

So far it looks like the only thing preventing the x509v3 extension draft from moving forward is the lack of at least one browser implementation. It would be great if we could have such an implementation soon, so that IANA can proceed with OID allocation.

Comment 2

[Tim Kuijsten]

I think the TOFU design is not a problem, but more of an improvement over the current situation of having no real world revocation possible at all. Besides, security minded people are already accustomed to the "pre-load your websites before you travel" pattern because of HSTS.

Supporting a Must-Staple header might also stimulate any progress on the x509 draft, which seem to have been stalled.

According to "Recommendations for Secure Use of TLS and DTLS" section 6.3 (the most recent draft that mentions must-staple):
"The current consensus appears to be that OCSP stapling, combined with
a "must staple" mechanism similar to HSTS, would finally resolve this
problem.  But such a mechanism has not been standardized yet."
https://tools.ietf.org/html/draft-ietf-uta-tls-bcp-01#section-6.3

Since the HTTP-header is the most independent and thus fastest way for Mozilla to lead this technology, I hope this will be implemented. Who knows what x509 incentive this might create.

Comment 3

[Tim Kuijsten]

(sorry for spamming, just found out about a thread on IETF of last summer and a new draft)

@briansmith, after the private implementation you've build last summer [1], did you do any more experimenting or implement the most recent draft from last December [2]?

[1] http://www.ietf.org/mail-archive/web/tls/current/msg12785.html
[2] http://www.ietf.org/id/draft-hallambaker-tlsfeature-06.txt

Comment 4

[Mark Goodwin [:mgoodwin]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=e06438c614c0

Comment 5

[Mark Goodwin [:mgoodwin]]

Attachment: MozReview Request: Bug 921907 - Enable OCSP must-staple. r?keeler

Bug 921907 - Enable OCSP must-staple. r?keeler

Comment 6

[Mark Goodwin [:mgoodwin]]

This time actually running some tests...

https://treeherder.mozilla.org/#/jobs?repo=try&revision=ea7f8e3db027

Comment 7

[Dana Keeler (she/her) (use needinfo) [:keeler]]

Comment on attachment 8690032 [details]
MozReview Request: Bug 921907 - Enable OCSP must-staple. r?keeler

https://reviewboard.mozilla.org/r/25751/#review23211

I'm not entirely sure why we set this up this way, but yes, let's go ahead and enable it.

Comment 8

[Mark Goodwin [:mgoodwin]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/bd02f1cb9f4fe84ee6a42cafef7d2d5d9784b753
Bug 921907 - Enable OCSP must-staple. r=keeler

Comment 9

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/bd02f1cb9f4f