Intent to Deprecate and Remove: TLS 1.2 ECDSA with SHA-1 and SHA-512 signature algorithms

[David Benjamin]

This change does not affect which certificates will be accepted. SHA-1 in certificates has been handled separately. This Intent is to trim the signature algorithms we advertise for the online signature in the TLS protocol itself.

Primary eng (and PM) emails

davi...@chromium.org

Summary

In most modes, TLS 1.2 uses a signature in the ServerKeyExchange message to prove ownership of the private key. There is an extension, signature_algorithms, to negotiate which signature algorithms are acceptable. We intend to remove ECDSA with SHA-1 and ECDSA with SHA-512, leaving SHA-256 and SHA-384 for ECDSA.

Motivation

SHA-1 signatures should not be used. While SHA-1 signatures in certificates are on the way out, SHA-1 is still accepted in the online signature. ECDSA with SHA-1 is virtually nonexistent in the ecosystem, so we intend to remove it. Between RSA/SHA-1 and TLS 1.0/1.1 (both sadly far too widespread to remove at this time), this change will not remove the dependency on SHA-1 for the online signature. But by ratcheting where we can, we hope to help avoid the ecosystem regressing.

Removing SHA-512 signatures with ECDSA is less obvious. However, we only support P-256 and P-384 for ECDSA curves, neither of which admit hashes that large. Hashes larger than SHA-256 (respectively, SHA-384) signed with P-256 (respectively, P-384) get truncated to size, so the larger hash is not useful. Moreover, TLS 1.3 will prohibit ECDSA curve/hash mismatches, so this change aligns our TLS 1.2 and 1.3 advertisements.

Compatibility Risk

Algorithms are negotiated, so server software should automatically select a more suitably-sized hash. ECDSA in TLS is used by few organizations and usually with a more complex setup (some older clients only support RSA), so we expect ECDSA sites to be better maintained and more responsive in case of problems.

Measurements also suggest this is a very low-risk change. See metrics below.

As always, we will monitor the error rate as this change progresses and react to any unforeseen issues.

Alternative implementation suggestion for server administrators

Sign a more suitably-sized hash. Server software should do this automatically and, unlike cipher suites, this is rarely configured (sometimes not even configurable), so no action should be necessary.

We are aware of a bug in OpenSSL, fixed in 2014, which causes some server configurations to only sign SHA-1. There have been several OpenSSL security advisories since then, so administrators are recommended to update regardless. LibreSSL imported the fix in their most recent releases in September 2016. These releases also carry fixes for a recent OpenSSL security advisory, so administrators are recommended to update regardless.

Usage information from UseCounter

ECDSA with SHA-1 usage currently rounds to 0.00% of TLS 1.2 connections. Further, a crawl of top million hosts in Alexa found 54 of 58 SHA-1-signing ECDSA hosts will sign another algorithm when SHA-1 is not advertised so the impact is expected to be lower than measured. We’ll reach out to the remaining 4.

ECDSA with SHA-512 is harder to evaluate. OpenSSL and derivatives are common and preferentially sign the largest hash available, regardless of curve size. However, they all can sign SHA-256 and SHA-384. The same crawl found zero which would break. SSL Labs reports Safari on macOS and iOS do not advertise ECDSA with SHA-512, so any affected sites would also fail to load in those clients.

OWP launch tracking bug

https://crbug.com/655318

Entry on the feature dashboard

https://www.chromestatus.com/feature/5725838074970112

Requesting approval to remove too?

Yes

[Eric Lawrence]

> This change does not affect which certificates will be accepted. SHA-1 in certificates has been handled separately.

While it doesn't impact what certificates the client accepts, will it impact the certificates the server is willing to serve? E.g. https://groups.google.com/a/tagpma.org/forum/#!topic/tagpma-general/_NbjhvKJ4qI implies that IIS was once failing connections that had SHA-512 in the certificate chain if the client didn't advertise support for that in signature_algorithms. 

[David Benjamin]

On Thu, Oct 13, 2016 at 5:13 PM Eric Lawrence <bay...@gmail.com> wrote:

> This change does not affect which certificates will be accepted. SHA-1 in certificates has been handled separately.

While it doesn't impact what certificates the client accepts, will it impact the certificates the server is willing to serve? E.g. https://groups.google.com/a/tagpma.org/forum/#!topic/tagpma-general/_NbjhvKJ4qI implies that IIS was once failing connections that had SHA-512 in the certificate chain if the client didn't advertise support for that in signature_algorithms. 

IIS will attempt to match the sent certificates against signature_algorithms, yeah. Most other server software I know of doesn't. OpenSSL only does it starting 1.0.2 and, even then, only if you explicitly enable it.

