Intent to Deprecate: SHA-1 certificates

[Ryan Sleevi]

Primary eng (and PM) emails

rsl...@chromium.org

Summary

The use of SHA-1 within TLS certificates is no longer sufficiently secure. This is an intent to phase them out (in 2-3 years). In order to make such a phase-out execute smoothly, rather than be an Internet flag day, we will be degrading the experience when these certificates are used in the wild.

The following changes to Chromium's handling of SHA-1 are proposed:

- All SHA-1-using certificates that are valid AFTER 2017/1/1 are treated insecure, but without an interstitial. That is, they will receive a degraded UI indicator, but users will NOT be directed to click through an error page.

- Additionally, the mixed content blocker will be taught to treat these as mixed content, which WILL require a user action to interact with.

- All SHA-1-using certificates that are valid AFTER 2016/1/1 are treated as insecure, but without an interstitial. They will receive a degraded UI indicator, but will NOT be treated as mixed content.

Motivation

We need to execute the SHA-1 transition smoother than MD5.

MD5 was first shown weak in 1995 and was no longer recommended for new usages.

In 2004, it was near conclusively broken for most purposes, by showing it was not collision resistant.

In 2008, researchers were able to obtain a usable fraudulent certificate through MD5 manipulation from a CA.

Yet Chrome was not able to remove it until December 2011, due to it's widespread use on the Internet, and having to lead the way as one of the first browsers to do so (iOS mobile deprecated MD5 slightly earlier).

In doing so, Chrome users, particularly in enterprise scenarios, were surprised when a variety of so-called security products failed to work, often due to the security products insecure settings.

The lesson from this is that as long as it is supported, Certificate Authorities and software vendors will continue to use SHA-1. Discussions within the CA/Browser Forum have established that CAs do not view SHA-1 as a significant enough risk to begin active deprecation, in part, because any one CA that refuses to issue SHA-1 certificates is just giving customers to any other CA that will.

Despite the CA/Browser Forum's Baseline Requirements, published in 2011, recommending that SHA-1 only be used until the majority of browsers support SHA-256 (with Windows XP earlier than SP2 not supporting SHA-256 being the primary concern), CAs have still not transitioned.

Microsoft has been the first to announce hard dates - with CAs in their root program no longer being able to issue SHA-1 following 2016/1/1, and with Microsoft planning to disable SHA-1 in 2017/1/1. However, Microsoft has left enough room for alteration that CAs are not taking this plan seriously, and thus not beginning to transition away.

Without action, there is great risk that CAs will continue to issue SHA-1 certificates up until 2015/12/31, the maximum lifetime of which can be 39 months, meaning these certificates will be valid until 2019. However, before 2015/4/1, CA's may issue up to 60 months - meaning valid until 2021.

Using SHA-1 in 2020 is unacceptable. Using SHA-1 in 2015 is not desirable.

By degrading the UI, we wish to provide negative reinforcement that SHA-1 is no longer secure enough, and positive encouragement for CA's that adopt modern algorithms.

Compatibility Risk

Chromium will be the first browser to make this transition, and thus will bear the brunt of compatibility issues. However, this is precisely to avoid having significant portions of the Internet break in 2017 if CAs continue (and, based on evidence, are accelerating) the currently insecure practice.

CAs have been aware of this desire by the Chromium networking and security teams to deprecate since February 2014, and have had half a year to prepare their infrastructure and issuance pipelines. This followed Microsoft's announcement in November of 2013.

Alternative implementation suggestion for web developers

Site operators that are affected by this have several options:

• Immediately transition to SHA-256. Users running Windows XP versions older than SP2 already are vulnerable to significant security risks, and should at least update to a modern version of XP (Microsoft Genuine checks are no longer required for XP security updates, so all users have this available).
• Transition to a SHA-1 certificate that is not valid longer than 2015/12/31, recognizing that eventually it will be necessary to transition to SHA-256.
• (less than ideal) Transition to a SHA-1 certificate that is not valid longer than 2016/12/31, recognizing that Chrome users will see a degraded UI.

Each of these "transition" options SHOULD, if using a respected CA, generally be a free option available to their users. Many CAs will offer users both SHA-1 and SHA-256 certificates (simultaneously), to allow the customer to transition and experiment with transitioning as necessary.

The largest risk is for users who are using certificates that have other undesirable security properties, such as unvalidated information or weaker keys (RSA keys less than 2048 bits). Because CAs MUST ensure that all new certificates conform to the Baseline Requirements, customers who purchased certificates before 2012 that were valid for extended period of times (e.g. up until 2022, as some CAs sold 10 year certs) will find they will need to be issued a new certificate, which may require additional and necessary security checks, and it will not be able to exceed the 60 month maximum validity.

Usage information from UseCounter

Based on the Certificate Transparency logs operated by Google, which records all certificates Google has seen or has had submitted to it (e.g. it includes certificates that have been revoked or discontinued, in addition to active certificates), this means the following:

SHA-1 and valid longer than 2016/1/1 - Approximately 14% of all certificates seen between 2012 and 2014 (previously, from 2012 - 2013, this was only 9.6% )

SHA-1 and valid longer than 2017/1/1 - Approximately 6.2% of all certificates seen between 2012 and 2014 (previously, from 2012 - 2013, this was only 4.13% )

Approximately 17 CAs (actual organizations, counting for acquisitions, is about 12) are responsible for 92% of the 2016 certs.

Approximately 11 CAs (closer to 7 actual organizations) are responsible for 92% of the 2017 certs.

Further details on who these CAs are is available at https://crbug.com/401365

Entry on chromestatus.com, crbug.com, or MDN

https://code.google.com/p/chromium/issues/detail?id=401365

Requesting approval to remove too?

No

Barring cryptographic advances, the plan will be to synchronize with Microsoft, and hopefully other user agents, in fully removing this in 2017. This deprecation is in alignment with those goals, with the hope that SHA-1 will be virtually unused in certificates by 2016, ensuring a smooth removal.

[William Chan (陈智昌)]

No one has responded, so I'm just chiming in to say that this sounds awesome to me. Carry on.

--
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CACvaWvY69QubTnWTan62QkJjW%3D5gGbixHB9Cp8GGbq_RoMv1Og%40mail.gmail.com.

[yuhong...@hotmail.com]

"(Microsoft Genuine checks are no longer required for XP security updates, so all users have this available)."

It never was true as far as I know.

[Mike West]

On Thu, Aug 21, 2014 at 12:45 AM, William Chan (陈智昌) <will...@chromium.org> wrote:

No one has responded, so I'm just chiming in to say that this sounds awesome to me. Carry on.

LGTM as well, for what it's worth.

In particular, the mixed content aspect of the deprecation is a nice way of ratcheting up protections for our users, and is certainly in-line with the "deprecated TLS protection" concept defined in the spec.

-mike

[rowl...@gmail.com]

With rekeys, duplicates, early renewal programs, etc., I think most of the certificates valid in 2016 will be replaced well before then. Considering many CAs are working to move existing SHA1 customers to SHA2 before 2016, showing a UI degradation now will probably only serve to upset website owners rather than spur faster adoption. Most of these customers are on a set transition plan that will move them to SHA2 well before the deadline, despite having a certificate currently that extends past the end of 2015. At least consider a "window" in the validity period range where the transition will likely happen before 2016 despite a post-2016 validity period (such as March 2016). Putting the degradation on certs with a validity period past March 2016 will likely have the same effect in spurring a transition to SHA2 but let people keep their current transition plan in-tact.

Jeremy

On Tuesday,

[bruce....@entrust.com]

Hi Ryan, some input.

There are 3 SHA-1 attacks that need to be considered: collision, second-preimage and preimage. SHA-1 is weak when considering a collision attack, but is not considered weak for either preimage attacks.

A collision attack can happen at the time of certificate issuance. The policy to stop issuing SHA-1 signed certificates as of January 1, 2016 mitigates the collision attack. At that time the maximum validity period will be 39 months, so all SHA-1 signed certificates will have expired by April 1, 2019.

Since collision will be mitigated, then the next attack we need to consider is second-preimage. It is unlikely that SHA-1 will be susceptible for a second-preimage attack before April 1, 2019. As such, I do not see any value in providing a degraded UI indicator.

Also, since Microsoft has stated that Windows will not support SHA-1 as of January 1, 2017; it is likely that most users will have switched to SHA-2 by then. Please note that Microsoft might change this date based on its evaluation of preimage. I would suggest that it would be of little value extending the date out past April 1, 2019 as most of the SHA-1 certificates will be expired by then.

Thanks, Bruce.

[Ryan Sleevi]

