Security/Features/CA pinning functionality - Revision history

Sidstamm at 20:44, 30 July 2013

2013-07-30T20:44:06Z

← Older revision		Revision as of 20:44, 30 July 2013
Line 7:		Line 7:
	}}		}}
	{{FeatureTeam		{{FeatureTeam
	\|Feature product manager=~~Lucas Adamski~~		\|Feature product manager=Sid Stamm
	\|Feature feature manager=Camilo Viecco		\|Feature feature manager=Camilo Viecco
	\|Feature lead engineer=Camilo Viecco		\|Feature lead engineer=Camilo Viecco
Line 62:		Line 62:
	{{FeatureInfo		{{FeatureInfo
	\|Feature priority=P1		\|Feature priority=P1
	\|Feature theme=~~Security Leadership~~		\|Feature theme=TLS Hardening
	\|Feature roadmap=Security		\|Feature roadmap=Security
	\|Feature engineering team=Security		\|Feature engineering team=Security
	}}		}}
	{{FeatureTeamStatus}}		{{FeatureTeamStatus}}

Cviecco at 22:26, 27 September 2012

2012-09-27T22:26:17Z

← Older revision		Revision as of 22:26, 27 September 2012
Line 3:		Line 3:
	\|Feature stage=Development		\|Feature stage=Development
	\|Feature status=In progress		\|Feature status=In progress
	~~\|Feature version=Firefox 17~~
	\|Feature health=OK		\|Feature health=OK
	\|Feature status note=~~Waiting for feedback from permission manager peer or owner~~		\|Feature status note=Depends on enabling libpkix by default. The feature will land one relase after the pkix landing.
	}}		}}
	{{FeatureTeam		{{FeatureTeam

Cviecco at 05:40, 9 August 2012

2012-08-09T05:40:44Z

← Older revision		Revision as of 05:40, 9 August 2012
Line 25:		Line 25:
	* Enabling pinning without also requiring HTTPS (see section 6.5 of spec)		* Enabling pinning without also requiring HTTPS (see section 6.5 of spec)
	\|Feature functional spec=It will be deployed in two pushes:		\|Feature functional spec=It will be deployed in two pushes:
	1. Do built in pins.		# Do built in pins.
	2. Allow website pin data as the ietf draft		# Allow website pin data as the ietf draft

	See https://tools.ietf.org/html/draft-evans-palmer-key-pinning .		See https://tools.ietf.org/html/draft-evans-palmer-key-pinning .
Line 38:		Line 38:
	1. (the default) Ignore Pinning IF the trust anchor is not a built in CA.		1. (the default) Ignore Pinning IF the trust anchor is not a built in CA.
	2. Strict enforcement.		2. Strict enforcement.

	\|Feature ux design=The draft recommends that users have ways of querying which domains are pinned. We need to consider whether we think this is necessary and, if so, how to do it. (Perhaps integrated with the history view?)		\|Feature ux design=The draft recommends that users have ways of querying which domains are pinned. We need to consider whether we think this is necessary and, if so, how to do it. (Perhaps integrated with the history view?)
	No UI will be provided to change the enforcement level.		No UI will be provided to change the enforcement level.

Cviecco at 16:36, 8 August 2012

2012-08-08T16:36:53Z

← Older revision		Revision as of 16:36, 8 August 2012
Line 24:		Line 24:
	\|Feature non-goals=* Replacing the existing x.509 PKI infrastructure. (This is a refinement.)		\|Feature non-goals=* Replacing the existing x.509 PKI infrastructure. (This is a refinement.)
	* Enabling pinning without also requiring HTTPS (see section 6.5 of spec)		* Enabling pinning without also requiring HTTPS (see section 6.5 of spec)
	\|Feature functional spec=See https://tools.ietf.org/html/draft-evans-palmer-key-pinning .		\|Feature functional spec=It will be deployed in two pushes:
			1. Do built in pins.
			2. Allow website pin data as the ietf draft

			See https://tools.ietf.org/html/draft-evans-palmer-key-pinning .

	However we need to get clarification on several issues including:		However we need to get clarification on several issues including:
	1. What do do when muliple headers are found (?)		1. What do do when muliple headers are found (?)
	2. What is the benefit for the requirement that the backup key must NOT be in the chain?		2. What is the benefit for the requirement that the backup key must NOT be in the chain?

			To allow for self MIM the pinning feature will provide three enforcement levels (it will always be calculated)
			0: Ignore pinning, ie allow connectionw with failed pin data. (calculate but store result somewhere internally) Hopefully we can put some UX to reflect failed pins, but this is outside of the current scope.
			1. (the default) Ignore Pinning IF the trust anchor is not a built in CA.
			2. Strict enforcement.

	\|Feature ux design=The draft recommends that users have ways of querying which domains are pinned. We need to consider whether we think this is necessary and, if so, how to do it. (Perhaps integrated with the history view?)		\|Feature ux design=The draft recommends that users have ways of querying which domains are pinned. We need to consider whether we think this is necessary and, if so, how to do it. (Perhaps integrated with the history view?)
			No UI will be provided to change the enforcement level.

	If site access is denied, we will need a screen explaining why. (There will be no override, as per spec.)		If site access is denied, we will need a screen explaining why. (There will be no override, as per spec.)
Line 44:		Line 55:
	2. Ability to "Note" a pinning when presented over an error free TLS connection		2. Ability to "Note" a pinning when presented over an error free TLS connection
	3. Ability to use the permission manager at chain building time to ensure a valid (from the pinning perspective planner exists).		3. Ability to use the permission manager at chain building time to ensure a valid (from the pinning perspective planner exists).
			\|Feature qa review=This will require a lot of QA, in particular due to the built-in roots. Will need non trivial collaboration with QA.
	\|Feature implementation notes=So we have two bugs created now:		\|Feature implementation notes=So we have two bugs created now:
	https://bugzilla.mozilla.org/show_bug.cgi?id=744212 (this one is waiting for review)		https://bugzilla.mozilla.org/show_bug.cgi?id=744212 (this one is waiting for review)

Cviecco at 15:36, 11 June 2012

2012-06-11T15:36:02Z

← Older revision		Revision as of 15:36, 11 June 2012
Line 25:		Line 25:
	* Enabling pinning without also requiring HTTPS (see section 6.5 of spec)		* Enabling pinning without also requiring HTTPS (see section 6.5 of spec)
	\|Feature functional spec=See https://tools.ietf.org/html/draft-evans-palmer-key-pinning .		\|Feature functional spec=See https://tools.ietf.org/html/draft-evans-palmer-key-pinning .

			However we need to get clarification on several issues including:
			1. What do do when muliple headers are found (?)
			2. What is the benefit for the requirement that the backup key must NOT be in the chain?
	\|Feature ux design=The draft recommends that users have ways of querying which domains are pinned. We need to consider whether we think this is necessary and, if so, how to do it. (Perhaps integrated with the history view?)		\|Feature ux design=The draft recommends that users have ways of querying which domains are pinned. We need to consider whether we think this is necessary and, if so, how to do it. (Perhaps integrated with the history view?)

Line 35:		Line 39:

	We shall notice that this is an HTTP extension. Not an TLS/SSL extension.		We shall notice that this is an HTTP extension. Not an TLS/SSL extension.

			There are 3 parts fo the implementation:
			1. Enhance permission manager to include strings for storage (https://bugzilla.mozilla.org/show_bug.cgi?id=744212 )
			2. Ability to "Note" a pinning when presented over an error free TLS connection
			3. Ability to use the permission manager at chain building time to ensure a valid (from the pinning perspective planner exists).

	\|Feature implementation notes=So we have two bugs created now:		\|Feature implementation notes=So we have two bugs created now:
	https://bugzilla.mozilla.org/show_bug.cgi?id=744212		https://bugzilla.mozilla.org/show_bug.cgi?id=744212 (this one is waiting for review)
	and		and
	https://bugzilla.mozilla.org/show_bug.cgi?id=744204		https://bugzilla.mozilla.org/show_bug.cgi?id=744204
			\|Feature landing criteria=This feature depends on using libpkix for functionality.
	}}		}}
	{{FeatureInfo		{{FeatureInfo

Sidstamm at 22:18, 7 June 2012

2012-06-07T22:18:43Z

← Older revision		Revision as of 22:18, 7 June 2012
Line 1:		Line 1:
	{{FeatureStatus		{{FeatureStatus
	\|Feature name=CA Pinning		\|Feature name=CA Pinning
	\|Feature stage=~~Draft~~		\|Feature stage=Development
			\|Feature status=In progress
			\|Feature version=Firefox 17
	\|Feature health=OK		\|Feature health=OK
			\|Feature status note=Waiting for feedback from permission manager peer or owner
	}}		}}
	{{FeatureTeam		{{FeatureTeam

Cviecco at 20:42, 26 April 2012

2012-04-26T20:42:20Z

← Older revision		Revision as of 20:42, 26 April 2012
Line 30:		Line 30:

	Shall this be included in the STS .idl file? Dont know yet.		Shall this be included in the STS .idl file? Dont know yet.

			We shall notice that this is an HTTP extension. Not an TLS/SSL extension.
	\|Feature implementation notes=So we have two bugs created now:		\|Feature implementation notes=So we have two bugs created now:
	https://bugzilla.mozilla.org/show_bug.cgi?id=744212		https://bugzilla.mozilla.org/show_bug.cgi?id=744212

Cviecco at 17:52, 26 April 2012

2012-04-26T17:52:57Z

← Older revision		Revision as of 17:52, 26 April 2012
Line 30:		Line 30:

	Shall this be included in the STS .idl file? Dont know yet.		Shall this be included in the STS .idl file? Dont know yet.
			\|Feature implementation notes=So we have two bugs created now:
			https://bugzilla.mozilla.org/show_bug.cgi?id=744212
			and
			https://bugzilla.mozilla.org/show_bug.cgi?id=744204
	}}		}}
	{{FeatureInfo		{{FeatureInfo

Ladamski at 00:01, 13 April 2012

2012-04-13T00:01:00Z

← Older revision		Revision as of 00:01, 13 April 2012
Line 35:		Line 35:
	\|Feature theme=Security Leadership		\|Feature theme=Security Leadership
	\|Feature roadmap=Security		\|Feature roadmap=Security
			\|Feature engineering team=Security
	}}		}}
	{{FeatureTeamStatus}}		{{FeatureTeamStatus}}

Cviecco at 17:27, 5 April 2012

2012-04-05T17:27:58Z

← Older revision		Revision as of 17:27, 5 April 2012
Line 15:		Line 15:
	\|Feature overview=Now they can require HTTPS connections (via HSTS), sites may want to also restrict the CAs who can issue certificates for their domain to a small number (> 1) that they trust. This can be accomplished via providing a list of certificate fingerprints, at least one of which must be present in any chain considered valid for the domain. This is rather like what Chrome has done [http://www.imperialviolet.org/2011/05/04/pinning.html] except we would not be managing a static list of anchors.		\|Feature overview=Now they can require HTTPS connections (via HSTS), sites may want to also restrict the CAs who can issue certificates for their domain to a small number (> 1) that they trust. This can be accomplished via providing a list of certificate fingerprints, at least one of which must be present in any chain considered valid for the domain. This is rather like what Chrome has done [http://www.imperialviolet.org/2011/05/04/pinning.html] except we would not be managing a static list of anchors.
	\|Feature users and use cases=CA Foo is compromised and grants a certificate for example.com to an attacker. The owners of example.com have their site pinned to certificates from CAs Bar and Baz, so when the attacker attempts to use the certificate from CA Foo, he fails to satisfy the pinning requirement. Any users presented with his certificate will not have access to the fraudulent connection (hard fail).		\|Feature users and use cases=CA Foo is compromised and grants a certificate for example.com to an attacker. The owners of example.com have their site pinned to certificates from CAs Bar and Baz, so when the attacker attempts to use the certificate from CA Foo, he fails to satisfy the pinning requirement. Any users presented with his certificate will not have access to the fraudulent connection (hard fail).

			The spec does not necesaily ping the CA, it pins a subset of keys so that at least one of the keys pinned must be in the CA list of the certificate.
	\|Feature dependencies=<strike>HSTS.</strike> This feature should not be tied to HSTS, but the two technologies should work together.		\|Feature dependencies=<strike>HSTS.</strike> This feature should not be tied to HSTS, but the two technologies should work together.
	\|Feature requirements=Google has had CA pinning for a while; we should talk to them about their experience and any risks/problems with current proposals. (We need to separate issues with having a hard-coded list, which we aren't planning to do, from issues with the idea of pinning itself.)		\|Feature requirements=Google has had CA pinning for a while; we should talk to them about their experience and any risks/problems with current proposals. (We need to separate issues with having a hard-coded list, which we aren't planning to do, from issues with the idea of pinning itself.)
Line 25:		Line 27:

	We should already have mechanisms for clearing stored HSTS information when the user clears their history; pin information should go with it.		We should already have mechanisms for clearing stored HSTS information when the user clears their history; pin information should go with it.
			\|Feature implementation plan=The pinning data will be stored as a site pref. And it will be implemented in a way similar to STS. The first stage would be to enhance the preferences to be able to store blobs or strings.

			Shall this be included in the STS .idl file? Dont know yet.
	}}		}}
	{{FeatureInfo		{{FeatureInfo