Intent to Remove: Support for RSA keys smaller than 2048 bits in TLS certificates

[Ryan Sleevi]

Primary eng (and PM) emails

rsl...@chromium.org awha...@chromium.org

Link to "Intent to Deprecate" thread

No deprecate thread. Browsers have required that all new RSA certificates valid after Dec 31 2013 be issued with key sizes of at least 2048-bits, first starting as a requirement in late 2011.

Summary

This is concluding a half-decade long migration away from weaker keys (those with RSA key sizes less than 2048-bits).

Certificates issued with such keys will be treated as if their key was weak, as is already done for key sizes less than 1024 bits (technically, 1023, due to CAs' inability to follow IETF drafts)

Motivation

Browsers have been collaborating in the CA/Browser Forum to deprecate this practice for the past decade, with the first version of the Baseline Requirements (late 2011) fully forbidding certificates from being valid after 12-31-2013 with RSA key sizes less than 2048 bits.

Despite this, it still took several years to phase out the practice, particularly for intermediate certificates that needed to be rotated.

The risk in accepting a weak key size is that the key has an increased risk of factoring by motivated attackers, and is below the threshold suitable for long-lived protection.

Compatibility Risk

Low. The Baseline Requirements have capped the practice since 2011.

The CA/Browser Forum itself has strong signals from other UAs for deprecating. However, to date, only Apple has expressed support for enforcing (via App Transport Security), although I suspect our Mozilla colleagues may be interested in moving forward as well.

Usage Information

The affect that this would have on the number of certificate validations is tracked by the CertificateType2 set of metrics, which are broken down by the BR effective day (2012-07-01), the type of certificate (leaf, intermediate, root) and the key algorithm being used. This proposal would only affect RSA keys.

From the BR-compliant set:

CertificateType2.BR.Leaf.RSA = 0.00%

CertificateType2.BR.Intermediate.RSA = 0.00%

CertificateType2.BR.Root.RSA = 0.03%

From the pre-BR set

CertificateType2.NonBR.Leaf.RSA = 0.00%

CertificateType2.NonBR.Intermediate.RSA = 0.01%

CertificateType2.NonBR.Root.RSA = 0.22%

However, note that "NonBR" is measured by the leaf's validity period, not the roots'. Thus that 0.22% is "The set of certificates whose leaf cert is set at 2012-07-01 or earlier, and which is not expired" - meaning these certificate have been in use for nearly 5 years, which is well-into the legacy that is also being deprecated (the BRs previously required 60 month validity - 5 years - presently require 39 month validity - 3.25 years - and we're working to reduce that significantly in the coming months).

OWP launch tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=686909

Entry on the feature dashboard

[Unclear whether this warrants one]

[Mike West]

On Tue, Jan 31, 2017 at 12:03 AM, 'Ryan Sleevi' via net-dev <net...@chromium.org> wrote:

Primary eng (and PM) emails

rsl...@chromium.org awha...@chromium.org

Link to "Intent to Deprecate" thread

No deprecate thread. Browsers have required that all new RSA certificates valid after Dec 31 2013 be issued with key sizes of at least 2048-bits, first starting as a requirement in late 2011.

Summary

This is concluding a half-decade long migration away from weaker keys (those with RSA key sizes less than 2048-bits).

Certificates issued with such keys will be treated as if their key was weak, as is already done for key sizes less than 1024 bits (technically, 1023, due to CAs' inability to follow IETF drafts)

I'm 100% behind this at a high level. I agree with you that this is the right behavior for us to move to.

 

Usage Information

The affect that this would have on the number of certificate validations is tracked by the CertificateType2 set of metrics, which are broken down by the BR effective day (2012-07-01), the type of certificate (leaf, intermediate, root) and the key algorithm being used. This proposal would only affect RSA keys.

From the BR-compliant set:

CertificateType2.BR.Leaf.RSA = 0.00%

CertificateType2.BR.Intermediate.RSA = 0.00%

CertificateType2.BR.Root.RSA = 0.03%

From the pre-BR set

CertificateType2.NonBR.Leaf.RSA = 0.00%

CertificateType2.NonBR.Intermediate.RSA = 0.01%

CertificateType2.NonBR.Root.RSA = 0.22%

However, note that "NonBR" is measured by the leaf's validity period, not the roots'. Thus that 0.22% is "The set of certificates whose leaf cert is set at 2012-07-01 or earlier, and which is not expired" - meaning these certificate have been in use for nearly 5 years, which is well-into the legacy that is also being deprecated (the BRs previously required 60 month validity - 5 years - presently require 39 month validity - 3.25 years - and we're working to reduce that significantly in the coming months).

I don't understand what these numbers mean. What's the numerator? What's the denominator? Do 0.22% of TLS connections chain up to a root created before the relevant BR revision whose key is weak? Or do 0.22% of TLS connections chain up to a root using an RSA key (which might or might not be <2048 bits)? Or something else altogether?

-mike

[Ryan Sleevi]

On Mon, Jan 30, 2017 at 4:09 PM, Mike West <mk...@chromium.org> wrote:

From the BR-compliant set:

CertificateType2.BR.Leaf.RSA = 0.00%

CertificateType2.BR.Intermediate.RSA = 0.00%

CertificateType2.BR.Root.RSA = 0.03%

From the pre-BR set

CertificateType2.NonBR.Leaf.RSA = 0.00%

CertificateType2.NonBR.Intermediate.RSA = 0.01%

CertificateType2.NonBR.Root.RSA = 0.22%

However, note that "NonBR" is measured by the leaf's validity period, not the roots'. Thus that 0.22% is "The set of certificates whose leaf cert is set at 2012-07-01 or earlier, and which is not expired" - meaning these certificate have been in use for nearly 5 years, which is well-into the legacy that is also being deprecated (the BRs previously required 60 month validity - 5 years - presently require 39 month validity - 3.25 years - and we're working to reduce that significantly in the coming months).

I don't understand what these numbers mean. What's the numerator? What's the denominator? Do 0.22% of TLS connections chain up to a root created before the relevant BR revision whose key is weak? Or do 0.22% of TLS connections chain up to a root using an RSA key (which might or might not be <2048 bits)? Or something else altogether?

Described proasically:

- If a certificate is not issued by a publicly-trusted (BR compliant) root, ignore. This means any enterprise-installed certificates

- The chain is classified as either being a "BR compliant" chain (the leaf certificate was issued after 2012-07-01) or a "non-BR compliant" chain (the leaf certificate was reportedly issued prior to 2012-07-01)

- For each certificate in the chain, it's bucketed into either "Leaf" (i == 0), "intermediate" (i > 0 && i < size - 1), or "root" (i == size - 1)

So, for example, CertificateType2.BR.Root.RSA means that 0.03% of all certificate validations that are rooted in an RSA key, and which the server's certificate was issued after 2012-07-01, validate to a root certificate less than 2048 bits.

CertificateType2.NonBR.Root.RSA means that 0.22% of all certificate validations that are rooted in an RSA key, which the server's certificate was issued *before* 2012-07-01, validate to a root certificate less than 2048 bits.

It's a fair question about what the numerator and denominator mean. So using the above example, CertificateType2.NonBR.Root.RSA, you'd want to sum all of the NonBR.Root.RSA counts to know how many RSA key-rooted certificates, or sum all of NonBR.Root.* values (to know how many non-BR certificates there were).

Since your question is "Overall number of validations", we can:

- Take the sum of BR.Root.* and NonBR.Root.* (which collectively represents 100% of publicly trusted certificates), and then compute the fraction of which NonBR.Root.RSA < 2048.

For the case of "How many certificate validations would enforcing this on the root" mean, we end up with 0.03% of connections.

So despite the "0.22%" being large, the actual end-user effect overall is 0.03%.

[Ryan Sleevi]

On Mon, Jan 30, 2017 at 4:25 PM, Ryan Sleevi <sle...@google.com> wrote:

Since your question is "Overall number of validations", we can:

- Take the sum of BR.Root.* and NonBR.Root.* (which collectively represents 100% of publicly trusted certificates), and then compute the fraction of which NonBR.Root.RSA < 2048.

Er, sorry, the 0.03% was based on the combined sum of BR.Root.RSA and NonBR.Root.RSA.

The 0.22% maps to .00002% of connections overall.

[Mike West]

Thanks for the explanation, Ryan!

Non-OWNER's LGTM based on the real risk of weak keys, and the pretty insubstantial expected breakage.

Given your suspicion that Mozilla folks would be interested in moving in the same direction, perhaps you could file a bug against Firefox pointing to this thread?

-mike

[Ryan Sleevi]

On Mon, Jan 30, 2017 at 4:32 PM, Mike West <mk...@chromium.org> wrote:

Thanks for the explanation, Ryan!

Non-OWNER's LGTM based on the real risk of weak keys, and the pretty insubstantial expected breakage.

Given your suspicion that Mozilla folks would be interested in moving in the same direction, perhaps you could file a bug against Firefox pointing to this thread?

Mozilla bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1137484 and they're in the telemetry gathering phase.

Their numbers overcount for manually installed roots (it looks like), but they already refuse EV treatment for such certificates. 

[Philip Jägenstedt]

Thanks for the detailed explanations and usage analysis, Ryan. LGTM1

Aside: I'm curious about the "BRs previously required 60 month validity" and upcoming changes. Would making this validity limit short enough (e.g. 1 year) make date-based restrictions more workable for phasing out weak keys and other problems? As this has been a half-decade migration, being able to move faster without risking (unexpected) hard breakage would be awesome.

[Jochen Eisinger]

lgtm2

[Chris Harrelson]

LGTM3

lgtm2

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.