On Thu, Aug 21, 2014 at 1:28 PM, <bruce....@entrust.com> wrote:

Hi Ryan, some input.

There are 3 SHA-1 attacks that need to be considered: collision, second-preimage and preimage. SHA-1 is weak when considering a collision attack, but is not considered weak for either preimage attacks.

A collision attack can happen at the time of certificate issuance. The policy to stop issuing SHA-1 signed certificates as of January 1, 2016 mitigates the collision attack. At that time the maximum validity period will be 39 months, so all SHA-1 signed certificates will have expired by April 1, 2019. 

Since collision will be mitigated, then the next attack we need to consider is second-preimage. It is unlikely that SHA-1 will be susceptible for a second-preimage attack before April 1, 2019. As such, I do not see any value in providing a degraded UI indicator.

Also, since Microsoft has stated that Windows will not support SHA-1 as of January 1, 2017; it is likely that most users will have switched to SHA-2 by then.

Note that this deprecation is a direct complement to this. Microsoft's requirements for their root are no new issuances beyond January 1, 2016 - as you note, mitigating the collision.

However, after January 1, 2017 - no SHA-1 certificates will be accepted. The 2019 date is thus irrelevant for discussion.

The goal of this degraded UI is to help ensure an orderly transition away from SHA-1, by ensuring that users and site operators are aware of the number and nature of sites that will no longer work after 2017/1/1. If we allowed these certificates to be valid to 2019/4/1, then it's extremely possible (and, as shown by MD5, virtually guaranteed) that site operators and users will be completely unprepared for that 2017 date.

Internet flag days are bad for everyone involved, and we wish to avoid that.

We know that CAs are unable to effectively communicate with their users (site operators) - often due to no fault of the CA themselves, but that site operators tend to ignore emails and alerts. This is based on our experiences with deprecating RSA-1024 bit certificates, especially root certificates, in which hundreds of thousands of sites are negatively affected by and can trivially fix.

This UI policy has the effect of encouraging site operators and CAs to work towards a migration sooner (by 2016/1/1), rather than waiting until the last possible second (2017/1/1). For those that do choose to wait until the last possible second, they're at least consciously aware that they're doing so, and prepared for the 2017/1/1 shutdown date.

 

Please note that Microsoft might change this date based on its evaluation of preimage. I would suggest that it would be of little value extending the date out past April 1, 2019 as most of the SHA-1 certificates will be expired by then.

Thanks, Bruce.

Microsoft may, but I don't think we will. Microsoft's made it clear to CAs how unlikely this is, though a possibility, and what information may lead to this.

This deprecation helps both the Chromium team and other UAs, such as Microsoft and Mozilla, understand the greater scope and user impact. For example, as I mentioned in the notice, when MD5 was deprecated, though it was used on ~5% of the internet, it was significantly higher in enterprise "security" products. Unlike CAs, such vendors have virtually no incentive to take users security seriously, but their use absolutely puts Chromium users at risk (and the broader Internet), so it was a balanced tradeoff.

The net-effective of this deprecation policy is:

Site operators MUST *be prepared and aware* of the need to transition to SHA-256 by 2017/1/1

Site operators SHOULD *be prepared and aware* of the need to transition to SHA-256 by 2016/1/1. This is important, because in the event of a need to reissue a certificate (e.g. for another Heartbleed-like event, as hopefully unlikely as that may be), that is the ONLY type of the certificate they can legitimately acquire.

Our end goal with this is to ensure that no user's browsing experience is disrupted in 2016 or 2017, because the Internet will have transitioned away.

However, without these sorts of changes as proposed, all the evidence and metrics we're measuring suggest an orderly transition will not and is not happening as a whole, even if individual CAs are slowly transitioning.

Thanks for the feedback!

[robin...@gmail.com]

My concern is what about the SHA-1 root certificate in OS trust store.
Google is using the root certificate come with operating system, is it also affect the SHA-1 root certificate?

[Lucas Garron]

For those of us who are not involved with this, is there anywhere but bug reports where the policy/plans for certificate hashes are laid out, apart from this email?

In particular, It appears that this change would mean SHA-256 will remain the only valid hash algorithm for signatures. Is that correct?

