Security/Features/Certs Disallow Weak Keys
Status
Disallow Weak RSA Keys | |
Stage | Draft |
Status | ` |
Release target | ` |
Health | OK |
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 |
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
- Pick a release
- Implement and test the enforcement
- 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
`
Feature details
Priority | P2 |
Rank | 999 |
Theme / Goal | Product Hardening |
Roadmap | Security |
Secondary roadmap | ` |
Feature list | ` |
Project | ` |
Engineering team | Security |
Team status notes
status | notes | |
Products | ` | ` |
Engineering | ` | ` |
Security | ` | ` |
Privacy | ` | ` |
Localization | ` | ` |
Accessibility | ` | ` |
Quality assurance | ` | ` |
User experience | ` | ` |
Product marketing | ` | ` |
Operations | ` | ` |
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...
- Related bugs: bug 360126, bug 134735, bug 623265 bug 622859
- press about 512-bit RSA keys -- "The latest versions of Safari ..., Opera, Google Chrome, and Internet Explorer ... Notably, Mozilla Firefox does not yet reject such certificates."
- 512bit certs have been maliciously used.
- Chrome and Apple also previously disallowed certs < 1024 bits.
- Microsoft software update to be released in October 2012 will block the use of cryptographic keys that are less than 1024 bits.
- CAs have confirmed that they are no longer issuing certs less than 1023 bits.
- bug 360126#c10 - rejecting < 1024 is fine.
- bug 360126#c16: NSS has SSL_GetChannelInfo function to enable apps to get and display information about cert key strengths. Also see bug 587234