Security/Features/Certs Disallow Weak Keys

From MozillaWiki
Jump to navigation Jump to search
Please use "Edit with form" above to edit this page.

Status

Disallow Weak RSA Keys
Stage Draft
Status `
Release target `
Health OK
Status note `

{{#set:Feature name=Disallow Weak RSA Keys

|Feature stage=Draft |Feature status=` |Feature version=` |Feature health=OK |Feature status note=` }}

Team

Product manager Sid Stamm
Directly Responsible Individual `
Lead engineer `
Security lead `
Privacy lead `
Localization lead `
Accessibility lead `
QA lead `
UX lead `
Product marketing lead `
Operations lead `
Additional members Kathleen Wilson

{{#set:Feature product manager=Sid Stamm

|Feature feature manager=` |Feature lead engineer=` |Feature security lead=` |Feature privacy lead=` |Feature localization lead=` |Feature accessibility lead=` |Feature qa lead=` |Feature ux lead=` |Feature product marketing lead=` |Feature operations lead=` |Feature additional members=Kathleen Wilson }}

Open issues/risks

Need to pick a release in which we plan to disallow weak keys, so we can start communications.

Stage 1: Definition

1. Feature overview

RSA keys < 2048 bits should be considered invalid for SSL certificates. They're easy to break and we should treat certs with these weak keys as invalid.

Since 2010 we have been communicating to CAs about CA:MD5and1024 which says: "Under no circumstances should any party expect continued support for RSA key size smaller than 2048 bits past December 31, 2013."

See also: https://cabforum.org/pipermail/public/2013-September/002233.html

2. Users & use cases

Make the web safer. Kill weak keys.

3. Dependencies

`

4. Requirements

We should plan for which release the change will go in, and announce it well ahead of time, which means picking a release and moving from there.

Non-goals

`

Stage 2: Design

5. Functional specification

`

6. User experience design

`

Stage 3: Planning

7. Implementation plan

  1. Pick a release
  2. Implement and test the enforcement
  3. land it

8. Reviews

Security review

`

Privacy review

`

Localization review

`

Accessibility

`

Quality Assurance review

`

Operations review

`

Stage 4: Development

9. Implementation

`

Stage 5: Release

10. Landing criteria

` {{#set:Feature open issues and risks=Need to pick a release in which we plan to disallow weak keys, so we can start communications. |Feature overview=RSA keys < 2048 bits should be considered invalid for SSL certificates. They're easy to break and we should treat certs with these weak keys as invalid.

Since 2010 we have been communicating to CAs about CA:MD5and1024 which says: "Under no circumstances should any party expect continued support for RSA key size smaller than 2048 bits past December 31, 2013."

See also: https://cabforum.org/pipermail/public/2013-September/002233.html |Feature users and use cases=Make the web safer. Kill weak keys. |Feature dependencies=` |Feature requirements=We should plan for which release the change will go in, and announce it well ahead of time, which means picking a release and moving from there. |Feature non-goals=` |Feature functional spec=` |Feature ux design=` |Feature implementation plan=# Pick a release

  1. Implement and test the enforcement
  2. land it

|Feature security review=` |Feature privacy review=` |Feature localization review=` |Feature accessibility review=` |Feature qa review=` |Feature operations review=` |Feature implementation notes=` |Feature landing criteria=` }}

Feature details

Priority P2
Rank 999
Theme / Goal Product Hardening
Roadmap Security
Secondary roadmap `
Feature list `
Project `
Engineering team Security

{{#set:Feature priority=P2

|Feature rank=999 |Feature theme=Product Hardening |Feature roadmap=Security |Feature secondary roadmap=` |Feature list=` |Feature project=` |Feature engineering team=Security }}

Team status notes

  status notes
Products ` `
Engineering ` `
Security ` `
Privacy ` `
Localization ` `
Accessibility ` `
Quality assurance ` `
User experience ` `
Product marketing ` `
Operations ` `

{{#set:Feature products status=`

|Feature products notes=` |Feature engineering status=` |Feature engineering notes=` |Feature security status=` |Feature security health=` |Feature security notes=` |Feature privacy status=` |Feature privacy notes=` |Feature localization status=` |Feature localization notes=` |Feature accessibility status=` |Feature accessibility notes=` |Feature qa status=` |Feature qa notes=` |Feature ux status=` |Feature ux notes=` |Feature product marketing status=` |Feature product marketing notes=` |Feature operations status=` |Feature operations notes=` }}


http://research.microsoft.com/pubs/206278/ndss.pdf: "In terms of key lengths, perhaps surprisingly, we find that the proportion of signed certificates with 1024-bit keys actually went up from 4.3% (plus 117 intermediate CAs) to 5.2% (plus 2 intermediate CAs) between the two periods. For endpoint and intermediate CA certificates, 1024-bit keys are allowed by the CA/Browser Forum if they expire before 2014. Checking this requirement, the percentage of violations among endpoint certificates is in fact going down slightly from 0.57% to 0.53%. Investigating further, we found that the main providers of 1024-bit keys (Google, Akamai, and Servision) are issuing only short lifespan certificates and seem to be in the process of moving to 2048-bit keys.

Our code still allows certs with 512-bit RSA keys...