Security/Meetings/2011-08-17

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
• 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?