(As far as I understand, the main known qualitative flaw of SHA-256 is that it is still subject to an extension attack. That's not directly applicable to certificate collisions, but still not desirable, I imagine.)

Are there current plans to support and/or encourage SHA-3 after it is "finalized"?

»Lucas Garron

On Tue, Aug 19, 2014 at 9:52 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

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

[Ryan Sleevi]

As noted in the original posting, this applies to the entire chain of validated signatures.

The root certificate's signature is not validated - as it's merely a delivery mechanism for a subject name/public key pair.

So the SHA-1 certificates in the OS trust store are irrelevant, provided that the entire intermediate-and-leaf chain is of sufficient security, much in the same way that the use of MD5 in the root certificates is irrelevant.

[Ryan Sleevi]

On Thu, Aug 21, 2014 at 7:38 PM, Lucas Garron <crease...@gmail.com> wrote:

For those of us who are not involved with this, is there anywhere but bug reports where the policy/plans for certificate hashes are laid out, apart from this email?

security-dev / net-dev@ in general are the venues for exploring Chromium policies.

However, the more substantive meat of discussions happens typically in the CA/Browser Forum (public archive here - https://cabforum.org/pipermail/public/ ) and in the Mozilla dev.security.policy list ( https://lists.mozilla.org/listinfo/dev-security-policy ), in which much more outreach and evangelism with CAs happens.

That is, by the time it reaches security-dev@/net-dev@, it's often been discussed at length both with CAs and in the context of the public CA root program that Mozilla operates.

 

In particular, It appears that this change would mean SHA-256 will remain the only valid hash algorithm for signatures. Is that correct?

Effectively, yes.

 

(As far as I understand, the main known qualitative flaw of SHA-256 is that it is still subject to an extension attack. That's not directly applicable to certificate collisions, but still not desirable, I imagine.)

Are there current plans to support and/or encourage SHA-3 after it is "finalized"?

Similar to the earlier comments, this remains TBD, but can generally be assumed. What you'll see is a series of activities in other venues before it trickles down to Chrome. You'll see IETF publishing some form or draft describing how SHA-3 is used in the context of PKIX signatures. You'll see the CA/Browser Forum updating the Baseline Requirements (and related documents) to support SHA-3. You'll see the audit requirements derived from the CA/B Forum's documents updated to permit them. You'll see the root program requirements changed to accept them.

Somewhere in that time frame, you'll likely see implementation within Chromium to support it, although note that Chromium is currently dependent upon the OS capabilities for cert verification.

To the extent of "support and/or encourage SHA-3", the primary activity will be through Chromium engineers' involvement in the IETF, the CA/Browser Forum, and Mozilla's public root CA program, more than any explicit "Intent to Implement" on these lists.

[Chris Bentzel]

The plan overall sounds great, and I'm glad that it is trying to avoid
the flag day behavior.

I am a bit concerned about treating content retrieved over connections
using sha-1 signed certificates valid after 2017/1/1 as mixed-content
during the early stages of this phase-out - particularly for mixed
script which may effectively break a number of sites immediately.
Perhaps the first release or two could change the UI security
indicators and dump information to the devtools console about the
upcoming mixed-content change without actually enforcing it? This
would also let us gather information for how frequently this happens
weighted by usage (page views or some other metric).

[bruce....@entrust.com]

On Thursday, August 21, 2014 5:09:13 PM UTC-4, Ryan Sleevi wrote:
> However, after January 1, 2017 - no SHA-1 certificates will be accepted. The 2019 date is thus irrelevant for discussion.
>
>
> The goal of this degraded UI is to help ensure an orderly transition away from SHA-1, by ensuring that users and site operators are aware of the number and nature of sites that will no longer work after 2017/1/1. If we allowed these certificates to be valid to 2019/4/1, then it's extremely possible (and, as shown by MD5, virtually guaranteed) that site operators and users will be completely unprepared for that 2017 date.

The issue with MD5 was that it was found to be weak to collision and some CAs did not stop signing certificates with MD5. On the other hand, MD5 still has strength against a second-preimage or preimage attack.

The way we can be different with SHA-1, is to stop issuing SHA-1 signed certificates. The CAs will stop signing with SHA-1 due to the Microsoft policy. For SSL, the preimage attacks will be mitigated as the old SHA-1 certificates expire. I do not believe that anyone is stating that there is a vulnerability to preimage in the next 5 years, which is the maximum lifetime of an SSL certificate issued today.

The browser does not need to provide warnings for SHA-1 certificates that were issued before January 1, 2016. For these certificates, the preimage attack will be mitigated by expiry.

[Ryan Sleevi]

Bruce,

These certificates will stop working after 2017. The browser absolutely can and should provide warnings.

As I am sure you are well aware, nothing in the CA/Browser Forum's requirements require that a CA place the issuance date in the notBefore. While this is expected by common sense, we regularly see CAs fudge this number - for both legitimate (easing interoperability with machines with slightly-off clocks) and illegitimate (to avoid additional checks imposed by browsers) means.

I think where your idea is flawed is that it assumes the UA can reasonably and reliably detect 'when' a certificate is issued. This is not and has never been the case - for certificates that conform to the Baseline Requirements or for certificates issued by internal CAs and security software.

As shown by MD5, the ONLY way to get software and CAs to transition away from issuing SHA-1 certs is to actually disable it. This notice phase serves as a way of informing users and site operators of coming changes - changes 2-3 years away, and changes not just being made by Chromium, but other UAs as well.

[b...@digicert.com]

If the downgraded UI is the https with the red slash through it, doesn't that go too far in providing a warning? In other words, if I saw it, I would think that there was something more severely wrong with the website's SSL certificate or the encryption behind it, etc. So far, SHA1 has not been broken, at least publicly. My understanding is that we're just trying to accelerate migration away from SHA1. So I would think a less severe UI downgrade would be better than the red slash.
Thanks,
Ben Wilson

[Ryan Sleevi]

On Aug 22, 2014 9:55 AM, <b...@digicert.com> wrote:
>
> If the downgraded UI is the https with the red slash through it, doesn't that go too far in providing a warning?  In other words, if I saw it, I would think that there was something more severely wrong with the website's SSL certificate or the encryption behind it, etc. 

That's not the case for most users, but it sounds like you're agreeing that its bad, just disagreeing on the UX.

Chromium has a UI for 'origins that attempt to be secure (HTTPS) but are not secure'. Its a red lock with strike through. This is a UX issue for Chromium.

> So far, SHA1 has not been broken, at least publicly.

There are graduations of broken. It's not binary.

What we do see is that SHA-1 is showing the same set of weaknesses at MD5, and multiple rounds of weakening that allow an attacker to create colliding blocks.

It's not YET as computationally easy as MD5, at least from the public research, but that's irrelevant with respect to whether we need to transition. This is especially true based on the fact that the Flame malware (2012), which also exploited MD5 collisions, used methods that were entirely unknown to the public as being weak.

>  My understanding is that we're just trying to accelerate migration away from SHA1.  So I would think a less severe UI downgrade would be better than the red slash.
> Thanks,
> Ben Wilson
>

Given how easy it is for sites and CAs to mitigate this issue with zero compatibility issues, I think this is unnecessary.

The fundamental question is whether we (Chromium) view SHA-1 as secure enough to be worthy of a secure indicator.

That answer from everyone involved on the Chromium side is no, although its clear for some CAs on this thread they think the answer should be 'yes'. This is not surprising, as its the cause of the impasse in the CA/Browser Forum.

We had hoped to see this practice stop in 2012, as the Baseline Requirements so strongly encouraged, so it's not that we have not made repeated attempts to work with CAs on timelines.

[Chris Palmer]

On Thu, Aug 21, 2014 at 9:07 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

>> For those of us who are not involved with this, is there anywhere but bug
>> reports where the policy/plans for certificate hashes are laid out, apart
>> from this email?
>
> security-dev / net-dev@ in general are the venues for exploring Chromium
> policies.

Additionally, keep an eye on these 2 "forever" bugs:

https://code.google.com/p/chromium/issues/detail?id=102949

https://code.google.com/p/chromium/issues/detail?id=119213

It's an on-going effort to enforce, at run-time, as much tightness in
cryptographic parameters as is possible. Also, to ratchet upward.

[tshi...@trustwave.com]

On Friday, August 22, 2014 12:01:29 AM UTC-4, Ryan Sleevi wrote:
> As noted in the original posting, this applies to the entire chain of validated signatures.

Can we clarify if the date checks apply only to the end-entity certificates? Or do they also apply to the intermediates? If the latter, that would require new SHA-1 intermediates to be issued with 2015-12-31 expiration dates in order to offer the option of a shorter-term SHA1-signed certificate to customers.

[Ryan Sleevi]

The evaluation is described in the linked bug.

Only the leaf certificates notAfter is considered (and independent of leaf signature algorithm), but if it matches the criteria, then all the validated signatures in the chain (i.e. excluding the root) are considered.

No new intermediates are required, unless you are issuing long-lived SHA-256 certs that chain to a SHA-1 intermediate.

[Ben Wilson]

Is there a web page where someone can take a look at all of Chrome's address-bar security-related traffic signs (i.e. small image files)? 

Thanks,

Ben

[ni...@cloudflare.com]

This timeline for deprecating SHA-1 is very aggressive and puts us
(CloudFlare) in a bind.

Currently we provide certificates to our customers signed by GlobalSign's
SHA-1 intermediate, with a 3 year expiration (i.e. all customer certificates
from this year are valid for part of 2017). We still use these SHA-1 certificates
because a large percentage of the web visitors of our customers are using
Windows XP SP2 which does not support SHA-256. It's not realistic to expect
everyone to be able to upgrade to SP3.

This change will force our customers to have to choose between having a
mixed content warning on Chrome or cutting off a large portion of their
visitor base.

Can we please delay this move until at least next year?

[Matt Menke]

Is there a reason to think the situation will be significantly different in 4 months?  Seems unlikely to me.  XP SP3 has been out for 6 years now.

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/c73f30b1-2c3e-4e85-9a81-5a90026b4c5e%40chromium.org.

[Ryan Sleevi]

Nick,

We've been communicating this to CAs for some time. I'm sorry that GlobalSign hasn't been passing that on.

As mentioned, if you set your expiration for these CloudFlare hosted certs to be 2015/12/31, you will receive no warnings.

After 2016/1/1, no CA is allowed to issue SHA-1 certificates. As such, all sites SHOULD be prepared to switch (e.g. for emergency purposes such as Heartbleed or CA compromise).

That still gives you more than a year to test and help migrate.

I do take issue with the definition of 'a large percentage'. Evidence suggests this is a quite small percent (<= 1%), and large sites have already transitioned (Twitter) or are in the process of transitioning.

[Nick Sullivan]

Hi Ryan,

Re-issuing every one of our client certificates is not a trivial task. Being forced to do so in the next few weeks without warning is not something we (or many other sites) were prepared for. I'm sure we are not the only ones who would appreciate a delay in this change.

Many of the sites that use our services have user bases in geographical locations where cutting off XP SP2 is just not a feasible option this year. For some sites, the percentage is much higher than 1%. Hopefully this situation will resolve itself within two years, but it will not be resolved in 6-12 weeks.

Nick

[Ryan Sleevi]

Hi Nick,

CAs were told about these plans 6 months ago, in order to help their customers prepare and move off. We waited for this long precisely because CAs at the time indicated they took the matter seriously and knew this was coming.

As Matt mentioned, XP SP3 has been out for 6 years. What do you think will change in the next 4 months - or the next 4 years - that hasn't already happened?

Short of CAs stopping issuing SHA-1 certs (which the evidence is that there is no such rush occurring, despite widespread agreement even in 2009 on the risks of continuing the current path), I don't see what will change. CAs have continued to use XP SP2 as the justification for years now, but I think we're well beyond the point in which that explanation holds muster (e.g. we're well into the long-tail now).

I also find disconcerting your answer that you're not prepared for large-scale re-issuance. This was something that has already shown to be necessary this year (Heartbleed), and something that's inevitable with further cryptoanalytic advances in SHA-1 (e.g. the very thing we're trying to avoid en masse).

Knowledge of SHA-1 deprecation by Microsoft has been out for nearly a year. Can you share what, if any, steps CloudFlare has taken to support that?

To be clear, I'm not trying to be dismissive of your concerns. However, the ecosystem is precarious here, with CAs continually unwilling to take the first step unless all CAs do, and enough CAs refuse to do so, preventing any meaningful security improvements. It was necessary in 2011 for Chrome to take the first step in disabling MD5, despite years of undeniable evidence of its insecurity. I cannot help but feel we're at that point with SHA-1 as well, and the proposed plan balances the trade-offs to users (we don't want to require interstitials), to site operators (they can continue using SHA-1 through 2016 without any effect, and 2017 with degraded UI), and to CAs (who, despite having significant advance notice, have not meaningfully moved)

As a prime example, even discussions to simply require that CA's offer SHA-256 by default to all new customers, and require the customer to explicitly request SHA-1 (such as for situations like you describe) have been outright rejected, repeatedly, by CAs. I think we've made every good-faith effort to avoid surfacing UI, but if we continue the present course and continue to delay action, then we're only leaving our users more at risk, and making the situation even more and more guaranteed of mutually assured trouble for users.

[rowl...@gmail.com]

Can you provide a link to the communication with CAs, Ryan? I don't recall seeing anything that explained any of the proposed Chrome changes. As far as I knew, Chrome was planning on following the Microsoft deadline of 2017, not accelerating the date to 2016. I think the sheer volume of 2016 certificates suggests the number is quite large, not a small percent.

[Ryan Sleevi]

Sure.

This was discussed for around an hour/hour and a half during the CA/Browser Forum's February 2014 meeting, hosted by Google in Mountain View.

The minutes are available at cabforum.org and were sent to the CA/B Forum's place.

Given that all CAs are expected to adhere to the Baseline Requirements, which are developed in the CA/B Forum, it is reasonably expected that CAs are following the discussion, even when they are not directly contributing.

[rowl...@gmail.com]

Those links don't show disclosure of a new 2016 deadline. In fact, they support the CA's understanding of Jan 1 2017 as the deprecation date:


"Chrome's plan continues to remain aggressive - disallowing certain algorithms/key sizes if their issuance date is after their sunset-grace period, outright rejecting them if their validity period exceeds the sunset-fail period, and eventually outright removing support entirely. As such, a CA that (continues) to issue such certs would not (ultimately) be causing outright risk to *current* versions of Chrome users"

[JR] The sunset-fail period is 2017, not 2016.

"Ryan: <snip> It goes back to attempting what we believe is a balanced approach for the user experience by telling the user that we don’t have full confidence in this site but allowing the user to proceed, but this may become more serious over time. So we’ll transition the user by not giving an EV indication. We’re also not going to require users to click through warnings."

[JR] Again, this is about 2017.


"Ryan: This pushes support to the browsers because when a site operator does not switch over to SHA2 people will say the browser doesn’t work. So, regardless of the sunset date, we’ll have to start taking away your security benefits soon, but it would be better to find a solution based on policy. If we cannot come to agreement on policy, like Brian said, then we are going to have different approaches, but we cannot have a situation where we’re going to allow CAs to run SHA1 certificates up the wire and pass the cost on to the browsers. The reality is that when a site breaks, it is not the site operator that suffers, it’s the users, and users don’t contact the site operator, they contact the browser or they go on social media and complain."

[JR] This is about certificates that expire after the 2017 deadline.

"Ryan: It is all fine that we as a CA/Browser Forum can agree on something, but we need to get the attention of site operators and users on this. If January 2016 is the date that CAs cease issuing SHA1 certificates, but site operators are installing 3-year certificates until then, we’re going to see problems when they have forgotten about it. If we cannot resolve this in the CA/Browser Forum, it will be something the browsers will start working on to get that messaging out."

[JR] It says right in this section that the date CAs are supposed to stop issuing is 2016. The deprecation date for use is 2017.

"Bob: Ryan has said that in Chrome they will implement a countdown meter that tells end users that in X days the website will stop working because the server has not migrated from SHA1.

[JR] Referencing certificates that expire in 2017.

[rowl...@gmail.com]

Alex,

The point is not that there shouldn't be a degraded UI for the 2017 deadline. The concern is that Google has suddenly accelerated the deadline to 2016 immediately after customers and CAs developed transition plans based on the 2017 deadline previously discussed.

Jeremy

[Ryan Sleevi]

On Fri, Aug 22, 2014 at 2:55 PM, <rowl...@gmail.com> wrote:

Those links don't show disclosure of a new 2016 deadline.  In fact, they support the CA's understanding of Jan 1 2017 as the deprecation date:


"Chrome's plan continues to remain aggressive - disallowing certain algorithms/key sizes if their issuance date is after their sunset-grace period, outright rejecting them if their validity period exceeds the sunset-fail period, and eventually outright removing support entirely. As such, a CA that (continues) to issue such certs would not (ultimately) be causing outright risk to *current* versions of Chrome  users"

[JR] The sunset-fail period is 2017, not 2016.

Hi Jeremy,

I'm sorry that this was not clear to you. It was clear to Bob, and considering the duration we discussed in (during the F2F and later during our calls), it was hoped this was clear.

The original plan from February - one which we backed off of precisely based on CA feedback - was that any SHA-1 certificate with a validity after 2017 would be outright rejected. This is noted above.

As Bob's comment notes, it was also clear that the degraded UI, which would not require direct user action, was something that would begin before then. As discussed during the F2F, this was proposed as 2016, the point in which CAs could no longer issue such certificates.

I do want to reiterate, none of this is with the goal to 'penalize' anybody. It's to make sure that users and site operators are aware that 2017 is a date that SHA-1 MUST be deprecated. As we have heard from other CAs, and even from organizations such as CloudFlare, that's a position that's not being accurately or honestly reflected in the certificates being issued today, and that represents a real danger to being able to effectively deprecate SHA-1.

As I noted in my original mail, we saw this same issue with MD5, preventing it from being disabled. This cannot be allowed to happen again - leaving users vulnerable for five years to real and practical attacks, with no mitigations (other than those adopted AFTER researchers demonstrated how trivial it was, for which we can and should reasonably infer it was in use by attackers BEFORE then)

If this were a proposal to interstitial users, which was the original plan, I can absolutely understand and appreciate the hesitation. However, this is about making sure that Chrome's security UI accurately reflects the views of the Chromium developer community, and the greater cryptographic community at large, as to what represents acceptable security/risk. In 2011, CAs also agreed of the risks posed, so it's surprising to hear them so downplayed now.

There are plenty of options for mitigations of this, but I think the core element is this, and was noted by Chris Palmer earlier: The age of having a secure UI remain static for five years is no longer tenable. It is expected that sites be able to respond to and adapting to security threats. This applies whether you're talking about TLS protocol level attacks like BEAST, cryptographic attacks like those involved in certificate issuance, or application-level attacks such as mixed content.

For the vast majority of our users, security is a one-or-two bit state, not the gradiations that CAs may see. In this model, we need to accurately reflect to the user whether or not we believe they're secure.

Using SHA-1 is not something we believe is secure. We won't require the user to take make a decision immediately - that's not for another two and a half years - but we also won't and cannot bestow a secure indicator just because we always did. This plan has directly taken feedback from CAs and already delayed it (by 6 months) and softened it (by not interstitialling). This represents a reasonable compromise between the interests at play.

At present, the plan is to roll this out roughly over 12 weeks - that's three full months for CAs and sites to prepare. If this was being rolled out tomorrow to stable users, I can understand the concern. But I think this represents a generous time for sites to be notified and prepare. If a site is not capable of changing its cert within 12 weeks, then I think we have a far more serious security problem - as Heartbleed as taught us.

[rowl...@gmail.com]

I understand the UI degradation context before 2017, but the comments surrounding the degradation all indicated the UI degradation was going to happen only to certs valid past the 2017 deadline.

I was expecting a degradation now for certs still valid in 2017 but affecting certs valid in 2016, especially when the previous policy was that SHA-1 certs could be issued until 2016, seems like a sudden change.

[Brian Smith]

On Tue, Aug 19, 2014 at 9:52 PM, Ryan Sleevi <rsl...@chromium.org> wrote:
> The following changes to Chromium's handling of SHA-1 are proposed:

[snip]

I think this is a very cool proposal.

It seems like the proposal only deals with SHA-1 signatures used in
certificates' signatures, but it doesn't say anything about SHA-1 use
in the signatures of the TLS ServerKeyExchange message. It may be
useful to say what, if anything, you are planning to do change
regarding SHA-1- or SHA-1+MD5- signed ServerKeyExchange messages, and
on what timeline. Similarly, it would be interesting to here your
plans, if any, regarding changing the values delivered in the TLS
signature_algorithms extension to advertise that SHA-1 is no longer
supported. Note, in particular, that SHA-1(+MD5) signatures MUST be
used in TLS 1.1 and earlier, so potentially there could be
version-specific policies regarding this. And, also note that even TLS
1.2 (weakly) encourages SHA-1 to be used for signatures when the
server certificate's keypair is a DSA keypair.

More below.

> Site operators that are affected by this have several options:
>

> * Immediately transition to SHA-256. Users running Windows XP versions older

> than SP2 already are vulnerable to significant security risks, and should at
> least update to a modern version of XP (Microsoft Genuine checks are no
> longer required for XP security updates, so all users have this available).
>

> * Transition to a SHA-1 certificate that is not valid longer than 2015/12/31,

> recognizing that eventually it will be necessary to transition to SHA-256.
> (less than ideal)
>

> * Transition to a SHA-1 certificate that is not valid longer

> than 2016/12/31, recognizing that Chrome users will see a degraded UI.
>
> Each of these "transition" options SHOULD, if using a respected CA,
> generally be a free option available to their users. Many CAs will offer
> users both SHA-1 and SHA-256 certificates (simultaneously), to allow the
> customer to transition and experiment with transitioning as necessary.

It may be useful to suggest a specific instance of such an
experimental transition plan of using SHA-1 and SHA-256 certificates
simultaneously:

* Acquire both SHA-1 and SHA-256 certificate chains from the
certificate authority.

* Deploy TLS 1.2 with support for the dowgrade SCSV [1] configured to
prevent insecure fallback to versions prior to TLS 1.2 for browsers
that support TLS 1.2 and the downgrade SCSV. This way, you can rely on
the signature_algorithms TLS extension, which is not sent in versions
prior to TLS 1.2.

* Configure the server's TLS stack to work as follows: If the client
sent the signature_algorithms extension and it indicates support for
SHA-2-based signatures, then use the SHA-256-based certificate chain.
Otherwise, use some (currently-unspecified) heuristics based on the
information in the ClientHello message to determine whether to send a
SHA-2-based or SHA-1-based certificate chain. Preferably, default to
SHA-256 when the heuristics fail.

Pros:

1. More servers would start using SHA-256-based certificate chains
sooner with modern (TLS-1.2-capable) browsers, by immediately (as soon
as servers support the mechanism) eliminating the risk of
experimenting with SHA-256-based certificate chains.

2. This would encourage quicker deployment of
draft-bmoeller-tls-downgrade-scsv-02.

3. This may (should!) alleviate current concerns of CAs and others
that are already concerned about your proposal.

4. Encouraging server vendors to add support for this option ASAP
reduces the amount of last-minute resistance by website administrators
you will experience when their websites actually start being
negatively impacted.

Cons: This may encourage CAs to keep minting SHA-1 certificates and/or
it may encourage them to mint them with longer validity periods,
whereas they may making a sharper transition to SHA-256 if my
suggestion weren't an option.

Again, I think your proposal is great. I hope you find these
suggestions helpful.

Cheers,
Brian

[1] http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-02 on
the server

[Ryan Sleevi]

On Fri, Aug 22, 2014 at 8:23 PM, Brian Smith <br...@briansmith.org> wrote:

On Tue, Aug 19, 2014 at 9:52 PM, Ryan Sleevi <rsl...@chromium.org> wrote:
> The following changes to Chromium's handling of SHA-1 are proposed:

[snip]

I think this is a very cool proposal.

It seems like the proposal only deals with SHA-1 signatures used in
certificates' signatures, but it doesn't say anything about SHA-1 use
in the signatures of the TLS ServerKeyExchange message. It may be
useful to say what, if anything, you are planning to do change
regarding SHA-1- or SHA-1+MD5- signed ServerKeyExchange messages, and
on what timeline.

When we have something to say, we'll say it :)

The biggest focus right now is on certificates.

 

Similarly, it would be interesting to here your
plans, if any, regarding changing the values delivered in the TLS
signature_algorithms extension to advertise that SHA-1 is no longer
supported. Note, in particular, that SHA-1(+MD5) signatures MUST be
used in TLS 1.1 and earlier, so potentially there could be
version-specific policies regarding this. And, also note that even TLS
1.2 (weakly) encourages SHA-1 to be used for signatures when the
server certificate's keypair is a DSA keypair.

Yeah, luckily the number of (valid) DSA certificates is extremely low. If I recall the data from 2013 correctly, it was on the order of 'several hundred', although this could easily be confirmed by the CT logs.

Thanks for explicitly mentioning this, Brian, and the kind words of support for this.

In talking with several large CDNs - which operate a non-trivial chunk of these long-lived SHA-1 certs - this exact solution had been brought up, and it seems to be universally agreed that this is a viable plan for them - or at least, those that support TLS 1.2 :)

As you note, by using TLS 1.2 as an appropriate signal, a CA can detect an modern, secure client and deliver to them a proper certificate (i.e. one that is not at risk of breaking soon). This helps accomplish the primary goal of seeing SHA-1 certificates no longer in use on the Web by 2017. CAs that continue to issue these - which the Baseline Requirements implicitly support, though actively discourage - will only be placing clients at risk that do not support TLS 1.2 / SHA-256, and such clients already have a myriad of problems.

I tried to keep the suggested mitigations on the simpler side, in order to favour the long-tail of site operators who are not capable of deploying parallel certificates (RSA & ECDSA, SHA-1 and SHA-256, etc). This is because common off the shelf server software makes this fairly tricky. However, many CDNs already support this capability though, precisely to support ECDSA rollouts.

For those wondering how to implement this, OpenSSL 1.0.2+ (as an example) exposes SSL_set_cert_cb precisely to support this - see the man pages ( https://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=doc/ssl/SSL_CTX_set_cert_cb.pod;hb=3aac17a82fbaf2bc23ee62f24611e5883d3e7b97#l51 )

[David Benjamin]

On Fri, Aug 22, 2014 at 11:43 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

Yeah, luckily the number of (valid) DSA certificates is extremely low. If I recall the data from 2013 correctly, it was on the order of 'several hundred', although this could easily be confirmed by the CT logs.

UMA stats also suggest that the DSA cipher suites are all but unused. (We advertise one with NSS and four with OpenSSL. All of them added together still round to 0.00%.) BoringSSL currently doesn't even implement them anymore.

David 

[Doug Beattie]

Ryan,

We all agree with firm dates for deprecating SHA-1 and moving to SHA-2, but the logic and dates Google has specified give web site operators little time to react.

On Thursday, August 21, 2014 5:09:13 PM UTC-4, Ryan Sleevi wrote:

<clip>

This UI policy has the effect of encouraging site operators and CAs to work towards a migration sooner (by 2016/1/1), rather than waiting until the last possible second (2017/1/1). For those that do choose to wait until the last possible second, they're at least consciously aware that they're doing so, and prepared for the 2017/1/1 shutdown date.

Unfortunately, the  Google approach retroactively punishes web site owners vs. working towards a migration.  A more team friendly approach would be to allow all stakeholders to have sufficient time before the user community is presented with confusing UI changes.  If we want to accelerate the Microsoft announced "cliff" dates by a year (or more), then we should work together on a plan that allows website owners to make the necessary changes, vs. one company making a unilateral industry decision.

While Google currently has systems established to rotate their SHA-1 certificates every 3 months, provisioning 3-month certificates is not as automated for the general user community.  The policy taken my Google appears to be self-serving in that there is no impact to the Google CA and issuance process until a year from now while all web site operators are impacted in 12 weeks.  In order to avoid these undesirable UI displays, all CAs and web site operators must start consuming only SHA-2 certificates by 1/1/2015, or, set up unique systems, processes and pricing to enable the issuance of SHA-1 certificates that are valid for less than a year.  This effectively brings in the Microsoft date in by 2 years, with 12-weeks notice.

If we're going to work together towards a migration milestone on 2016/01/01, then I recommend, at a minimum, that the Chromium logic be updated to look at the certificate issuance date.  This would allow Google, Microsoft, the CAs, and other interested parties to get the word out about the upcoming deadlines.  It also puts us all on the same playing field with respect to conversion.  While there will be some SHA-1 certificates issued that extend into 2017, CAs and web site operators have procedures in place that allow re--issuing the certificates quickly and easily.  It's not necessary to get the stick out 2 years before the cliff date.

The general industry consensus is that 1 January change dates should be avoided as this line up with system lock-down periods and can be confused with calendar year related changes. A March 31 date would be preferable.

To make matters worse, those sites that do not understand the change and resulting UI behavior will not realize this until the holiday shopping season has started and many sites are in lock-down.  The timing could not be worse.

 <clip>

The net-effective of this deprecation policy is:

Site operators MUST *be prepared and aware* of the need to transition to SHA-256 by 2017/1/1

Agree, we're onboard with this date.

 

Site operators SHOULD *be prepared and aware* of the need to transition to SHA-256 by 2016/1/1. This is important, because in the event of a need to reissue a certificate (e.g. for another Heartbleed-like event, as hopefully unlikely as that may be), that is the ONLY type of the certificate they can legitimately acquire.

Communication from CAs and Google is making it's way down to the user communities and web site operators.  Here at GlobalSign we've been sending out notices and updates and we've been actively pushing SHA-2 SSL certificates for the last 5 months, and the pressure and education will continue to increase in urgency and frequency.  Transitioning to SHA-2 issuance and use by 1/1/2016, a year prior to the Microsoft "cliff" date is still going to be a challenge, but is certainly more achievable than replacing all 2-year SHA-1 certificates on the net in the next 12 weeks and moving exclusively to SHA-2 issuance in 4 months.

 

Our end goal with this is to ensure that no user's browsing experience is disrupted in 2016 or 2017, because the Internet will have transitioned away.

This end goal is contradictory to the proposal above.  The browsing experience WILL be disrupted (in 2014) by new, non-intuitive UI changes that make Non-Google sites appear untrusted while still enabling Google to continue to use SHA-1 certificates and appear "more" trusted. 

My recommendation is to:

- Display informational type info (like is done today for CT) in 12 weeks for ALL SHA-1 certificates, including those issued by Google

- Display the first level UI notice starting on 1/1/2016 with certificates issued as of that date, or later

- Display the second level of UI starting 6/1/2016 based on certificate expiration dates

Doug Beattie

VP Product Management, GlobalSign Inc.

doug.b...@globalsign.com

 

[Ryan Sleevi]

On Aug 25, 2014 7:03 AM, "Doug Beattie" <douglas...@gmail.com> wrote:
>
> Ryan,
>
> We all agree with firm dates for deprecating SHA-1 and moving to SHA-2, but the logic and dates Google has specified give web site operators little time to react.
>

Doug,

It seems extremely misleading to suggest 9 months is insufficient time.

Let's be clear: we both know that there are CAs that actively campaigned for 2017 as unrealistic, and instead have (and in some cases, continue to) argue for 2020 or later.

This is such a common occurrence that it continues to delay or prevent any meaningful improvements to online security.

Regarding proposals for examining notBefore as an issuance date - as you know, this fails to meaningfully address any of the security concerns. We have discussed in the CA/Browser Forum why it doesn't work, and it's been discussed above why it doesn't work - in particular, CAs are not required to be honest in them, and in the vast majority of cases, are not honest in them. Using information like this for security decisions fails to consider that reality.

While I appreciate your alternative proposal, for reasons that were explained six months ago, and reasons explained earlier on this thread, that timeline doesn't align with the goal, and just serves to kick this exact same conversation of "not enough time / not enough warning" down the road.

What I haven't seen is any dispute to the following:
- By 2016/1/1, CAs may no longer issue SHA-1 certificates. Sites which rely on these certificates (e.g. for XP SP2) WILL NOT be able to obtain any new certificates, WILL NOT be able to respond to security incidents, and WILL NOT be able to make any changes or correct any information.
- By 2017/1/1, these sites WILL NOT work.

If we did as you'd propose, the 2016 users will have zero warning, and the 2017 users will have less than a year, and we would be having this exact same conversation about not enough time and proposing delays. What's worse, it would have the exact effect we are trying to avoid, of having 2017 be a flag day.

To be clear, in 2017/1/1, these certificates will not work. It is not a degraded UI (as you proposed), but an indistinguishable from untrusted certificate. This is significant enough to merit advance communication - which this deprecation notice is.

I don't mean this as a hypothetical - we very much saw this play out for 5 years with MD5, as CAs continued to suggest SHA-1 wasn't needed, and mitigations like entropy in the serial was sufficient.

In this proposal, no penalties are being taken against the CA. No CA is being found in violation of our root or EV policies, and no CA is risking removal wholesale. This is merely a UI update, one which doesn't require user action, that reflects the security views and best practices, which, again, CAs agreed upon and recognized this view as far back as 2011.

This is fundamentally no different than Chrome using UI to communicate other insecure CA practices that, despite every effort, continue to be used well beyond when it is safe. For example, the insecure inclusion of unverifiable domain names (also called internal server names), which has caused significant risk to the CA's users - and the Internet at large - as ICANN delegates new TLDs. Indeed, many of these same discussions were had, and worse, the timelines continually attempted to be pushed back or altogether dismissed.

It is important that Chrome, for which security has been a foundational pillar of the design, accurately and honestly reflect the security status of the page. The exact details are generally left to our security and UX teams, which have seen this as a reasonable balance between requiring the user to take direct action (via a security interstitial) and the misleading and downright status quo - of doing nothing.

[rowl...@gmail.com]

What I haven't seen is any dispute to the following:
- By 2016/1/1, CAs may no longer issue SHA-1 certificates. Sites which rely on these certificates (e.g. for XP SP2) WILL NOT be able to obtain any new certificates, WILL NOT be able to respond to security incidents, and WILL NOT be able to make any changes or correct any information.
- By 2017/1/1, these sites WILL NOT work.

[JR] You don't see a dispute because everyone has already accepted and, for the most part, support these as the dates when SHA1 will be deprecated. As previously mentioned has mentioned, the issue is with accelerating the deprecation to 12 weeks from now.

If we did as you'd propose, the 2016 users will have zero warning, and the 2017 users will have less than a year, and we would be having this exact same conversation about not enough time and proposing delays. What's worse, it would have the exact effect we are trying to avoid, of having 2017 be a flag day.

[JR] Why would 2016 users need a warning? The certs are still valid in 2016. Customers of CAs are getting warnings that they can't get SHA1 as of 2016. You just aren't seeing the warnings since Google has its own CA. All of the major CAs are trying to help their current customers transition to SHA2, including providing alerts that they need to transition before 2017.

To be clear, in 2017/1/1, these certificates will not work. It is not a degraded UI (as you proposed), but an indistinguishable from untrusted certificate. This is significant enough to merit advance communication - which this deprecation notice is.

[JR] Right, but your plan includes placing warnings on certs that are not valid in 2017. Why the advanced communication on certificates that are going to expire in 2016?

This is fundamentally no different than Chrome using UI to communicate other insecure CA practices that, despite every effort, continue to be used well beyond when it is safe. For example, the insecure inclusion of unverifiable domain names (also called internal server names), which has caused significant risk to the CA's users - and the Internet at large - as ICANN delegates new TLDs. Indeed, many of these same discussions were had, and worse, the timelines continually attempted to be pushed back or altogether dismissed.

[JR] I think the internal name deprecation issue is a good example of how CAs worked with ICANN to balance the need for a rapid deprecation with the need to transition customers over to FQDNs. 120 days for deprecation is not a long period of time.

It is important that Chrome, for which security has been a foundational pillar of the design, accurately and honestly reflect the security status of the page. The exact details are generally left to our security and UX teams, which have seen this as a reasonable balance between requiring the user to take direct action (via a security interstitial) and the misleading and downright status quo - of doing nothing.

[JR] For the 2017 certs, I think the approach is reasonable, although 12 weeks is a pretty short notice of the action. Still, I agree CAs had notice that 2017 was the cutoff for SHA1 functionality. However, the warning for 2016 certs was definitely a surprise.

[Doug Beattie]

Ryan,

I'm not sure where the 9 month date is coming from, my read is that in 12 weeks users will be impacted with a new UI raising some concern about the trust or security of their connection.  They've been tortured enough recently.  I don't see any milestones in 9 months.  While mixed content pages have serious security issues, it's not obvious to me why commercial CA SHA-1 certificates fall into this category (and, by the way, Google issued SHA-1 certificates do not).  ALL SHA-1 certificates should be treated the same regardless of when they expire.  Creating a loop-hole for Google issued SSL seems sneaky - even though you are publically disclosing the rules.

More responses below.

On Monday, August 25, 2014 10:38:55 AM UTC-4, Ryan Sleevi wrote:

On Aug 25, 2014 7:03 AM, "Doug Beattie" <douglas...@gmail.com> wrote:
>
> Ryan,
>
> We all agree with firm dates for deprecating SHA-1 and moving to SHA-2, but the logic and dates Google has specified give web site operators little time to react.
>

Doug,

It seems extremely misleading to suggest 9 months is insufficient time.

Let's be clear: we both know that there are CAs that actively campaigned for 2017 as unrealistic, and instead have (and in some cases, continue to) argue for 2020 or later.

Microsoft specified 1/1/2017 as a critical date and I believe we're all working towards that date - CAs, Web site operators, browsers and OS vendors.  I'm not aware of anyone asking for 2020 or later and agree with you that 2017 is a solid date.

This is such a common occurrence that it continues to delay or prevent any meaningful improvements to online security.

Regarding proposals for examining notBefore as an issuance date - as you know, this fails to meaningfully address any of the security concerns. We have discussed in the CA/Browser Forum why it doesn't work, and it's been discussed above why it doesn't work - in particular, CAs are not required to be honest in them, and in the vast majority of cases, are not honest in them. Using information like this for security decisions fails to consider that reality. 

While I appreciate your alternative proposal, for reasons that were explained six months ago, and reasons explained earlier on this thread, that timeline doesn't align with the goal, and just serves to kick this exact same conversation of "not enough time / not enough warning" down the road.

We have been working to the 1/1/2017 date and I don't advocate kicking that down the road.  But, your proposal just kicked the can "up the road" over 2 years.  If this had been proposed last year then there would have been more time to align issuance updates with these new requirements, but with only 12 weeks until the untrusted UI goes into affect there is very little time for the industry to react.  Web site operators have established certain processes to obtain and install certificates which are difficult to change.  Those that cannot change stand to loose customers and money.  As a CA, we're ready to issue replacement certificates, but not all customers are prepared to swap over to SHA-2.

What I haven't seen is any dispute to the following:
- By 2016/1/1, CAs may no longer issue SHA-1 certificates. Sites which rely on these certificates (e.g. for XP SP2) WILL NOT be able to obtain any new certificates, WILL NOT be able to respond to security incidents, and WILL NOT be able to make any changes or correct any information.

If this is the MS set of requirements, I read "MAY" as optional (vs Shall or Must).  There will be reasons to replace (issue) SHA-1 certificates during the last year of their support, but I expect most, or all, CAs will have removed SHA-1 ordering of new certificates before 2016.

- By 2017/1/1, these sites WILL NOT work.

This is the date we've all been working towards, agree.  SSL certificates that are issued under publically trusted roots will not work.  Having a set of UI changes leading up to this is also highly desirable, I just disagree with starting this over 2 years ahead of time with rather confusing UI experience about the trustworthiness of the site.

If we did as you'd propose, the 2016 users will have zero warning, and the 2017 users will have less than a year, and we would be having this exact same conversation about not enough time and proposing delays. What's worse, it would have the exact effect we are trying to avoid, of having 2017 be a flag day.

Perhaps you misread my suggestions.  I recommend that the "untrusted UI" updates could be applied one year after you're current plan and only react to those certificates that were issued on or after 1/1/2016 (assuming there are no new advanced in the preimage attacks).  Then, in mid-2016 you implement your checks you had scheduled for 1/1/2016 (5 months delay).  I don't think this is an unreasonable request.

 

To be clear, in 2017/1/1, these certificates will not work. It is not a degraded UI (as you proposed), but an indistinguishable from untrusted certificate. This is significant enough to merit advance communication - which this deprecation notice is.

Sure, that aligns with Microsoft and their behavior.  I have no issues with that date.

 

I don't mean this as a hypothetical - we very much saw this play out for 5 years with MD5, as CAs continued to suggest SHA-1 wasn't needed, and mitigations like entropy in the serial was sufficient.

In this proposal, no penalties are being taken against the CA. No CA is being found in violation of our root or EV policies, and no CA is risking removal wholesale. This is merely a UI update, one which doesn't require user action, that reflects the security views and best practices, which, again, CAs agreed upon and recognized this view as far back as 2011.

This is fundamentally no different than Chrome using UI to communicate other insecure CA practices that, despite every effort, continue to be used well beyond when it is safe. For example, the insecure inclusion of unverifiable domain names (also called internal server names), which has caused significant risk to the CA's users - and the Internet at large - as ICANN delegates new TLDs. Indeed, many of these same discussions were had, and worse, the timelines continually attempted to be pushed back or altogether dismissed.

It is important that Chrome, for which security has been a foundational pillar of the design, accurately and honestly reflect the security status of the page. The exact details are generally left to our security and UX teams, which have seen this as a reasonable balance between requiring the user to take direct action (via a security interstitial) and the misleading and downright status quo - of doing nothing.

I think it's misleading to design a set of requirements and migration plans which impact everyone in the industry except Google for this issuance of SHA-1 certificates.  The bar should be set at the same level for all CAs and web site operators, but the proposed approach impacts everyone except Google for the next year. 

Doug

[Ryan Sleevi]

On Aug 25, 2014 8:42 AM, "Doug Beattie" <douglas...@gmail.com> wrote:
>
> Ryan,
>

> I'm not sure where the 9 month date is coming from, my read is that in 12 weeks users will be impacted with a new UI raising some concern about the trust or security of their connection. 

CAs were told about this 6 months ago.

> They've been tortured enough recently.  I don't see any milestones in 9 months.  While mixed content pages have serious security issues, it's not obvious to me why commercial CA SHA-1 certificates fall into this category (and, by the way, Google issued SHA-1 certificates do not).  ALL SHA-1 certificates should be treated the same regardless of when they expire.  Creating a loop-hole for Google issued SSL seems sneaky - even though you are publically disclosing the rules.
>

I think its best to let the original message, which laid out precisely what the motivations are, show how this statement is neither productive nor accurate.

> More responses below.
>
> On Monday, August 25, 2014 10:38:55 AM UTC-4, Ryan Sleevi wrote:
>>
>>
>> On Aug 25, 2014 7:03 AM, "Doug Beattie" <douglas...@gmail.com> wrote:
>> >
>> > Ryan,
>> >
>> > We all agree with firm dates for deprecating SHA-1 and moving to SHA-2, but the logic and dates Google has specified give web site operators little time to react.
>> >
>>
>> Doug,
>>
>> It seems extremely misleading to suggest 9 months is insufficient time.
>>
>> Let's be clear: we both know that there are CAs that actively campaigned for 2017 as unrealistic, and instead have (and in some cases, continue to) argue for 2020 or later.
>
> Microsoft specified 1/1/2017 as a critical date and I believe we're all working towards that date - CAs, Web site operators, browsers and OS vendors.  I'm not aware of anyone asking for 2020 or later and agree with you that 2017 is a solid date.

You can find both in the minutes and then the Forum archives proposals to effect of what you've suggest here - that is, if any cert is valid on 2015/12/31 with SHA-1, that it be allowed to 'live out' its maximally issued life (of 39 months, or 60 months if issued before 2015/4/1)

>
>> This is such a common occurrence that it continues to delay or prevent any meaningful improvements to online security.
>>
>> Regarding proposals for examining notBefore as an issuance date - as you know, this fails to meaningfully address any of the security concerns. We have discussed in the CA/Browser Forum why it doesn't work, and it's been discussed above why it doesn't work - in particular, CAs are not required to be honest in them, and in the vast majority of cases, are not honest in them. Using information like this for security decisions fails to consider that reality. 
>>
>> While I appreciate your alternative proposal, for reasons that were explained six months ago, and reasons explained earlier on this thread, that timeline doesn't align with the goal, and just serves to kick this exact same conversation of "not enough time / not enough warning" down the road.
>
> We have been working to the 1/1/2017 date and I don't advocate kicking that down the road.  But, your proposal just kicked the can "up the road" over 2 years.  If this had been proposed last year then there would have been more time to align issuance updates with these new requirements, but with only 12 weeks until the untrusted UI goes into affect there is very little time for the industry to react.

This was proposed and discussed 6 months ago, in a meeting you were recorded as present in ( https://cabforum.org/2014/02/19/2014-02-19-minutes-of-mountain-view-f2f/ ) and noted as participating in. I think it is worth noting the participation recorded was opposition towards requirements that would have had CAs communicating this sunset to their users, by forcing their expiration date be meaningfully set, rather than require UAs to do so.

>  Web site operators have established certain processes to obtain and install certificates which are difficult to change.  Those that cannot change stand to loose customers and money.  As a CA, we're ready to issue replacement certificates, but not all customers are prepared to swap over to SHA-2.

And, as you read from my original message (and Brian Smith's excellent followup), your customers are not being required to immediately swap to SHA-256.

>
>> What I haven't seen is any dispute to the following:
>> - By 2016/1/1, CAs may no longer issue SHA-1 certificates. Sites which rely on these certificates (e.g. for XP SP2) WILL NOT be able to obtain any new certificates, WILL NOT be able to respond to security incidents, and WILL NOT be able to make any changes or correct any information.
>
> If this is the MS set of requirements, I read "MAY" as optional (vs Shall or Must).  There will be reasons to replace (issue) SHA-1 certificates during the last year of their support, but I expect most, or all, CAs will have removed SHA-1 ordering of new certificates before 2016.

The Microsoft language includes no such provision, nor has it.

http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx

"CAs must stop issuing new SHA1 SSL and Code Signing end-entity certificates by 1 January 2016."

Note the must.

>
>> - By 2017/1/1, these sites WILL NOT work.
>
> This is the date we've all been working towards, agree.  SSL certificates that are issued under publically trusted roots will not work.  Having a set of UI changes leading up to this is also highly desirable, I just disagree with starting this over 2 years ahead of time with rather confusing UI experience about the trustworthiness of the site.
>

And the Mozilla Root Program shows that 2 years is often insufficient time for CAs to be relied upon communicate with their users. Mozilla has been attempting to remove 1024-bit certs for FIVE YEARS now. If you read through https://bugzilla.mozilla.org/show_bug.cgi?id=881553 and related, you will see that there is, for a variety of CAs, a long tail of consumers they cannot reach, and for who the CA's inability (or, in some cases, unwillingness) to communicate with leaves a large majority of Internet users at risk.

>> If we did as you'd propose, the 2016 users will have zero warning, and the 2017 users will have less than a year, and we would be having this exact same conversation about not enough time and proposing delays. What's worse, it would have the exact effect we are trying to avoid, of having 2017 be a flag day.
>
> Perhaps you misread my suggestions.  I recommend that the "untrusted UI" updates could be applied one year after you're current plan and only react to those certificates that were issued on or after 1/1/2016 (assuming there are no new advanced in the preimage attacks).  Then, in mid-2016 you implement your checks you had scheduled for 1/1/2016 (5 months delay).  I don't think this is an unreasonable request.

I hope the above discussion will highlight how it is.

As you have again confused the dates, there will NOT be any new certificates issued with SHA-1 after 2016/1/1. These will be hard errors AND a violation of the respective root policies, which may lead to action to protect the user from such CAs as a whole. I want to make sure this is unambiguous here, though its been repeated several times.

As you well know, this would encourage and permit SHA-1 certificates, issued at 39 months validity, being issued up until 2016/12/31. That would leave such users 5 months to transition. The discussion we are having right now is that three months isn't enough to transition (during a period where this transition can functionally last over a year), but you're proposing a five month transition with absolutely no ability to extend.

I'm sure and hope you can see the risk your proposal would leave users at, and the harm it would cause.

[wgo...@gmail.com]

Hi,

Sorry how are you reaching the conclusion that Google is treating its own SHA-1 certificates differently than those issued by public CAs?

Ryan, for what it's worth a bit ++1 to your proposal.

Walter

[Ryan Sleevi]

That was supposed to read "being issued up until 2015/12/31" (the last valid issuance date). The rest is still correct - that is, delaying warning until mid-2016 still leaves users only 5 months to transition certs they may have received as recently as 6 months ago, with no possible recourse.

It also leaves ISVs and interception devices 5 months to transition their users, which we know is often insufficient, and, as noted in the original thread, part of the motivation (based on experience with MD5 deprecation). That is, 18 months to deprecate SHA-1 if you're an owner of an anti-virus or traffic inspection device is, often, a MINIMUM. (6 months for the vendor to implement the changes and release them, then ~12 months for customers to upgrade and deploy).

So it's not just CAs that are being targeted with this deprecation, which is why there is such a necessarily long lead-up.

[Brian Smith]

On Fri, Aug 22, 2014 at 8:43 PM, Ryan Sleevi <rsl...@chromium.org> wrote:
> On Fri, Aug 22, 2014 at 8:23 PM, Brian Smith <br...@briansmith.org> wrote:
>> It seems like the proposal only deals with SHA-1 signatures used in
>> certificates' signatures, but it doesn't say anything about SHA-1 use
>> in the signatures of the TLS ServerKeyExchange message. It may be
>> useful to say what, if anything, you are planning to do change
>> regarding SHA-1- or SHA-1+MD5- signed ServerKeyExchange messages, and
>> on what timeline.
>
> When we have something to say, we'll say it :)
>
> The biggest focus right now is on certificates.

Understood. My understanding is that, at least one point in time,
Chrome on non-SP3 Windows XP would advertise that it supports SHA-2
signatures in the signature_algorithms extension, even though it
doesn't support SHA-2 signatures on certificates on non-SP3 Windows
XP. This is why I see all of these issues as being inter-related. In
particular, using the mechanism I described to support SHA-1
certificates for non-SHA-2-capable clients while giving SHA-2-capable
clients SHA-2 certificates doesn't work well when the
signature_algorithms extension overstates the client's capabilities.

> Yeah, luckily the number of (valid) DSA certificates is extremely low. If I
> recall the data from 2013 correctly, it was on the order of 'several
> hundred', although this could easily be confirmed by the CT logs.

FWIW, Firefox's measurements also show that DSA is almost totally unused.

> I tried to keep the suggested mitigations on the simpler side, in order to
> favour the long-tail of site operators who are not capable of deploying
> parallel certificates (RSA & ECDSA, SHA-1 and SHA-256, etc). This is because
> common off the shelf server software makes this fairly tricky. However, many
> CDNs already support this capability though, precisely to support ECDSA
> rollouts.
>
> For those wondering how to implement this, OpenSSL 1.0.2+ (as an example)
> exposes SSL_set_cert_cb precisely to support this - see the man pages (
> https://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=doc/ssl/SSL_CTX_set_cert_cb.pod;hb=3aac17a82fbaf2bc23ee62f24611e5883d3e7b97#l51
> )

Understood. I think a lot of the risk of last-minute resistance would
be mitigated if Apache, nginx, IIS, and other (origin) web server
software made this easy to configure. I am not sure if it is practical
to update those products to add this capability within window in which
it would be useful, however. Perhaps too little, too late.

Cheers,
Brian

[Peter Bowen]

On Mon, Aug 25, 2014 at 11:52 AM, Ryan Sleevi <rsl...@chromium.org> wrote:
>
> It also leaves ISVs and interception devices 5 months to transition their
> users, which we know is often insufficient, and, as noted in the original
> thread, part of the motivation (based on experience with MD5 deprecation).
> That is, 18 months to deprecate SHA-1 if you're an owner of an anti-virus or
> traffic inspection device is, often, a MINIMUM. (6 months for the vendor to
> implement the changes and release them, then ~12 months for customers to
> upgrade and deploy).
>
> So it's not just CAs that are being targeted with this deprecation, which is
> why there is such a necessarily long lead-up.

Does this imply that there will not be an exception for certificates
issued by CAs that users add to the trust list? Today Chrome gives
these CAs some special handling (for example not checking pinning
rules).

Thanks,
Peter

[Ryan Sleevi]

Correct. 

[Ryan Sleevi]

On Mon, Aug 25, 2014 at 12:03 PM, Brian Smith <br...@briansmith.org> wrote:

On Fri, Aug 22, 2014 at 8:43 PM, Ryan Sleevi <rsl...@chromium.org> wrote:
> On Fri, Aug 22, 2014 at 8:23 PM, Brian Smith <br...@briansmith.org> wrote:

>> It seems like the proposal only deals with SHA-1 signatures used in
>> certificates' signatures, but it doesn't say anything about SHA-1 use
>> in the signatures of the TLS ServerKeyExchange message. It may be
>> useful to say what, if anything, you are planning to do change
>> regarding SHA-1- or SHA-1+MD5- signed ServerKeyExchange messages, and
>> on what timeline.
>
> When we have something to say, we'll say it :)
>
> The biggest focus right now is on certificates.

Understood. My understanding is that, at least one point in time,
Chrome on non-SP3 Windows XP would advertise that it supports SHA-2
signatures in the signature_algorithms extension, even though it
doesn't support SHA-2 signatures on certificates on non-SP3 Windows
XP. This is why I see all of these issues as being inter-related. In
particular, using the mechanism I described to support SHA-1
certificates for non-SHA-2-capable clients while giving SHA-2-capable
clients SHA-2 certificates doesn't work well when the
signature_algorithms extension overstates the client's capabilities.

The error page today for XP SP2 users already directs them to install SP3.

I also suspect we will "butterbar" these SP2 users, similar to how we have notified users who have failed to install recent/updated versions of Chrome or when they're running an older version of an OS that has known security issues.

[Brian Smith]

I think those are good measures. However, if CDNs and others are going
to jump through hoops to keep supporting non-SHA-2-capable clients
while doing the right thing for SHA-2-capable clients, then it seems
like we would need to document a technique that doesn't make the
decision over which cert chain to use (soley) based on the contents of
the signature_algorithms extension.

I know that some people within the TLS WG are also aware of the need
to differentiate between the signature algorithms supported during
certificate chain verification vs. the signature algorithms supported
in signed TLS structures and presumably people are working on a
solution for that. This is a good indication that such a solution
should probably be backported to earlier versions of TLS.

I don't know how big the Chrome-on-XP-SP2 userbase is. It seems like
it is large enough that the Chrome team (list like, IIRC, the Firefox
team does for Firefox-on-XP-SP2) feels justified in continuing to
supporting them indefinitely. It seems like websites also will want to
support those users too, but it seems like how to do that is still an
unsolved problem.

Cheers,
Brian