Security/Meetings/2011-08-17 - Revision history

Jesse: /* Lifecycle Discussion */

2011-08-17T23:07:40Z

Lifecycle Discussion

← Older revision		Revision as of 23:07, 17 August 2011
Line 4:		Line 4:
	== Meeting time ==		== Meeting time ==
	* Starting next week, this meeting will be at 10am Pacific.		* Starting next week, this meeting will be at 10am Pacific.
	== ~~Lifecycle Discussion~~ ==		== Security bug lifecycle ==
	* today 3pm (MV: 2B)		* today 3pm (MV: 2B)
	* evolving critsmash and other sec tasks		* evolving critsmash and other sec tasks
	* metrics		* metrics
	* small discussion for now, open the audience for next team meeting		* small discussion for now, open the audience for next team meeting
			* [[Security/Meetings/lifecycledisc]]

	== Project updates ==		== Project updates ==

Jesse: /* Lifecycle Discussion */

2011-08-17T22:08:57Z

Lifecycle Discussion

← Older revision		Revision as of 22:08, 17 August 2011
Line 5:		Line 5:
	* Starting next week, this meeting will be at 10am Pacific.		* Starting next week, this meeting will be at 10am Pacific.
	== Lifecycle Discussion ==		== Lifecycle Discussion ==
	* today 3pm		* today 3pm (MV: 2B)
	* evolving critsmash and other sec tasks		* evolving critsmash and other sec tasks
	* metrics		* metrics
	* small discussion for now, open the audience for next team meeting		* small discussion for now, open the audience for next team meeting

	== Project updates ==		== Project updates ==
	=== XSS Auditor (Riccardo) ===		=== XSS Auditor (Riccardo) ===

Jesse: /* Responding to CA compromise (Kai) */

2011-08-17T22:07:48Z

Responding to CA compromise (Kai)

← Older revision		Revision as of 22:07, 17 August 2011
Line 40:		Line 40:
	** We'd want to know how frequent each failure mode is. We don't want to overload OCSP servers.		** We'd want to know how frequent each failure mode is. We don't want to overload OCSP servers.
	== Responding to CA compromise (Kai) ==		== Responding to CA compromise (Kai) ==
	~~Preparing for the next CA or major-site compromise.~~		===Scenarios===
	* CA private key compromise		* CA private key compromise
	* Intermediate private key compromise		* Intermediate private key compromise
Line 47:		Line 47:
	** Mis-issuance of a wildcard cert		** Mis-issuance of a wildcard cert
	** Mis-issuance of a single cert (DV authentication compromise)		** 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?		Is there some way we can prepare in order to respond within hours rather than days?
	* Should get things on [https://wiki.mozilla.org/Security/Roadmap the roadmap] to help us address longer term issues with certs		* Should get things on [https://wiki.mozilla.org/Security/Roadmap the roadmap] to help us address longer term issues with certs

Jesse at 22:07, 17 August 2011

2011-08-17T22:07:01Z

← Older revision		Revision as of 22:07, 17 August 2011
Line 1:		Line 1:
	~~Agenda~~
	== All Hands (lucas) ==		== All Hands (lucas) ==
	* get registered and travel if you have not		* get registered and travel if you have not

Curtisk: Created page with "Agenda == 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..."

2011-08-17T22:00:11Z

Created page with "Agenda == 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..."

New page

Agenda
== 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.
== Lifecycle Discussion ==
* today 3pm
* evolving critsmash and other sec tasks
* metrics
* small discussion for now, open the audience for next team meeting
== 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) ==
Preparing for the next CA or major-site compromise.
* 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)
Is there some way we can prepare in order to respond within hours rather than days?
* Should get things on [https://wiki.mozilla.org/Security/Roadmap 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 [http://en.wikipedia.org/wiki/Too_big_to_fail 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?