I'd also found no ECDSA/SHA-1 or ECDSA/SHA-512 certificates in CT logs. Plus changes made now won't hit the stable channel until 2017, so I believe after the date when SHA-1 certificates are planned to be distrusted anyway.

David

[Chris Harrelson]

LGTM1

--
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.

[Mike West]

Non-owner's LGTM. I agree with your assessment of the risk of dropping these signatures from those we advertise, and aligning with TLS 1.3 requirements now seems like a good-enough justification to proceed.

-mike

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+unsubscribe@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAOMQ%2Bw9rJ515nhZr_SjkfZjJ5bU6BZjcpvOra--NKVKjhWv%3DnQ%40mail.gmail.com.

[Philip Jägenstedt]

Non-expert LGTM2.

On Fri, Oct 14, 2016 at 11:12 AM Mike West <mk...@chromium.org> wrote:

Non-owner's LGTM. I agree with your assessment of the risk of dropping these signatures from those we advertise, and aligning with TLS 1.3 requirements now seems like a good-enough justification to proceed.

-mike

On Fri, Oct 14, 2016 at 12:41 AM, Chris Harrelson <chri...@chromium.org> wrote:

LGTM1

On Thu, Oct 13, 2016 at 3:18 PM, David Benjamin <davi...@chromium.org> wrote:

On Thu, Oct 13, 2016 at 5:13 PM Eric Lawrence <bay...@gmail.com> wrote:

> This change does not affect which certificates will be accepted. SHA-1 in certificates has been handled separately.

While it doesn't impact what certificates the client accepts, will it impact the certificates the server is willing to serve? E.g. https://groups.google.com/a/tagpma.org/forum/#!topic/tagpma-general/_NbjhvKJ4qI implies that IIS was once failing connections that had SHA-512 in the certificate chain if the client didn't advertise support for that in signature_algorithms. 

IIS will attempt to match the sent certificates against signature_algorithms, yeah. Most other server software I know of doesn't. OpenSSL only does it starting 1.0.2 and, even then, only if you explicitly enable it.

I'd also found no ECDSA/SHA-1 or ECDSA/SHA-512 certificates in CT logs. Plus changes made now won't hit the stable channel until 2017, so I believe after the date when SHA-1 certificates are planned to be distrusted anyway.

David

--
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+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "net-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.

To post to this group, send email to net...@chromium.org.

[TAMURA, Kent]

The risk looks low.  LGTM3.

On Fri, Oct 14, 2016 at 6:25 PM, Philip Jägenstedt <foo...@chromium.org> wrote:

Non-expert LGTM2.

On Fri, Oct 14, 2016 at 11:12 AM Mike West <mk...@chromium.org> wrote:

Non-owner's LGTM. I agree with your assessment of the risk of dropping these signatures from those we advertise, and aligning with TLS 1.3 requirements now seems like a good-enough justification to proceed.

-mike

On Fri, Oct 14, 2016 at 12:41 AM, Chris Harrelson <chri...@chromium.org> wrote:

LGTM1

On Thu, Oct 13, 2016 at 3:18 PM, David Benjamin <davi...@chromium.org> wrote:

On Thu, Oct 13, 2016 at 5:13 PM Eric Lawrence <bay...@gmail.com> wrote:

> This change does not affect which certificates will be accepted. SHA-1 in certificates has been handled separately.

While it doesn't impact what certificates the client accepts, will it impact the certificates the server is willing to serve? E.g. https://groups.google.com/a/tagpma.org/forum/#!topic/tagpma-general/_NbjhvKJ4qI implies that IIS was once failing connections that had SHA-512 in the certificate chain if the client didn't advertise support for that in signature_algorithms. 

IIS will attempt to match the sent certificates against signature_algorithms, yeah. Most other server software I know of doesn't. OpenSSL only does it starting 1.0.2 and, even then, only if you explicitly enable it.

I'd also found no ECDSA/SHA-1 or ECDSA/SHA-512 certificates in CT logs. Plus changes made now won't hit the stable channel until 2017, so I believe after the date when SHA-1 certificates are planned to be distrusted anyway.

David

--
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.

--
You received this message because you are subscribed to the Google Groups "net-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+unsubscribe@chromium.org.

To post to this group, send email to net...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAOMQ%2Bw9rJ515nhZr_SjkfZjJ5bU6BZjcpvOra--NKVKjhWv%3DnQ%40mail.gmail.com.

--

TAMURA Kent
Software Engineer, Google

[aslsys....@dmartindia.com]

