Security/Meetings/2011-08-17
From MozillaWiki
Contents
All Hands (lucas)
- get registered and travel if you have not
- what fun thing could we do as a team during the all hands, especially in or near San Jose, especially things that are fun even without large quantities of alcohol?
Meeting time
- Starting next week, this meeting will be at 10am Pacific.
Security bug lifecycle
- today 3pm (MV: 2B)
- evolving critsmash and other sec tasks
- metrics
- small discussion for now, open the audience for next team meeting
- Security/Meetings/lifecycledisc
Project updates
XSS Auditor (Riccardo)
- https://bugzilla.mozilla.org/show_bug.cgi?id=528661
- Patch submitted as related to the review that was conducted
- Awaiting review
DNSSEC, DANE (David Keeler)
- Implemented, some policy questions and testing remain
- License issue for included library needs to be resolved
- Schedule a review
Team embedding
- move bsmith off of Sync as he has a hard conflict that prevents him from attending the Sync team weekly meeting
Malware site blacklisting and application reputation
- NSS Labs report
- http://www.morbo.org/2011/08/note-on-malware-detection-performance.html
- https://bugzilla.mozilla.org/show_bug.cgi?id=662819 - application reputation
- Privacy tradeoffs
Cert revocation isn't working (Kai)
- OCSP revocation is insufficiently integrated into the browser application
- How do we get the web closer to where we can make OCSP mandatory?
- Something softer than an error page
- Broken lock icon / larry line-item?
- Bypassable error page?
- Captive portal detection
- Stapling
- If we start interpreting the presence of OCSP information as mandatory-OCSP, some sites will remove the OCSP information from their cert, out of uptime concerns
- Even with stapling???
- Can a cert specify how strict to be about OCSP failures and how fresh the OCSP response must be?
- And if a cert says it doesn't care, Larry can look slightly sadder
- Something softer than an error page
- Retry on failure
- We'd want to know how frequent each failure mode is. We don't want to overload OCSP servers.
Responding to CA compromise (Kai)
Scenarios
- CA private key compromise
- Intermediate private key compromise
- Mis-issuance
- Mis-issuance of an intermediate cert
- Mis-issuance of a wildcard cert
- Mis-issuance of a single cert (DV authentication compromise)
Responding faster
Is there some way we can prepare in order to respond within hours rather than days?
- Should get things on the roadmap to help us address longer term issues with certs
- Allow Mozilla to push a CA list update (or a cert blacklist update) without updating the browser, so we can revoke a CA?
- But side data updates don't update the About window, so users who want to know whether they're up to date won't know.
- This seems like a solvable problem
- But so many CAs are TBTF
- Time-based revocation (CA can't issue new certs)?
- Downgrade EV to DV
- Let site owners know: "Mozilla will blacklist the CA that gets compromised. If you care about uptime, you need to have an extra cert ready at any time."
- Can we try to formulate standard responses to certain cases?
- Maybe negotiate with other browser manufacturers about these responses
- Requires changes to libpkix?
- But side data updates don't update the About window, so users who want to know whether they're up to date won't know.