What is solution over ECDSA with SHA-512 signature algorithms?
--


*This e-mail is confidential and intended for the recipient alone. This
may constitute privileged information and if you are not the intended
recipient please delete the message and notify the sender immediately by
return e-mail.*


www.dmartindia.com <http://www.dmartindia.com> 

[David Benjamin]

On Fri, Aug 23, 2019 at 12:30 PM aslsys.support via net-dev <net...@chromium.org> wrote:

What is solution over ECDSA with SHA-512 signature algorithms?

We only advertise support for P-256 and P-384, so SHA-512 was already being truncated down. As is required in TLS 1.3, you should match the hash algorithm to the curve. If the key is P-256, use SHA-256. If it's P-384, use SHA-384. (Though in TLS 1.2, we don't enforce they match, so if you wanted to swap them you could.)

[ASL SYS Support]

Dear David,

In our environment, we generated the certificate SHA-512 ECDSA Algorithm. It is supported for latest Google Chrome Version i.e 76.0.3809

Whenever we change the SSL certificate URL does not work in latest google chrome version. Kindly provide the solution for this issue.

Note: Kindly log the Service Request ticket in sapphire for any service/issue.

Thanks & Regards

Jitendra Nevarekar

AD Support
Tel 022-71230828 / 785

Avenue Supermarts Ltd (Dmart)

This e-mail is confidential and intended for the recipient alone. This may constitute privileged information and if you are not the intended recipient please delete the message and notify the sender immediately by return e-mail.

www.dmartindia.com 

[Adam Langley]

On Sun, Aug 25, 2019 at 10:45 PM 'ASL SYS Support' via Security-dev <securi...@chromium.org> wrote:

In our environment, we generated the certificate SHA-512 ECDSA Algorithm. It is supported for latest Google Chrome Version i.e 76.0.3809

Whenever we change the SSL certificate URL does not work in latest google chrome version. Kindly provide the solution for this issue.

This logic does not depend on the issuance date of the certificate so, if something no longer works, pertinent aspects of the certificate have likely changed. We may be able to help if given some information. For example, the new and old certificates, or a URL of a server that isn't loading in Chrome.

Cheers

AGL 

[ASL SYS Support]

Dear Adam,

Our application URL is working in all IE and Google Chrome versions with old certificate i.e Signature Algorithm is "sha256RSA".

And we have made changes in new certificate as for Signature Algorithm is "sha512ECDSA". When binding such certificate to application site, URL does not open in new Google chrome version <63.00 version.

Kindly suggest any solution for this issue. (Is it required any TLS setting?)

Thanks & Regards

Jitendra

[Adam Langley]

On Mon, Aug 26, 2019 at 6:08 AM ASL SYS Support <aslsys....@dmartindia.com> wrote:

Our application URL is working in all IE and Google Chrome versions with old certificate i.e Signature Algorithm is "sha256RSA".

And we have made changes in new certificate as for Signature Algorithm is "sha512ECDSA". When binding such certificate to application site, URL does not open in new Google chrome version <63.00 version.

Chrome 63 is extremely old and no longer supported.

Since Chrome only advertises support for P-256 and P-384 in the TLS handshake, some servers will refuse to use a P-521 certificate. (I forget whether we decided that was sensible given the RFCs or not, but it's something that happens.) If you selected SHA-512 as the hash, you might have generated a P-521 certificate to match, but without the certificate itself I can't tell.

In general, if you want to use ECDSA, SHA-256 with P-256 is recommended. If you believe that the probability of a breakthrough in elliptic-curve analysis that breaks P-256 but, somehow, not larger curves, is non-trivial, SHA-384 with P-384 will also work. P-521 is a very convenient prime but doesn't offer enough benefit for the extra complexity and may not work.

Cheers

AGL

[ASL SYS Support]

Dear Adam,

Sorry for typo mistake, as per my scenario its worked in lower version of google chrome (below ver 63) and URL not able to open in latest google chrome version (above ver 63). What should I do?

Note: Kindly log the Service Request ticket in sapphire for any service/issue.

Thanks & Regards

Jitendra Nevarekar

AD Support
Tel 022-71230828 / 785

Avenue Supermarts Ltd (Dmart)

[Adam Langley]

On Mon, Aug 26, 2019 at 10:13 PM 'ASL SYS Support' via Security-dev <securi...@chromium.org> wrote:

Sorry for typo mistake, as per my scenario its worked in lower version of google chrome (below ver 63) and URL not able to open in latest google chrome version (above ver 63). What should I do?

If you want an ECDSA certificate, then use SHA-256 with P-256.

Cheers

AGL