Intent to Deprecate: SHA-1 certificates

5.980 visualizações
Pular para a primeira mensagem não lida

Ryan Sleevi

não lida,
20 de ago. de 2014, 00:52:4820/08/2014
para blink-dev, security-dev, net-dev

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 (陈智昌)

não lida,
20 de ago. de 2014, 18:45:5720/08/2014
para Ryan Sleevi, blink-dev, security-dev, net-dev
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

não lida,
20 de ago. de 2014, 20:50:1520/08/2014
para blin...@chromium.org, securi...@chromium.org, net...@chromium.org, rsl...@chromium.org
"(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

não lida,
21 de ago. de 2014, 05:25:2621/08/2014
para William Chan (陈智昌), Ryan Sleevi, blink-dev, security-dev, net-dev
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

não lida,
21 de ago. de 2014, 15:00:4321/08/2014
para securi...@chromium.org, blin...@chromium.org, net...@chromium.org, rsl...@chromium.org
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

não lida,
21 de ago. de 2014, 16:28:0921/08/2014
para securi...@chromium.org, blin...@chromium.org, net...@chromium.org, rsl...@chromium.org
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

não lida,
21 de ago. de 2014, 17:09:1721/08/2014
para Bruce Morton, security-dev, blink-dev, net-dev, 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

não lida,
21 de ago. de 2014, 21:48:2221/08/2014
para securi...@chromium.org, blin...@chromium.org, net...@chromium.org, rsl...@chromium.org
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

não lida,
21 de ago. de 2014, 22:39:0321/08/2014
para rsl...@chromium.org, blink-dev, security-dev, net-dev
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

não lida,
22 de ago. de 2014, 00:01:3222/08/2014
para robin...@gmail.com, security-dev, blink-dev, net-dev, 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

não lida,
22 de ago. de 2014, 00:07:2322/08/2014
para Lucas Garron, Ryan Sleevi, blink-dev, security-dev, net-dev
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

não lida,
22 de ago. de 2014, 06:52:2222/08/2014
para Ryan Sleevi, Lucas Garron, blink-dev, security-dev, net-dev
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

não lida,
22 de ago. de 2014, 09:04:2622/08/2014
para securi...@chromium.org, bruce....@entrust.com, blin...@chromium.org, net...@chromium.org, rsl...@chromium.org
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

não lida,
22 de ago. de 2014, 11:05:4622/08/2014
para Bruce Morton, net-dev, security-dev, blin...@chromium.org

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

não lida,
22 de ago. de 2014, 12:55:2922/08/2014
para securi...@chromium.org, blin...@chromium.org, net...@chromium.org, rsl...@chromium.org
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

não lida,
22 de ago. de 2014, 13:11:4222/08/2014
para b...@digicert.com, net-dev, security-dev, blin...@chromium.org


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

não lida,
22 de ago. de 2014, 13:25:3322/08/2014
para Ryan Sleevi, Lucas Garron, blink-dev, security-dev, net-dev
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

não lida,
22 de ago. de 2014, 13:31:3022/08/2014
para securi...@chromium.org, robin...@gmail.com, blin...@chromium.org, net...@chromium.org, rsl...@chromium.org
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

não lida,
22 de ago. de 2014, 13:39:2722/08/2014
para tshi...@trustwave.com, net-dev, security-dev, blin...@chromium.org, robin...@gmail.com

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

não lida,
22 de ago. de 2014, 13:59:0422/08/2014
para securi...@chromium.org, b...@digicert.com, net...@chromium.org, blin...@chromium.org, rsl...@chromium.org

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

não lida,
22 de ago. de 2014, 15:11:3222/08/2014
para securi...@chromium.org, blin...@chromium.org, net...@chromium.org, rsl...@chromium.org
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

não lida,
22 de ago. de 2014, 15:18:2922/08/2014
para ni...@cloudflare.com, security-dev, blin...@chromium.org, net-dev, Ryan Sleevi
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.

Ryan Sleevi

não lida,
22 de ago. de 2014, 15:19:0122/08/2014
para ni...@cloudflare.com, net-dev, security-dev, blin...@chromium.org

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

não lida,
22 de ago. de 2014, 15:37:2322/08/2014
para rsl...@chromium.org, net-dev, security-dev, blin...@chromium.org
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

não lida,
22 de ago. de 2014, 15:49:0022/08/2014
para Nick Sullivan, Ryan Sleevi, net-dev, security-dev, blink-dev
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

não lida,
22 de ago. de 2014, 16:00:1022/08/2014
para securi...@chromium.org, ni...@cloudflare.com, net...@chromium.org, blin...@chromium.org, rsl...@chromium.org
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

não lida,
22 de ago. de 2014, 16:05:2322/08/2014
para rowl...@gmail.com, Nick Sullivan, net-dev, securi...@chromium.org, blin...@chromium.org

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

não lida,
22 de ago. de 2014, 17:55:2122/08/2014
para securi...@chromium.org, blin...@chromium.org, net...@chromium.org, rsl...@chromium.org

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

não lida,
22 de ago. de 2014, 17:58:4522/08/2014
para securi...@chromium.org, blin...@chromium.org, net...@chromium.org, rsl...@chromium.org
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

não lida,
22 de ago. de 2014, 18:20:2922/08/2014
para Jeremy Rowley, security-dev, blink-dev, net-dev, 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 UIwhich 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

não lida,
22 de ago. de 2014, 18:32:2222/08/2014
para securi...@chromium.org, blin...@chromium.org, net...@chromium.org, rsl...@chromium.org
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

não lida,
22 de ago. de 2014, 23:23:4722/08/2014
para Ryan Sleevi, blink-dev, security-dev, net-dev
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

não lida,
22 de ago. de 2014, 23:43:0622/08/2014
para Brian Smith, Ryan Sleevi, blink-dev, security-dev, net-dev
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

não lida,
23 de ago. de 2014, 00:07:4223/08/2014
para Ryan Sleevi, Brian Smith, blink-dev, security-dev, net-dev
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

não lida,
25 de ago. de 2014, 10:03:1025/08/2014
para securi...@chromium.org, bruce....@entrust.com, blin...@chromium.org, net...@chromium.org, rsl...@chromium.org

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.


 

Ryan Sleevi

não lida,
25 de ago. de 2014, 10:38:5825/08/2014
para Doug Beattie, net-dev, security-dev, blin...@chromium.org, bruce....@entrust.com


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

não lida,
25 de ago. de 2014, 11:28:2925/08/2014
para securi...@chromium.org, blin...@chromium.org, net...@chromium.org, rsl...@chromium.org
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

não lida,
25 de ago. de 2014, 11:42:0825/08/2014
para securi...@chromium.org, douglas...@gmail.com, net...@chromium.org, blin...@chromium.org, bruce....@entrust.com, rsl...@chromium.org
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

não lida,
25 de ago. de 2014, 12:06:1025/08/2014
para Doug Beattie, net-dev, security-dev, bruce....@entrust.com, blin...@chromium.org


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

não lida,
25 de ago. de 2014, 12:07:0525/08/2014
para securi...@chromium.org, douglas...@gmail.com, net...@chromium.org, blin...@chromium.org, bruce....@entrust.com, rsl...@chromium.org
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

não lida,
25 de ago. de 2014, 14:52:4425/08/2014
para Ryan Sleevi, Doug Beattie, net-dev, security-dev, Bruce Morton, blink-dev
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

não lida,
25 de ago. de 2014, 15:03:4025/08/2014
para Ryan Sleevi, blink-dev, security-dev, net-dev
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

não lida,
25 de ago. de 2014, 15:12:2225/08/2014
para rsl...@chromium.org, Doug Beattie, net-dev, security-dev, Bruce Morton, blink-dev
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

não lida,
25 de ago. de 2014, 18:00:3725/08/2014
para Peter Bowen, Ryan Sleevi, Doug Beattie, net-dev, security-dev, Bruce Morton, blink-dev
Correct. 

Ryan Sleevi

não lida,
25 de ago. de 2014, 18:02:4025/08/2014
para Brian Smith, Ryan Sleevi, blink-dev, security-dev, net-dev
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

não lida,
25 de ago. de 2014, 18:46:1525/08/2014
para Ryan Sleevi, blink-dev, security-dev, net-dev
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

Chris Palmer

não lida,
25 de ago. de 2014, 18:59:4525/08/2014
para Brian Smith, Ryan Sleevi, blink-dev, security-dev, net-dev
On Mon, Aug 25, 2014 at 3:46 PM, Brian Smith <br...@briansmith.org> wrote:

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

Well, what about Twitter? I don't have a sufficiently-old computer to
be sure, but it looks like Twitter uses an EE cert signed with SHA-256
+ RSA.

Maybe Twitter is distinguishing SHA-256 capable vs. non-capable
clients, and serving different chains? Otherwise, a site as important
as Twitter seems to be OK with not working on old platforms.

And if that's true, maybe nobody else needs to care, either? Very few
sites can claim to be a bigger deal than Twitter...

yuhong...@hotmail.com

não lida,
25 de ago. de 2014, 19:06:5425/08/2014
para blin...@chromium.org, br...@briansmith.org, rsl...@chromium.org, securi...@chromium.org, net...@chromium.org
FYI, Twitter on IE8 running on XP SP3 shows a SHA-256 certificate.

yuhong...@hotmail.com

não lida,
25 de ago. de 2014, 19:11:4225/08/2014
para blin...@chromium.org, br...@briansmith.org, rsl...@chromium.org, securi...@chromium.org, net...@chromium.org


On Monday, August 25, 2014 3:02:40 PM UTC-7, Ryan Sleevi wrote:



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.

FYI, "Please update your computer to a more recent version of Windows." is pretty vague. I would have explicitly mentioned that they need to install XP SP3 for XP users or KB2868626 for Server 2003 users.

Peter Bowen

não lida,
25 de ago. de 2014, 19:13:1625/08/2014
para rsl...@chromium.org, Doug Beattie, net-dev, security-dev, Bruce Morton, blink-dev
> Correct.

Non-publicly trusted roots and certs they issue are not currently
subject to key size and requirements, correct? A non-publicly trusted
certificate with a 1024-bit RSA key with a SHA-256 signature will
continue to be accepted by Chrome, right? Is there a lower bound of
accepted key length?

Thanks,
Peter

Ryan Sleevi

não lida,
25 de ago. de 2014, 19:21:3625/08/2014
para Peter Bowen, Ryan Sleevi, Doug Beattie, net-dev, security-dev, Bruce Morton, blink-dev
Chrome rejects MD5 certificates, regardless of source. This was, as I mentioned, a significantly difficult change, both for public CAs (which is truly unfortunate) and for 'security' software that used insecure defaults. It also rejects RSA keys < 1024 bits.

Amusingly, malware authors were the first and fastest to adopt their interception to these new security requirements.

As Chris Palmer noted, over time, Chrome will continue to ratchet up the requirements, hopefully as CAs continue to adopt the practices agreed upon in 2011 in the publication of the Baseline Requirements. SHA-1 is just one, small aspect of this. See his response - https://groups.google.com/a/chromium.org/d/msg/security-dev/2-R4XziFc7A/zeGeKg_IjuYJ 

Håvard Molland

não lida,
26 de ago. de 2014, 05:38:2726/08/2014
para rsl...@chromium.org, blink-dev, security-dev, net-dev
Although we do understand some of the problems this causes for the CAs, Opera fully backs Chromium on this issue. We plan to follow and implement the same behavior.

How does this affect users of the content API?  Will this change be implemented entirely below the content/net APIs using existing security states, such that  all Chromium based browsers and applications automatically inherit the new UI behavior? Or will you implement this on top of the content API in your UI layer?

Thanks,
Håvard

On 20. aug. 2014 06:52, Ryan Sleevi wrote:

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.

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


-- 
---
Opera Software

Ryan Sleevi

não lida,
26 de ago. de 2014, 10:33:3426/08/2014
para Håvard Molland, blink-dev, net-dev, security-dev


On Aug 26, 2014 2:38 AM, "Håvard Molland" <haav...@opera.com> wrote:
>
> Although we do understand some of the problems this causes for the CAs, Opera fully backs Chromium on this issue. We plan to follow and implement the same behavior.
>

Glad to hear.

> How does this affect users of the content API?  Will this change be implemented entirely below the content/net APIs using existing security states, such that  all Chromium based browsers and applications automatically inherit the new UI behavior?

Yes.

> Or will you implement this on top of the content API in your UI layer?

//content embedders will still be able to control or alter this if needed, although like many other security features (like sandboxing), it's not recommended to disable.

benwil...@gmail.com

não lida,
26 de ago. de 2014, 11:25:2626/08/2014
para securi...@chromium.org, rsl...@chromium.org, blin...@chromium.org, net...@chromium.org
On Tuesday, August 26, 2014 3:38:24 AM UTC-6, haavardm at work wrote:
> Although we do understand some of the
> problems this causes for the CAs, Opera fully backs Chromium on
> this issue. We plan to follow and implement the same behavior.
> --
> ---
> Opera Software

Haavard,

When you say that Opera will implement "the same behavior", what does that mean in terms of UX? Will users start seeing a big red X through "https"? Can you point us to the image that will appear as the mini-icon in Opera's address bar? I'm concerned that browsers use passive SSL indicators that are appropriate to the threat level. Just like the US DHS threat level indicators, the color red should be reserved for the most severe threats. Red means prohibited. Orange means high alert. Yellow means guarded. Etc.
http://en.wikipedia.org/wiki/File:Hsas-chart_with_header.svg
This is similar to what was adopted in the 20th century by international road sign standards and for traffic lights - http://en.wikipedia.org/wiki/Vienna_Convention_on_Road_Signs_and_Signals#Traffic_lights.
(Hopefully we won't have to hold an international treaty convention for these road signs.)

Thanks,
Ben

Håvard Molland

não lida,
26 de ago. de 2014, 11:56:4626/08/2014
para benwil...@gmail.com, securi...@chromium.org, blin...@chromium.org, net...@chromium.org
Hi Ben,

"The same behavior" here simply means to adopt the same security levels, not how it is shown to the users. So we will not start to show the red X. In this case we will most likely do what we for for most other SSL issues: We downgrade the UI to no security, which is the same security level as normal http. That is, the site will simply loose the security badge and the same icon that used for http will be shown.

Cheers,
Håvard

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


--
---
Opera Software

rick_a...@symantec.com

não lida,
26 de ago. de 2014, 17:58:3426/08/2014
para securi...@chromium.org, blin...@chromium.org, net...@chromium.org, rsl...@chromium.org
Symantec agrees with other CAs that the industry needs to phase out the use of SHA-1 in certificates, and we, like all other CAs that have commented, have been offering SHA-2 certs to our customers for some time now. Our concern about Google’s proposal is in regards to the disruption we feel it will cause for thousands of web site operators.

We’ve all been working towards the deadlines presented in Microsoft’s SHA-1 deprecation policy, getting the word out to our customers. We thought we had consensus on that plan, but Google’s action will cause customers to scramble to preserve the security indicators they currently have. SHA-1 is not broken today; it’s not likely to be broken in six months. In fact, google.com is still using SHA-1 in both end-entity and intermediate certificates today. Granted, the end-entity cert is rather short-lived, but while Google has the ability to roll over their certificate every three months, most SSL customers cannot. And they shouldn’t be asked to do that on such short notice.

The deprecation of 1024-bit end-entity certs last year is a good example. The industry formed a consensus and a reasonable flag day, and we all worked towards that. Some certificates had end dates fixed to the day before the flag day, but many others had end dates after that. These cases were remedied, and there were no widespread issues – indeed, it was a non-event as far as browser users were concerned. Website owners worked with their certificate providers and there was near universal adoption of 2048 bit certificates on schedule. The lesson here is that browsers didn’t need to downgrade UI indications for existing certificates before the end date, and there was no major disruption to customers.

In short, we’ve shown that the industry can enable these kind of upgrades without warning indicators. For these reasons we feel that sticking to the original Microsoft deadline would be responsible and would not jeopardize Internet security.

Ryan Sleevi

não lida,
26 de ago. de 2014, 20:00:4426/08/2014
para Rick Andrews, security-dev, blink-dev, net-dev, Ryan Sleevi
On Tue, Aug 26, 2014 at 2:58 PM, <rick_a...@symantec.com> wrote:
Symantec agrees with other CAs that the industry needs to phase out the use of SHA-1 in certificates, and we, like all other CAs that have commented, have been offering SHA-2 certs to our customers for some time now. Our concern about Google’s proposal is in regards to the disruption we feel it will cause for thousands of web site operators.

We’ve all been working towards the deadlines presented in Microsoft’s SHA-1 deprecation policy, getting the word out to our customers. We thought we had consensus on that plan, but Google’s action will cause customers to scramble to preserve the security indicators they currently have. SHA-1 is not broken today; it’s not likely to be broken in six months. In fact, google.com is still using SHA-1 in both end-entity and intermediate certificates today. Granted, the end-entity cert is rather short-lived, but while Google has the ability to roll over their certificate every three months, most SSL customers cannot. And they shouldn’t be asked to do that on such short notice.

The deprecation of 1024-bit end-entity certs last year is a good example. The industry formed a consensus and a reasonable flag day, and we all worked towards that. Some certificates had end dates fixed to the day before the flag day, but many others had end dates after that. These cases were remedied, and there were no widespread issues – indeed, it was a non-event as far as browser users were concerned. Website owners worked with their certificate providers and there was near universal adoption of 2048 bit certificates on schedule. The lesson here is that browsers didn’t need to downgrade UI indications for existing certificates before the end date, and there was no major disruption to customers.

Respectfully, Rick, I must disagree here.

While it's heartening to see 1024-bit end entity certs phased out, your historic summary lacks many key details. For example, such a flag day was only codified in the Baseline Requirements. However, because browsers did not directly and immediately mandate the Baseline Requirements, many CAs did not adopt any of the security practices and principles reflected in them. Of course, before this was Mozilla's CA communication in October 2010 for the need of CAs to move away from this - https://wiki.mozilla.org/CA:Communications#October_11.2C_2010 - but unfortunately, many CAs disregarded this and continued to issue en masse.

Indeed, it is worth noting that even Symantec was unable to comply with this flag day, as demonstrated by https://bugzilla.mozilla.org/show_bug.cgi?id=966350

Worse, however, is this flag day does nothing to the effective security of our end users, because it still permits and encourages intermediate and root certificates sized less than 1024 bits, which are a far more valuable target for factorization. I'm sure you're aware of https://bugzilla.mozilla.org/show_bug.cgi?id=936105 , regarding the removal of Symantec's 1024-bit certificates. Indeed, it's taken nearly 4 years since that Mozilla's announcement for Symantec to move in this direction.

In my mind, and the minds of many others that I've talked to, the RSA-1024 leaf cert deprecation, while important, is far from a success story, took over four years, and still leaves users today vulnerable and at risk. This is similar to the story for MD5, and one which we cannot allow happen yet again with SHA-1.
 

In short, we’ve shown that the industry can enable these kind of upgrades without warning indicators. For these reasons we feel that sticking to the original Microsoft deadline would be responsible and would not jeopardize Internet security.

Indeed, the original deadline is still adhered to. No CAs are expected to be issuing certificates after 2016/1/1 (and we will check the notBefore date, as previously discussed). No SHA-1 certificates will be accepted after 2017/1/1, period. In support of both of these dates, which are not up for discussion, we're also going to surface information to ensure that these dates can be reasonably met without widespread breakage.

All the best,
Ryan
 

Kirk Hall

não lida,
27 de ago. de 2014, 15:13:0827/08/2014
para securi...@chromium.org, blin...@chromium.org, net...@chromium.org, rsl...@chromium.org
Why not push out the implementation of Google's new policy by six months - delay the negative UI effect on SHA-1 certs (and SHA-2 certs from a SHA-1 sub-CA) expiring after 2015 until six months from now?  In other words, delay your Chrome changes to a later version than Version 39.

Creating a flag day for all SSL certificate users with only a 6-12 week notice period, and requiring perhaps the majority of certs in use today to be replaced over that very short period, is not reasonable and not required by any current security threat.  Google can accomplish 100% of its stated goals with a six month delay, thereby avoiding turmoil among website owners and unnecessary confusion among Chrome users as to what is or is not actually an invalid certificate.  So far, Google has not given any reason why this change must happen in 6-12 weeks as opposed to six months.

steve...@gmail.com

não lida,
27 de ago. de 2014, 15:14:5827/08/2014
para blin...@chromium.org, securi...@chromium.org, net...@chromium.org, rsl...@chromium.org

Ryan,

I support your endorsement of the previously communicated Microsoft policy sent directly to all CAs informing us of the 2016 and 2017 deprecation milestones.  In my own business, like many CAs, I am working on this task actively and I will achieve the two goals.

In the course of reviewing this discussion and the CABFPub posts, I feel that the conversation is devolving toward a door slam and I want to prevent that by sharing further perspective from my own experience.  I need to amplify the concerns of my friends who have already contributed great objections to the strategy. I want to point out areas where I feel that the conversation is getting counter-productive and subject to failure. 

I’m going to bulletize as a favor to weary eyes.

  • It is incorrect to conclude that because a certificate is issued for three years, it will live out those full three years regardless of compliance impacts.
  • It is fully within CA policy, practice, customer relationship, and software functionality to replace certificates that are about to enter a non-compliance period with those that are compliant at no cost.
  • Certificates being issued now out of compliance to the future milestones are issued by a CA knowing that they will be replaced.
  • Rick documents the above as real world in his post about issuer and end entity deprecation of 1024-bit keys.
  • Google did not present UX indicia to users a year or two in advance of the Mozilla issuer and end entity key size deprecation.  Key size deprecation was a more critical matter, yet SHA-1 is planned to get two year advance indicia.
  • As you state, in October 2010 Mozilla published its intent to end 1024-bit keys in three months.  The public (and far more extensive private, in my case) discussion that followed pushed that date out several years by Mozilla’s admittance to the impacts.  Mozilla adapted to CA discussion with them, and continues to empathize with customer impact as Kathleen regularly demonstrates.
  • You confronted Rick on the continued use of his 1024-bit roots as dismissal of the value of his contribution to the discussion, yet in your own explanation of trusted root store impact, you confirm that you have no intent to show indicia for SHA-1 roots.  You clearly demonstrate empathy for the difference between root management and issuer and end entity policy management.
  • You may choose to dismantle my points as you did with Rick by citing our use of a 1024-bit root.  I’ve publicly disclaimed that our root has a life larger than browsers and while we strongly caution against its continued use there are some situations where something is better than nothing.  We secure infrastructure that is not as agile as the browser space.
  • Twelve weeks has been labeled as generous, reasonable and manageable.  Like my colleagues, we manage PKI for customers who issue tens of thousands of SSL server use case certificates.  We all support methods to gain replacement certificates compliant to new policies for free.  But the license cost of a certificate is a fraction of the TCO.  In a bank with 35,000 certificates, a team of 40-50 certificate admins and 100-200 server admins manage that load over a calendar year.  In twelve weeks, which in reality reduces to 8 when you factor in mobilizing such a project, the workload on this team is SIX times normal daily volume (12 months divided by 2 months).
  • In late October, retailers stop all maintenance against e-commerce servers until mid-February.  Installation of one SSL certificate on one server requires senior VP level override of policy.  This means that IF we send out broadcast messages to our customers this week, they realistically have six weeks to respond.  They’ll lose the front end of that just planning the activity.
  • In your comments, you lament that if a site cannot replace its certificate in X amount of time, then that’s a sad landscape.  The issues here are not about one guy at one dotcom that has to replace one cert.  That’s a 1:1:1 ratio.  The issue is a typical 1:2000 cert administrator ratio and a 1:400 server to server admin ratio.  These numbers are real, both at our customers and across the Verizon brand.
  • Certificates managed on revenue generating servers that handle PII are subject to internal and external audits and change control windows.  Click, boom, done is not reality, even at the medium end of SMB.
  • Tom’s plan is to stop trust of a SHA-1 certificate on 1/1/17 and you agree.  Microsoft have no plans to dent the chrome of any SHA-1 certificates in 2015 as they have confidence that their end of trust is firm and adequate enough to cause 100% CA action or embarrassing failure and loss of customers.
  • You are moving a known flag day in 2017 that is manageable to a new flag day in 12 weeks during holiday server lockdown because you lack confidence in CA ability to protect our customers from failed trust. CAs must act to protect their revenue.  This is a for profit business, we are not going to fall on our faces and leave our spoils to our friends.  Tom understands that his motivation is plenty.
  • Your fear is generating a massive cost for our certificate buying customers, and we have no exploit in the wild like Heartbleed to use as justification.  We will need to broadcast a message that politely describes your concerns and then urges our customers to launch full scale replacement projects.  Ultimately, our enterprise customers will see through the veneer and define an unwarranted business cost and an inconsistent perception of risk.
  • You downplay the red UX indicia as just a gentle nudge.  SSL certificate customers want no dents on the products they buy from us, just like I can’t sell a bus with three wheels.  Any mark other than perfect may as well be an untrusted mark.  In certificate buyer perception, you are bringing 1/1/17 to this year.
  • Based on current compatibility, SHA-2 is a support failure for my operational affiliates across the Verizon brand.  Due to the variety of user agents in use, we are unable to move B2C and B2B Verizon web assets to SHA-2 without revenue loss, helpdesk traffic cost, and service abandonment.  Our own company accurately represents the customer base we serve.
  • Ryan, you’ve faced a lot of resistance that I’m sure you expected.  At times, I see a closed and conclusive posture in your tone.  For example, you’ve stated "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."  You’ve stated parenthetically that CAs are unwilling to communicate with customers without basis in fact.  You’ve changed venue on the CABF discussion where valid points were raised.  In doing so, you deflated Kirk’s expectation that there was any point to his message, as he left it up to you to cross post if you saw a point to it.  It appears Kirk had no point.  You’ve criticized CAs based on root management policies when we all know that end entity and issuer transition is orders of magnitude easier than root transition.  I’ve been through 5 root transitions since 1998, they begin at T-minus four years.
  • Now let me balance that because I don’t want to spar.  Ryan, you’ve also shown a lot of patience with expected conflict.  I know you are open to the idea of looking at a calendar, looking at today’s date, looking in your outbox for a message to all CAs that states that this is your policy, looking at holiday freeze and realizing that if you don’t trust CAs to take action, now is not the time to try to catalyze action.  If you read my position statements with empathy toward the SSL certificate owner, and you can detect the passion of all the contributors here to comply, I feel you can dismiss the fear that we are ignoring this compliance deadline.
  • If you’re still afraid of us all failing, then 12 weeks just amplifies the impact on the market and the quantity of trusted connection failures.  A rational strategy to communicate your disgust with our inability to act would be to set a date we all feel we can achieve provided that we can get the message out, get real action started in February after holiday freeze, and get closure within 2015.  Closing this issue in 2015 is a 100% win and succeeds at the goals to which you subscribed in the CABF discussion you cite.  Marking certificates that temporarily exceed the 2016-7 targets with demerits in 2015 will cause market panic at a time when few are prepared to act.

Ryan, I compel you to review the passion we all share for your plan and our plea to let us execute it effectively with fanatical customer endorsement of the idea brought about by milestones that work from the enterprise to the dotmom.

 

felix

não lida,
27 de ago. de 2014, 15:56:4227/08/2014
para steve...@gmail.com, blin...@chromium.org, securi...@chromium.org, net...@chromium.org, rsl...@chromium.org
That's a long bullet list, and I think you're burying the lede:
  • In late October, retailers stop all maintenance against e-commerce servers until mid-February.  Installation of one SSL certificate on one server requires senior VP level override of policy.  This means that IF we send out broadcast messages to our customers this week, they realistically have six weeks to respond.  They’ll lose the front end of that just planning the activity.


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

Ryan Sleevi

não lida,
27 de ago. de 2014, 16:37:5027/08/2014
para steve...@gmail.com, blink-dev, security-dev, net-dev, Ryan Sleevi
On Wed, Aug 27, 2014 at 12:14 PM, <steve...@gmail.com> wrote:

Ryan,

I support your endorsement of the previously communicated Microsoft policy sent directly to all CAs informing us of the 2016 and 2017 deprecation milestones.  In my own business, like many CAs, I am working on this task actively and I will achieve the two goals.

In the course of reviewing this discussion and the CABFPub posts, I feel that the conversation is devolving toward a door slam and I want to prevent that by sharing further perspective from my own experience.  I need to amplify the concerns of my friends who have already contributed great objections to the strategy. I want to point out areas where I feel that the conversation is getting counter-productive and subject to failure. 

I’m going to bulletize as a favor to weary eyes.

  • It is incorrect to conclude that because a certificate is issued for three years, it will live out those full three years regardless of compliance impacts.
  • It is fully within CA policy, practice, customer relationship, and software functionality to replace certificates that are about to enter a non-compliance period with those that are compliant at no cost.
  • Certificates being issued now out of compliance to the future milestones are issued by a CA knowing that they will be replaced.
  • Rick documents the above as real world in his post about issuer and end entity deprecation of 1024-bit keys.
  • Google did not present UX indicia to users a year or two in advance of the Mozilla issuer and end entity key size deprecation.  Key size deprecation was a more critical matter, yet SHA-1 is planned to get two year advance indicia.
Leaf-cert key size deprecation is far less important than root deprecation, and as you note from Chris Palmer's reply early on, that very much is on our radar.
 
  • As you state, in October 2010 Mozilla published its intent to end 1024-bit keys in three months.  The public (and far more extensive private, in my case) discussion that followed pushed that date out several years by Mozilla’s admittance to the impacts.  Mozilla adapted to CA discussion with them, and continues to empathize with customer impact as Kathleen regularly demonstrates.
However, as noted in public forums, the CAs had communicated hard dates, and then repeatedly failed to meet those hard dates. This has continued to be a trend. We want to help CAs be able to reach their customers, which is the leading reason CAs give for being able to meet the dates they commit to.

  • You confronted Rick on the continued use of his 1024-bit roots as dismissal of the value of his contribution to the discussion, yet in your own explanation of trusted root store impact, you confirm that you have no intent to show indicia for SHA-1 roots.  You clearly demonstrate empathy for the difference between root management and issuer and end entity policy management.
 That's because the signature for a root is irrelevant, while the key size is very relevant.
  • You may choose to dismantle my points as you did with Rick by citing our use of a 1024-bit root.  I’ve publicly disclaimed that our root has a life larger than browsers and while we strongly caution against its continued use there are some situations where something is better than nothing.  We secure infrastructure that is not as agile as the browser space.
  • Twelve weeks has been labeled as generous, reasonable and manageable.  Like my colleagues, we manage PKI for customers who issue tens of thousands of SSL server use case certificates.  We all support methods to gain replacement certificates compliant to new policies for free.  But the license cost of a certificate is a fraction of the TCO.  In a bank with 35,000 certificates, a team of 40-50 certificate admins and 100-200 server admins manage that load over a calendar year.  In twelve weeks, which in reality reduces to 8 when you factor in mobilizing such a project, the workload on this team is SIX times normal daily volume (12 months divided by 2 months).
9 months. Not 12 weeks. 
  • In late October, retailers stop all maintenance against e-commerce servers until mid-February.  Installation of one SSL certificate on one server requires senior VP level override of policy.  This means that IF we send out broadcast messages to our customers this week, they realistically have six weeks to respond.  They’ll lose the front end of that just planning the activity.
  • In your comments, you lament that if a site cannot replace its certificate in X amount of time, then that’s a sad landscape.  The issues here are not about one guy at one dotcom that has to replace one cert.  That’s a 1:1:1 ratio.  The issue is a typical 1:2000 cert administrator ratio and a 1:400 server to server admin ratio.  These numbers are real, both at our customers and across the Verizon brand.
  • Certificates managed on revenue generating servers that handle PII are subject to internal and external audits and change control windows.  Click, boom, done is not reality, even at the medium end of SMB.
  • Tom’s plan is to stop trust of a SHA-1 certificate on 1/1/17 and you agree.  Microsoft have no plans to dent the chrome of any SHA-1 certificates in 2015 as they have confidence that their end of trust is firm and adequate enough to cause 100% CA action or embarrassing failure and loss of customers.
That's not a statement you can make, nor is it one Microsoft has made. It would be helpful to stick to the facts.
  • You are moving a known flag day in 2017 that is manageable to a new flag day in 12 weeks during holiday server lockdown because you lack confidence in CA ability to protect our customers from failed trust. CAs must act to protect their revenue.  This is a for profit business, we are not going to fall on our faces and leave our spoils to our friends.  Tom understands that his motivation is plenty.
The flag day for when SHA-1 will stop working has not changed at all. 

Chrome has always been committed to the security of its users, and regularly makes a variety of UI changes meant to highlight security or, when necessary, remove security indicators when we lack faith in the security. Mixed content issues are one example of this, and certificates issued to invalid server names are another.

We also see aggressive roll-outs of security features, ranging from mixed content blocking to the deprecation of insecure, legacy features such as NPAPI. While I understand that this differs in degree, as there is now a third-party involved, it's not a difference in kind, in which server operators respond to and adjust to the ongoing improvements in online security.
  • Your fear is generating a massive cost for our certificate buying customers, and we have no exploit in the wild like Heartbleed to use as justification.  We will need to broadcast a message that politely describes your concerns and then urges our customers to launch full scale replacement projects.  Ultimately, our enterprise customers will see through the veneer and define an unwarranted business cost and an inconsistent perception of risk.
  • You downplay the red UX indicia as just a gentle nudge.  SSL certificate customers want no dents on the products they buy from us, just like I can’t sell a bus with three wheels.  Any mark other than perfect may as well be an untrusted mark.  In certificate buyer perception, you are bringing 1/1/17 to this year.
As Chris noted, we will continue to adjust UI to reflect ongoing security best practice, and to downplay security practices with known issues. This is, conceptually, no different from the fact that we enforce a minimum keystrength of the TLS ciphers used, or the use of other indicators for determining the security status, such as mixed content.

That is, the mere presence of a certificate has never been sufficient to determine whether or not a site is 'secure' in the way that users expect. 
  • Based on current compatibility, SHA-2 is a support failure for my operational affiliates across the Verizon brand.  Due to the variety of user agents in use, we are unable to move B2C and B2B Verizon web assets to SHA-2 without revenue loss, helpdesk traffic cost, and service abandonment.  Our own company accurately represents the customer base we serve.
  • Ryan, you’ve faced a lot of resistance that I’m sure you expected.  At times, I see a closed and conclusive posture in your tone.  For example, you’ve stated "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."  You’ve stated parenthetically that CAs are unwilling to communicate with customers without basis in fact.  You’ve changed venue on the CABF discussion where valid points were raised.  In doing so, you deflated Kirk’s expectation that there was any point to his message, as he left it up to you to cross post if you saw a point to it.  It appears Kirk had no point.  You’ve criticized CAs based on root management policies when we all know that end entity and issuer transition is orders of magnitude easier than root transition.  I’ve been through 5 root transitions since 1998, they begin at T-minus four years.
As we've mentioned several times, it's normal and appropriate that the discussion of browser policy be held with the browser.

Chrome remains committed to openness that has, so far, well exceed the CA/Browser Forum's committments, as evidenced by the representation structure chosen two years ago. For such important changes, for example, we believe it's important to engage the public, which you can see this thread has done, and to which the CA/Browser Forum discussions cannot.

This is no different than discussions of Mozilla's security policy, which I note both you and Kirk have participated in the past, occurring on Mozilla's security policy list.
 
  • Now let me balance that because I don’t want to spar.  Ryan, you’ve also shown a lot of patience with expected conflict.  I know you are open to the idea of looking at a calendar, looking at today’s date, looking in your outbox for a message to all CAs that states that this is your policy, looking at holiday freeze and realizing that if you don’t trust CAs to take action, now is not the time to try to catalyze action.  If you read my position statements with empathy toward the SSL certificate owner, and you can detect the passion of all the contributors here to comply, I feel you can dismiss the fear that we are ignoring this compliance deadline.
  • If you’re still afraid of us all failing, then 12 weeks just amplifies the impact on the market and the quantity of trusted connection failures.  A rational strategy to communicate your disgust with our inability to act would be to set a date we all feel we can achieve provided that we can get the message out, get real action started in February after holiday freeze, and get closure within 2015.  Closing this issue in 2015 is a 100% win and succeeds at the goals to which you subscribed in the CABF discussion you cite.  Marking certificates that temporarily exceed the 2016-7 targets with demerits in 2015 will cause market panic at a time when few are prepared to act.

Ryan, I compel you to review the passion we all share for your plan and our plea to let us execute it effectively with fanatical customer endorsement of the idea brought about by milestones that work from the enterprise to the dotmom.

 


While not wishing to appear dismissive, I feel like the summation of this thread is that you don't feel that an insecure and deprecated practice - one that was shown weak in 2005 and recommendations to begin transition away from, one in which the cryptographic community successfully moved away from by 2010 (e.g. NIST requiring the US government to transition by 2010, or the statement at http://csrc.nist.gov/groups/ST/hash/statement.html ), and one in which the CA/Browser Forum agreed as deprecated in spirit 2011 - should be gently discouraged. I say gently, because this is not outright disabling, as users will be able to continue to use and interact with the site without incident.

I don't see how, with nearly 10 years having gone by in which CAs could have worked with both site operators and users to encourage transition to modern systems and certificates, that one year (on top of the 9 months already given) will fundamentally alter or change things. It's hard to feel that CAs are committed to security, when the preponderance of evidence for nearly a decade has been the insecurity, and the response in 2005 is the same as it is now - which is that SHA-1 is too big too fail and too hard to change. 10 years ago, this may have been the case, 5 years ago, this could have been the case, but in 2014, and far more importantly, 2017, this simply cannot be the case.

Steve

não lida,
27 de ago. de 2014, 19:14:4027/08/2014
para rsl...@chromium.org, blink-dev, security-dev, net-dev
Ryan,

I think we all firmly share the position that we need to act that you take in your conclusion responding to my points.  We are all quite eager to steer toward the best plan with you.  Just look at this thread in so few days.

We differ on the "gentle"-ness of your plan.  We differ on buyer perception of the dent.  Look across the CAs at the minutia we all use in marketing to create quality in perception gaps to quality in fact.  You don't think a ticking bomb on their site is going to affect certificate buyer behavior?

We all state various impacts, and we endorse what you are trying to do.

In your response, you chose to comment on specific bullets I wrote.  Did you have further responses to make or have we advanced together in an understanding of my other contributions?

I'm willing to accept your venue as the proper place for this discussion, as I prove by making my first contribution here.  In my topic, I was trying to point out that your approach to discussion with the CAs is not endearing participation.  We're across a river with catapults and nobody is building a boat.

In my presumption of Microsoft's position derived from a decade and a half of invested observation and a decade long working relationship with Tom and Kelvin, I'll toss my comment on the floor for them to refute and publicly humiliate me.  I won't stress the point because you're right, it's not fact.  I will stress that in my shop, I have been taking action based on Microsoft policy since the moment it was published.  Every CA I have subordinated since is signed twice, with SHA-1 and SHA256.  Every certificate I currently issue already has a SHA256 corollary in production operation and we are finalizing the marketing skins that will educate.  Our managed service customers are already availed of SHA256 certificates and SHA-1 alternatives upon request.  We have several customers operating full SHA256 chains, and we're steering massive corporate deployments in controlled environments toward all SHA256. 

Your work has already taken further effect to the response Microsoft provoked.  We are preparing communication in response to this thread to propose primary use of SHA256 and access to SHA-1 by exception only, along with an assurance that any application that cannot handle SHA256 is subject to significant security risks that can easily expose PII outside the tunnel regardless of algorithms and key sizes due to keylogger malware injection.  Such systems should be excluded from access, and we'd welcome PCI audit support of that position along with the once and for all deprecation of server gated cryptography as the false sense of security that has perpetuated the $800 toilet seat.

For the nine month comment, that points back to February, I would need to step out of professional context and employer payroll to fully express myself.  Remaining in context for now, must I quote Douglas Adams? 

Ryan, you have been very pro-active in stimulating discussion and communicating CT.  You also review Kathleen's drafts at m.d.s.policy.  Therefore, I don't need to post CA communications to show how your peers express policy because you're already doing great with CT.  What the heck happened here?

What percentage of the hundreds of thousands of affected certificates do you perceive are ready to be replaced in the weeks up to late October?  Then replaced again in the coming months to smooth away an anniversary spike that would happen every September?

Look at the consensus reaction in this thread.  February didn't sink in.  Let's look forward at what is going to work for all parties involved.

Kind regards,
Steven Medin
titles, titles, titles...

steve...@gmail.com

não lida,
28 de ago. de 2014, 13:12:5028/08/2014
para blin...@chromium.org, securi...@chromium.org, net...@chromium.org, rsl...@chromium.org
Today, Mozilla proposes to align to Microsoft 2017 deprecation timing with no prior UX or disabling action unless cryptographic failure warrants action, and opens the topic for discussion on m.d.s.policy.

https://wiki.mozilla.org/CA:Problematic_Practices#SHA-1_Certificates

Ryan Sleevi

não lida,
28 de ago. de 2014, 13:24:4128/08/2014
para steve...@gmail.com, blink-dev, security-dev, net-dev, Ryan Sleevi
This applies to the Mozilla Root Program, which is operated somewhat and slightly differently that Mozilla Firefox, much like the Microsoft Root Program is operated somewhat and slightly differently than IE.


To the extent it's relevant, I would simply note that it doesn't suggest that there will be no UX, only that Mozilla has aligned with Microsoft's dates for their (independent) Root Program.

steve...@gmail.com

não lida,
28 de ago. de 2014, 13:41:3128/08/2014
para blin...@chromium.org, steve...@gmail.com, securi...@chromium.org, net...@chromium.org, rsl...@chromium.org
Certainly Ryan, and as much as I respect your forum for conversation I respect your ownership of Chromium security policy.  I don't expect you to operate based on the actions of other organizations, you have your own goals to meet.  Of course, I drew attention to Kathleen's post as contrast since it does not state that UX indicia would be displayed and this is the major point we are contending.

Indeed it makes no statement about FF UX, and I've jumped on that clarification already as it brings weight here.  Saying nothing = doing nothing is a safe leap of faith, but we can close out that point at m.d.s.policy.

Kirk Hall

não lida,
28 de ago. de 2014, 17:34:1028/08/2014
para securi...@chromium.org, blin...@chromium.org, steve...@gmail.com, net...@chromium.org, rsl...@chromium.org

Ryan, I asked a question yesterday, and am still interested in the answer.  Why not push out the implementation of Google's new policy by six months – in other words, delay the negative UI effect on SHA-1 certs expiring after 2015 until six months from now?  

 

You can see that most or all CAs think Google’s current 6-12 week deadline is way too short for many website owners to change out all their current (valid) SHA-1 certs, especially with the holiday season lock-down coming soon (the window for response is actually more like 4 weeks for some retail websites).

 

Google can accomplish 100% of its stated goals with a six month delay in enforcement (e.g., to March 1, 2015).  This new date would still require all websites to replace all SHA-1 certs by the end of 2015 – Google’s stated goal – but in a more reasonable time frame.

 

Your prior postings have indicated Google has been working on this new policy for six months (February to August, when the new policy was announced).  Why not give website owners and CAs an equal period of time – six months – to respond to the new policy if that new deadline will still achieve all of your goals?  That could make your policy much more successful, and would be appreciated by everyone.

 

**So how about it, Ryan – will Google help everyone out and postpone its new policy for six months?**

Ryan Sleevi

não lida,
28 de ago. de 2014, 18:09:3528/08/2014
para Kirk Hall, security-dev, blink-dev, steve...@gmail.com, net-dev, Ryan Sleevi
On Thu, Aug 28, 2014 at 2:34 PM, Kirk Hall <kirk...@trendmicro.com> wrote:

Ryan, I asked a question yesterday, and am still interested in the answer.  Why not push out the implementation of Google's new policy by six months – in other words, delay the negative UI effect on SHA-1 certs expiring after 2015 until six months from now?  


Which we did after we discussed this six months ago. And we're still hearing the same reactions and plans, and we're still seeing that (some) CAs are communicating to their customers that they do not expect Chrome to actually anything other than positive security, therefore their customers need not worry about things nor change to SHA-256.

As I have already explained several times on this thread, there's more than just CAs at play here - there's a variety of software products and solutions that have relied on this, and even if CAs were perfect (and honest!) in their communication with their customers, this would still be a sizable and meaningful effort to functionally disable SHA-1 in 2017, for the same reasons we saw it take nearly a decade for MD5.
 

 

You can see that most or all CAs think Google’s current 6-12 week deadline is way too short for many website owners to change out all their current (valid) SHA-1 certs, especially with the holiday season lock-down coming soon (the window for response is actually more like 4 weeks for some retail websites).

 

Google can accomplish 100% of its stated goals with a six month delay in enforcement (e.g., to March 1, 2015).  This new date would still require all websites to replace all SHA-1 certs by the end of 2015 – Google’s stated goal – but in a more reasonable time frame.


This halves the effective time that site operators and ISVs are aware of the need to transition, in favour of particular CAs that were given advance notice of and participated in significant discussions of this six months ago.
 

 

Your prior postings have indicated Google has been working on this new policy for six months (February to August, when the new policy was announced).  Why not give website owners and CAs an equal period of time – six months – to respond to the new policy if that new deadline will still achieve all of your goals?  That could make your policy much more successful, and would be appreciated by everyone.


I'm not sure how you reached this conclusion. The policy was announced six months ago to CAs, with the precise intention that they would and could work with their website owners to respond to the new policy.
 

 

**So how about it, Ryan – will Google help everyone out and postpone its new policy for six months?**


I think it's clear that postponing six months will help some CAs, especially those who have been deceptive in communications with their customers, but will harm those users, site operators, and ISVs who are not aware.

We have seen similar situations with the deprecation of MD5, with 1024-bit certificates (as a whole), and with internal server names, so I'm not sure why you feel the evidence would suggest this would be any different, especially with six months already afforded and discussed.

kirk...@trendmicro.com

não lida,
28 de ago. de 2014, 18:18:4628/08/2014
para rsl...@chromium.org, security-dev, blink-dev, steve...@gmail.com, net-dev

Ryan – you keep saying Google told all CAs about this policy six months ago.  What are you referring to?  The CA/Browser Forum meeting in February?  You made no mention of this policy at that time.  See again the meeting minutes below from February 19, 2014.

 

Can you point to some other place – email, or whatever – where Google told anyone about its new SHA-1 policy?  I’m having a hard time understanding you – when and where did this happen?

 

The first time that ANY CA knew about your new policy was on August 19, when you posted it here: https://groups.google.com/a/chromium.org/forum/#!msg/security-dev/2-R4XziFc7A/NDI8cOwMGRQJ  Then you verbally informed CAs on the next call of the CA/Browser Forum on August 21.  As you may recall, there was stunned silence in response to the deadlines you announced.

 

To be blunt, Google did not announce its policy six months ago – only nine days ago.  Can’t you please create a reasonable deadline for everyone, when it will get Google to where it wants to be in early 2015?  There’s no reason to be vindictive – you are punishing everyone for what you see as the failings of (some) CAs on past transition issues like MD5, 1024 bit certs, etc.  Come on, Google is bigger than that…

 

Here (again) are the CA/Browser Forum Minutes from last February 19 – no new Google policy was announced:

 

Wednesday, 19 February 2014

Browser News

Mozilla (Brian Smith):

1. Working on changing to new cert verification library for FF30 which will be released in 16 weeks “Path bldg. for cert chains in a more sensible way”. Helps increase compatibility and will allow them to add new features in certs like CT.

2. Half way done in implementing “must staple” extension. Working to revise Phil Baker’s IETF draft and getting it published. Overall goal: make OCSP staple secure. This will help promote OCSP stapling as a good solution against key compromise. OCSP fetching discussion going on now. 7% of handshakes use OCSP stapling. Would like to increase to 100%.

3. The new path building logic will be an option in FF29. They will recommend that each CA test against their own certs

4. FF29 to remove most or all of 1024 bit roots. CA’s need to get back to Mozilla with any significant impact CAs that have legacy roots that have been cross signed would be affected. Mozilla will accept requests from CAs to build in intermediates into Mozilla if that will help prevent many web sites from breaking (contact Brian).

5. Timeline for FF29: April 29th (remove 1024 roots and new path building code optional). FF30: June 10th (new path building code enabled for all)

6. No decision made yet on SHA-1 deprecation. Awaiting feedback from CAs on MSFT proposal.

Google Chrome (Ryan Sleevi)

1. Transitioning away from NSS to OpenSSL stack except on Windows and Android. Win will continue with Crypto API Effect on moving to OpenSSL-parsing rules. No special UI for bridge certs but will support them.

2. Looking at programmatic enforcement of BRs

3. CT reqt to be discussed later

4. Chrome does not support internal server names from public roots (this has been true for some time now). Will not show lock.

Microsoft (Tom Albertson)

1. SHA-1 announcement published

2. First 1024 bit cert removal in March Windows update. Another one to be issued in June to remove more roots. One criteria used: how quickly CAs responded to Microsoft. By end of 2014-no more 1024 roots

3. Programmatically enforcing BRs in 2014. Tom contacting CAs directly. After 2014, rule out exceptions and “throw the switch”.

4. April 2015-No longer accepting non BR compliant certs.

5. Cert hygiene- checking things like no issuing from roots

SHA1 Sunsetting / Grandfathering Strategy

Ben: We should work on a path forward to make sure everyone is aware of the current plan to eliminate SHA-1. We might want to see if there is a way to allow exceptions for an initial grandfather period, along with the sunset period when everything gets turned off, because there are likely to be some that will object to a hard deadline.

Tom: Removal of roots may have some affect.

Richard: Four million users in China are relying on Windows XP, SP2, which cannot use SHA2.

Brian: If browsers enforced SHA2, then end users would stop approaching CAs asking for SHA1 certificates. 
When large, popular websites start using SHA2, then everyone will want to upgrade their browsers.

Brian: With TLS 1.2, the client can send the server a list of algorithms it supports, and maybe we could get server vendors to start adding an ability to select SHA1 vs. SHA2 based on what the TLS 1.2 client sends, like what has been done for EC certificates vs. RSA certificates. This might work with markets with localized issues like China and Japan. Also, large ecommerce sites have economies of scale to create customized code to serve SHA1 to SHA1 clients and SHA2 to SHA2 clients, so maybe we should make them aware of this possibility. They would be willing to do more work than the general population of server administrators.

Robin: We cannot, however, partition the Internet into different zones - SHA1 vs. SHA2.

Dean: How does this work on the browser side?

Brian: In Firefox, the user gets a warning that says, “we cannot verify that this was issued by a trusted issuer.” Then we let users click through it – we basically treat it as an invalid signature.

Dean: What about Chrome?

Ryan: You will get an invalid certificate, based on whether it uses CryptoAPI. Whether it is over-rideable depends on whether it is an invalid server certificate, then no, but if it is an untrusted server certificate, then yes, it is over-rideable.

Dean: What about Internet Explorer?

Tom: You will not be able to have an https connection.

Ben: Regardless of whether all of the browsers implement SHA1 sunsetting, there will still be users who do not upgrade their browsers, so the issue is how do we gracefully transition, because regardless of the cutoff date, there will be a tail that follows after that date. We should be looking for statistics – who has moved, why haven’t people moved to SHA2, etc., and based on that we could see whether any grandfathering rule makes sense, because no CA wants to violate a rule.

Chris: As a general rule, we seem to have a double sunset. We take a date to our customers, and they start to implement it. Then our customers come back to us with news about their problems, or their customers’ problems. And then through an organic process we come up with a grandfather policy.

Wayne: I wonder if we should be setting deadlines at this point. Microsoft has a date and a time next year at which to re-evaluate the policy, and then we have our users and a security policy we’re trying to implement without breaking things, so that is when we should evaluate between breaking things and the sunset.

Brian: If we wait too long, then we’ll have some CAs who have the situation under control and those that don’t. Then, if things change, those CAs who have handled the transition responsibly will feel they are being treated unfairly. For instance, a CA issuing a certificate without OCSP could sell certificates more cheaply in violation of the rules. By June 2015, we need to be able to say that we have identified all of the potential issues.

Chris: We need to have a process for future migrations. So, if Microsoft says, “we need to move over to this specification, but until customers begin to feel the pain, we don’t know what all of the issues are. Then, when they complain, we give them a temporary, 1-year reprieve while a better solution is developed.

Brian: We should definitely consider shortening the lifetimes of SHA1 certificates—they shouldn’t be longer than a year. So, we need to put into the Baseline Requirements a maximum lifetime for a certificate with a SHA1 signature.

Bob: We’re trying to reduce our risk, because we want to reduce the number of certificates with SHA1 and the negative impact that will occur when it is known that SHA1 is insecure.

Richard: We should issue the user two certificates. That way, at the appropriate time, the user can just switch over from their SHA1 certificate to their SHA2 certificate.

Rick: I like that idea, and we’re also considering that approach. It’s easier for us and for the customer, so we’d prefer that strategy rather than shortening lifetime.

Bob: We need to have the customer experience pain with a SHA1 certificate, or it won’t work.

Brian: What is the problem with limiting SHA1 to one year?

Rick: We have a number of platforms for selling certificates, and let’s say a customer buys a three-year certificate, and we deliver a SHA2 certificate, and they tell us that a SHA2 certificate doesn’t work. It’s much easier just to say, here are your two certificates. There is no longer a need to refund because we’ve at least given them what they’ll need over that three-year period.

Brian: It still doesn’t make sense to be selling and giving customers something that you know will not work two years from now.

Rick: If Microsoft re-evaluates in June 2015, it could push the date out.

Tom: It is most likely that the date will stay right where it is.

Rick: It is possible, so that’s why.

Tom: It’s not really a date that we’re going to be looking at the fragility of SHA1. Because we know SHA1 is already fragile. We are looking at the actual exposure to customers. We are trying to figure out who gets harmed by using SHA1. Right now, we don’t see enough harm to justify pushing out the date. I recommend getting your customers started on SHA2 now, that way, it will reduce your refunds.

Rick: We are pushing SHA2.

Brian: What do you think about my idea that changing server software to recognize that the server supports SHA2 and then serving up one certificate or another based on that?

Tom: Anything we can do to promote SHA2 is a good thing, like TLS 1.2.

Ryan Sleevi: It’s tricky. It requires action by both people on the server side and client side. With Chrome, we’ve seen some issues. For instance with ECDSA certificates, on OSX 8 verification of certificates was broken but TLS worked, so you have to engage in snipping to try and figure out what is going on. Is the TLS handshake issue coming from a Safari configuration or from Chrome? And there are other issues with certificate verification and relying on the OS. 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.

Brian: I can understand the ECC issue because Chrome has to support Windows XP that doesn’t have ECC, but as far as I know, Chrome doesn’t run on any platform that doesn’t support SHA2. So, when you’re running on SP 2, what do you do with the supported signature algorithms field of the TLS handshake for TLS 1.2?

Ryan: Probably the wrong thing. Description: Description: :-)

Brian: Presumably, you could fix that, too.

Ryan: Yes, we can, and we hope to resolve that in TLS 1.3, although supporting TLS 1.2 has been messy enough.

Ben: Assuming the Microsoft date is not going to change, can we take that as a given and work around the variables that we can change and identify what is not going to change?

Kirk: As Chris noted, there are two sunsets--the stated one and the panic one. The one thing to think about is whether Microsoft is really going to just turn SHA1 off so it doesn’t work. The sunset is January 2017. We could say that we couldn’t sell any SHA1 cert after July1 of the previous year so people try to get into panic mode and then give them 30-day certificates.

Ryan: We have had discussions with cryptographers about this, “oh crap, panic mode” and probable collisions and without giving CAs false hope, there might be things that browsers could do to pre-identify potential collisions based on certain characteristics and that might provide a little bit more of a transition phase. We might be able to look at those in SHA1 and block those certificates.

Ben: Whatever we do should not allow customers or other CAs wiggle out by not having to do it. It should be above board and strict and programmatically enforced, and just start people toward that pain point without CAs having to be the police on it, because there would be chances of undercutting it.

Wayne: What I’ve heard here today has changed my opinion, instead of assuming that all CAs are smart enough not to issue SHA1 certificates that expire after January 1, 2017, we should have a policy that says starting January 1, 2015, you’re not allowed to issue a certificate with a SHA1 algorithm that expires after January 1, 2017. When I read Microsoft policy, that’s what I get, but that’s not really what it says. Maybe that is a way to move it forward.

Brian: That’s almost exactly what I recommended that Firefox do, except I said 2014. I don’t see why we should keep accepting certificates after there has been time for CAs to adjust, that have a validity period that ends after January 1, 2017. If CAs say they need 6 months, to implement some changes before they are ready to do that, then that type of policy is very reasonable, not just for CA/B Forum to put in the BRs, but for browsers to start enforcing that on January 1, 2015.

Doug: I prefer to not set a certain date because when you’re selling certificates, it is hard to set the price for an 18-month or 20-month certificate. I think that we set maximum validity periods on certain dates. For instance, say April 2014 is a 2-year max validity SHA1 certificate, but not an end date—it’s easier to program for a 2-year or a 1-year certificate.

Wayne: My interpretation the way I hear what you are saying is after January 1, 2015, with my system is that I will no longer be able to sell a SHA1 Certificate to a customer for more than 1 year. But at the same time, other CAs might have different systems, but they are stuck with that.

Brian: I understand what you’re saying.

Chris: There’s a pro and con to what you’re saying, we want to be careful, but we can actually communicate this to our customers all at the same time in terms of policy. We could just pick a hard date.

Brian: It makes a lot of sense for the software developers to look at the cryptographic concerns that have been raised and determine that based on these concerns, as far as securing our products goes, we stop accepting these certificates after this date, based on what we know, and create some kind of document for it. IETF is already working on that anyway, and then say, here is an open standard that we are going to implement. For CAs selling certificates to customers, then you have an open, public recommendation that you can point people to. Put the blame on the software companies.

Rick: I agree with Doug and I disagree with Wayne. We can tell customers that we can sell them a SHA1 certificate that goes beyond January 1, 2017, but on that date your Windows box will stop trusting it. We are already giving that warning to customers, so it is superfluous to tell customers also that before then the browsers will stop trusting it. There is already a built in sunset date. I’d like to have the flexibility to issue beyond that date with the understanding that I’ll communicate with my customers. It just makes it a lot easier to comply.

Ryan: It is possible that the certificate will work well beyond the sunset date if they are not on a system with Windows update.

Kirk: What about a requirement that you tell a customer if you sell them a SHA1 certificate with an expiration date beyond 2017 it probably will not work on a certain applications? That sounds like it would cover what Symantec is already doing and it should reduce the number of customer support calls if we give that notice.

Ben: What if with that motion we included some type of endorsement or recognition of Microsoft’s date? Then we’re self-regulating without having to enforce a requirement.

Ryan: We’ve seen examples in the Forum of exceptions, but here we have an opportunity to work with root programs and state what has been determined as best practice. This could be folded into audit requirements and if you can’t meet the requirement then you can work with the root program for additional time in which to comply.

Bob: CAs should not be selling three-year SHA1 certificates at this point. We shouldn’t leave a policy that allows CAs to pre-sell SHA1 certificates.

Dean: It’s not because we are trying to sell SHA1 certificates, it is that customers want to buy them. Customers want to buy three-year certificates; they do not want to buy one-year certificates.

Bob: The point is that you have to stop selling three-year SHA1 certificates.

Doug: Not necessarily. They can get a replacement certificate for free, only it’s a SHA2. At their leisure, they can upgrade to a SHA256.

Rick: Clearly, after January 1, 2017, we cannot sell a SHA1 certificate of any duration. Our current path is best. We sell them a three-year SHA2 certificate. If they come back and say they need a SHA1 certificate, we give them a three-year SHA1 certificate, and we tell them, at some point, you’ll probably need to switch back to the SHA2 certificate.

Ryan: I understand where Bob is coming from on a policy perspective, but wouldn’t it be better to provide a warning to customers.

Rick: That’s what we’re doing.

Dean: Even NIST didn’t have a SHA2 certificate.

Brian: If we cannot agree within the Forum, then individual root programs should announce what they intend to do. The advantage of doing it within the Forum is that there is consistency and everyone knows what to expect. As I understand the reason for the Baseline Requirements, they were to give CAs more consistency across browser root program policies.

Ben: We could follow the Symantec approach and then just revoke certificates at that date, and it isn’t that auditable, but at least it gives people a date to look at, or on the other hand, maybe people want SHA1 certificates beyond that date, and we just leave it up to the browsers to turn SHA1 support off on January 1, 2017, and then who would want one of those certificates.

Kirk: I see Rick’s point, why not allow people to use it past 2017.

Rick: That’s not my point.

Kirk: Well, I see the reasoning behind warning the user and giving them both a SHA1 and SHA2 certificate.

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.

Moudrick: We need a date for not issuing them and we need a date for not recognizing them.

Ryan: That’s why we need these dates—to balance these burdens.

Dean: The Microsoft policy has two dates. It says stop issuing SHA1 on 1 January 2016 and that on 1 January 2017 it will stop recognizing SHA1 certificates.

Rick: That’s why I’m saying we need flexibility.

Chris: The two certificates solves the refund-revenue-recognition problem. There is no return policy because they have something they can move over to.

Ben: Why can’t we just adopt the Microsoft policy as the Baseline Requirements rule?

Chris: Don’t we have to go with that? I was hoping we could coordinate a unified voice. The meeting in 2015 is not going to result in any change.

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.

Chris: Rick, could you start putting a pain point out to customers starting January 2015?

Rick: I don’t know. On one of our retail platforms, the customer buys the certificate based on lifetime first and then they have to choose whether it is SHA1 or SHA2.

Chris: It would be great if we can all come to consensus on this together.

Doug: I agree with Rick, because it confuses the customer because they want to buy a three-year certificate and they fear anything but SHA1.

Ryan: We have known about concern with SHA1 since 2009.

Bob: So we should be experimenting now, not in 2016.

Ben: It sounds like most of us have some hybrid solution in place already.

Brian: One of the reasons we should work on this now is to reduce our support costs in 2017. Our goal isn’t to cause anyone pain or inconvenience now, but to ensure that in 2017 any inconvenience or pain is as close to zero as possible and to make this fair to every CA, because if it is coded in the browser, then there are no exceptions, and everyone can plan accordingly. Whatever way, some CAs are going to experience some pain in transitioning to whatever the migration plan is implemented.

Rick: We need to lead by example, and all CA/Browser Forum members should lead by example by installing SHA2 on our own websites.

Brian: I’m not saying we all move to SHA2, I’m saying we shouldn’t have certificates valid into 2017 with SHA1.

Ryan: There are market realities for why we’re all still using SHA1, but we need to find ways to ratchet up SHA2 so that other software vendors, site operators, and industry players see the move to SHA2.

Brian: Browser checks will be implemented regardless of what the Forum decides, but I think the purpose of this discussion is come up with a unified policy statement about this issue. I believe that if we adopt language similar to what Microsoft has said, then CAs will have something to point customers to as an industry-wide standard as background for explaining one way or another

Dean: I agree, but I don’t think we need to go beyond with additional requirements. We can’t have additional, different browser requirements.

Iñigo: Is this for just SSL?

Tom: No. All certificates.

Richard: In China, the big challenge is that online trade is in the billions of dollars and end users will have a problem.

Brian: But these big sites that do large amounts of business will be able to come up with solutions for their end users that are still on SHA1.

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.

Richard: But maybe government support in China will help.

Chris: If we can decide something here, then that will be of help with that.

Ben: For a ballot, is there anything more we need to say?

Dean: Let’s put the Microsoft language into a draft ballot and circulate it for discussion and comment.

Kirk: Let’s prepare a nice PDF white paper like what we have for the deprecation of internal server names for the Forum that explains what is going to happen. Microsoft has a list of devices that don’t support SHA2, which we can include in the white paper as appendix. The white paper would say, check the list now and if you’re device is on the list, switch that device out now because it won’t work with SHA2.

Ben: Good idea, because we have to remember to do outreach on this.

[End of discussion]

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

TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.

Ryan Sleevi

não lida,
28 de ago. de 2014, 18:30:2528/08/2014
para kirk...@trendmicro.com, rsl...@chromium.org, security-dev, blink-dev, steve...@gmail.com, net-dev
On Thu, Aug 28, 2014 at 3:18 PM, kirk...@trendmicro.com <kirk...@trendmicro.com> wrote:

Ryan – you keep saying Google told all CAs about this policy six months ago.  What are you referring to?  The CA/Browser Forum meeting in February?  You made no mention of this policy at that time.  See again the meeting minutes below from February 19, 2014.



Hi Kirk,

I fear you may have missed the messages on this thread where I've identified that for you particularly, and for others.


I note that I have already provided this link to you before, as shown on https://cabforum.org/pipermail/public/2014-August/003742.html

Hopefully you can take the opportunity to read it.


Kirk Hall

não lida,
28 de ago. de 2014, 18:36:2828/08/2014
para securi...@chromium.org, kirk...@trendmicro.com, rsl...@chromium.org, blin...@chromium.org, steve...@gmail.com, net...@chromium.org
Sorry, Ryan -- I don't see Google's new policy in any of those threads.  Can you point it out?

Ryan Sleevi

não lida,
28 de ago. de 2014, 18:40:1628/08/2014
para Kirk Hall, security-dev, Ryan Sleevi, blink-dev, steve...@gmail.com, net-dev
Hi Kirk,

I can't help but feel you're intentionally being misleading. I would encourage you to read it again and confer with your colleagues.

It was clear enough, and long enough, a discussion that  Bob (on behalf of Mozilla) was able to state it simply and succinctly in the text I conveniently highlighted for you in that thread. I'm not sure how there can be any ambiguity on that, and it's the exact same policy now being proposed here.

All the best,
Ryan

rick_a...@symantec.com

não lida,
28 de ago. de 2014, 18:49:5228/08/2014
para securi...@chromium.org, blin...@chromium.org, net...@chromium.org, rsl...@chromium.org
An unintended consequence of degrading the UI for SHA-1 certs might be that unencrypted (http) connections, which show no security warnings, might appear safer/better, at least to those folks who don’t pay a lot of attention to the browser chrome.

Ryan Sleevi

não lida,
28 de ago. de 2014, 18:51:1228/08/2014
para Rick Andrews, security-dev, blink-dev, net-dev, Ryan Sleevi
Luckily, we're working on that as well :)

Adrienne Porter Felt

não lida,
28 de ago. de 2014, 18:54:1528/08/2014
para rick_a...@symantec.com, security-dev, blink-dev, net-dev, Ryan Sleevi
HTTP makes no promises, which at least isn't a false promise.


On Thu, Aug 28, 2014 at 3:49 PM, <rick_a...@symantec.com> wrote:

Jeffrey Yasskin

não lida,
28 de ago. de 2014, 19:13:4028/08/2014
para steve...@gmail.com, blink-dev, securi...@chromium.org, net...@chromium.org, Ryan Sleevi
On Wed, Aug 27, 2014 at 12:14 PM, <steve...@gmail.com> wrote:

Ryan,

I support your endorsement of the previously communicated Microsoft policy sent directly to all CAs informing us of the 2016 and 2017 deprecation milestones.  In my own business, like many CAs, I am working on this task actively and I will achieve the two goals.

In the course of reviewing this discussion and the CABFPub posts, I feel that the conversation is devolving toward a door slam and I want to prevent that by sharing further perspective from my own experience.  I need to amplify the concerns of my friends who have already contributed great objections to the strategy. I want to point out areas where I feel that the conversation is getting counter-productive and subject to failure. 

I’m going to bulletize as a favor to weary eyes.

  • It is incorrect to conclude that because a certificate is issued for three years, it will live out those full three years regardless of compliance impacts.
  • It is fully within CA policy, practice, customer relationship, and software functionality to replace certificates that are about to enter a non-compliance period with those that are compliant at no cost.
  • Certificates being issued now out of compliance to the future milestones are issued by a CA knowing that they will be replaced.
https://cabforum.org/2014/02/19/2014-02-19-minutes-of-mountain-view-f2f/#SHA1-Sunsetting-Grandfathering-Strategy also includes a statement that "It’s not because we are trying to sell SHA1 certificates, it is that customers want to buy them.  Customers want to buy three-year certificates; they do not want to buy one-year certificates."

I don't know a whole lot about the CA business or Chrome's security decisions, but it seems misleading to your customers to sell them a certificate that claims to be valid for 3 years when you know it'll only be valid for 2 and will suddenly become really hard to replace in an emergency after 1.

Just because a customer asks for something impossible (a 3-year SHA-1 certificate) doesn't mean it's ok to tell them it's possible, and if the deadline isn't encoded in the certificate, there's no way for anyone else to verify what you've told the customer.  On the other side, if it's fully within CA customer relationship to replace a certificate within its purchased validity at no cost, it shouldn't be a problem to sell a 3-year certificate that's implemented as a several-month SHA-1 certificate freely replaceable with a 3-year SHA-2 certificate.

Jeffrey

Kirk Hall

não lida,
28 de ago. de 2014, 19:14:3928/08/2014
para securi...@chromium.org, kirk...@trendmicro.com, rsl...@chromium.org, blin...@chromium.org, steve...@gmail.com, net...@chromium.org
Ryan -- seriously -- if you can point us to where, in the strings you referenced, that Google's new policy was first disclosed to CAs, and if it was about six months ago, you will receive a full and abject public apology from me, and no further complaints about the new policy.

So please resolve this once and for all -- where and when exactly do you believe that Google first disclosed this new policy?  

Ryan Sleevi

não lida,
28 de ago. de 2014, 19:18:4428/08/2014
para Kirk Hall, security-dev, Ryan Sleevi, blink-dev, steve...@gmail.com, net-dev
In a discussion of SHA-1 deprecation:

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


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

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

kirk...@trendmicro.com

não lida,
28 de ago. de 2014, 19:29:1128/08/2014
para rsl...@chromium.org, security-dev, blink-dev, steve...@gmail.com, net-dev

Thanks.  But nothing in those snippets indicates that in August 2014 SHA-1 certificate users will be told by Google that they must switch out all their certs in 6-12 weeks or else their websites will receive untrusted UIs in Chrome – does it? 

 

As I mentioned before, our company already restricted our offerings so no customer can get a SHA-1 certificate expiring after 2016, so we are already in compliance.  Why are you effectively pushing back the SHA-1 deprecation deadline by two years on such short notice?

 

I think this is very unfortunate – Google seems angry at (some) CAs for past tardiness in transitions to stronger technologies (MD5, 1024 bit certs), but not all CAs are guilty and in any case this is a very punitive policy.

 

In fact, you are actually punishing website owners with perfectly valid SHA-1 certs who will be in full compliance with the SHA-1 deprecation policy by 2017 – they have done nothing wrong, but because of Google’s new August 2014 policy, they have to speed up compliance to this year, at a very inconvenient time for many.

 

Finally, in my opinion, you are effectively punishing Chrome users as well  (or confusing them, at the very least) by showing them “untrusted” Chrome UIs this fall for certs that are, in fact, perfectly valid under a 2017 SHA-1 deprecation policy – all in the name of social engineering (pushing website owners and CAs to move faster).  Is this really what you want to do to Chrome users with Chrome’s UI?  It’s like “crying wolf” – telling your own customers there is a problem with a website when there actually isn’t (you are just trying to make the website move faster).

 

Please listen to the people posting on this site and other sites, Ryan, and reconsider your timelines.  Do the right thing, and reset the deadline for March 1, 2015 or later.  That will accomplish all your stated purposes, and avoid hurting a lot of people (and Chrome users) unnecessarily.

 

From: sle...@google.com [mailto:sle...@google.com] On Behalf Of Ryan Sleevi
Sent: Thursday, August 28, 2014 4:19 PM
To: Kirk Hall (RD-US)
Cc: security-dev; Ryan Sleevi; blink-dev; steve...@gmail.com; net-dev
Subject: Re: Intent to Deprecate: SHA-1 certificates

 

In a discussion of SHA-1 deprecation:

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

Chris Palmer

não lida,
28 de ago. de 2014, 19:39:2328/08/2014
para kirk...@trendmicro.com, rsl...@chromium.org, security-dev, blink-dev, steve...@gmail.com, net-dev
On Thu, Aug 28, 2014 at 4:29 PM, kirk...@trendmicro.com
<kirk...@trendmicro.com> wrote:

> As I mentioned before, our company already restricted our offerings so no customer can get a SHA-1 certificate expiring after 2016, so we are already in compliance.

Great! Thank you.

> Why are you effectively pushing back the SHA-1 deprecation deadline by two years on such short notice?

SHA-1 is now, and has been for some time, deprecated. The deadline is
for when SHA-1 will be not just deprecated but *outright disabled*.

So, we are surfacing the deprecation *now*, so that all CAs will do as
Trend Micro has done, and won't suddenly be caught off-guard when
SHA-1 is indeed turned off as scheduled.

kirk...@trendmicro.com

não lida,
28 de ago. de 2014, 19:44:4128/08/2014
para Chris Palmer, rsl...@chromium.org, security-dev, blink-dev, steve...@gmail.com, net-dev
But Chris -- you are using a blunderbuss when you could use a high accuracy rifle (or better).

This policy is making compliant companies like Trend Micro contact all their customers now and make them replace all their SHA-1 certs (certs that all expire in 2014, 2015, and 2016) now -- when there is no need for that. Some customers have thousands of certs from many dozens of domains -- domestic and international. Why do we and our customers have to do this?

A six-month delay would still effectively eliminate all SHA-1 certs by the end of 2015 -- the same as Google's current deadline -- so you reach the same result. So why not give website owners and CAs some extra time to respond to this surprise policy? And get them past the holiday retail season website lockdown?

-----Original Message-----
From: Chris Palmer [mailto:pal...@google.com]
Sent: Thursday, August 28, 2014 4:39 PM
To: Kirk Hall (RD-US)
Cc: rsl...@chromium.org; security-dev; blink-dev; steve...@gmail.com; net-dev
Subject: Re: Intent to Deprecate: SHA-1 certificates

<table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential
and may be subject to copyright or other intellectual property protection.
If you are not the intended recipient, you are not authorized to use or
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></table>

Ryan Sleevi

não lida,
28 de ago. de 2014, 19:53:4628/08/2014
para kirk...@trendmicro.com, Chris Palmer, rsl...@chromium.org, security-dev, blink-dev, steve...@gmail.com, net-dev
So, I do feel that casting this policy in such violent iconography does no one any favors, especially not towards finding an amicable solution.

I suspect that, fundamentally, there's two disagreements:
- Dates
- Degree

With respect to degree, as noted in the proposal, we're discussing a "degraded UI indicator". It sounds like we're all in agreement that SHA-1 is not secure, as evidenced by TrendMicro's transition, so we shouldn't be misleading users and site operators as to it's security.

With respect to dates, our ability to rapidly respond to ongoing threats is limited by the ability of the industry to respond in advance. In this respect, and as evidenced on replies earlier asking for multi-year timelines, it seems we are also all in agreement that longer notice periods are better than shorter notice periods, especially if that longer notice period suddenly has to become a shorter notice period (e.g. as we narrowly avoided with MD5 and Flame).

So it would seem to benefit both our users and your customers (site operators) that this message is messaged as early as possible about coming changes, to help inform, educate, and transition.

So I'm not sure why you would want to delay that messaging, since while it may make it easier for CAs to transition their infrastructure, it may provide the customers, the users truly impacted by this, even less notice and time to prepare. I feel like we must put the customer first, as it were, and help provide ample lead time, while the CAs, who have not taken seriously the call to action of the past decade, begin their late transition.

kirk...@trendmicro.com

não lida,
28 de ago. de 2014, 19:55:2828/08/2014
para Chris Palmer, rsl...@chromium.org, security-dev, blink-dev, steve...@gmail.com, net-dev
Also, Chris -- who doesn't Google just deprecate SHA-1 certificates that expire on or after January 1, 2017 (now, or in six months) -- I can guarantee once that happens those certs will disappear, which is your stated goal -- and no new certs expiring in 2017 or later will ever be issued.

Why do you have to attack SHA-1 certs now that expire in 2016? If you just focus on certs expiring in 2017 or later, you will save thousands of website owners from needless switching of their current SHA-1 certs (when then will never be receiving SHA-1 replacement certs that expire in 2017).

This makes no sense -- can you explain why Google's SHA-1 early deprecation isn't limited to SHA-1 certs that expire in 2017 or later??? That would catch everything, and prevent issuance of new 2017 certs.

-----Original Message-----
From: Chris Palmer [mailto:pal...@google.com]
Sent: Thursday, August 28, 2014 4:39 PM
To: Kirk Hall (RD-US)
Cc: rsl...@chromium.org; security-dev; blink-dev; steve...@gmail.com; net-dev
Subject: Re: Intent to Deprecate: SHA-1 certificates

<table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential
and may be subject to copyright or other intellectual property protection.
If you are not the intended recipient, you are not authorized to use or
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></table>

kirk...@trendmicro.com

não lida,
28 de ago. de 2014, 19:57:2928/08/2014
para rsl...@chromium.org, Chris Palmer, security-dev, blink-dev, steve...@gmail.com, net-dev

Why not just limit your deprecation to SHA-1 certs that expire on or after January 1, 2017 – those in use, and those issued in the future?  That’s a much more logical way to accomplish this goal.

Ryan Sleevi

não lida,
28 de ago. de 2014, 20:21:3628/08/2014
para kirk...@trendmicro.com, Chris Palmer, rsl...@chromium.org, security-dev, blink-dev, steve...@gmail.com, net-dev
On Thu, Aug 28, 2014 at 4:55 PM, kirk...@trendmicro.com <kirk...@trendmicro.com> wrote:
Also, Chris -- who doesn't Google just deprecate SHA-1 certificates that expire on or after January 1, 2017 (now, or in six months) -- I can guarantee once that happens those certs will disappear, which is your stated goal -- and no new certs expiring in 2017 or later will ever be issued.

Why do you have to attack SHA-1 certs now that expire in 2016?  If you just focus on certs expiring in 2017 or later, you will save thousands of website owners from needless switching of their current SHA-1 certs (when then will never be receiving SHA-1 replacement certs that expire in 2017).

This makes no sense -- can you explain why Google's SHA-1 early deprecation isn't limited to SHA-1 certs that expire in 2017 or later???  That would catch everything, and prevent issuance of new 2017 certs.

Because as you well know from Microsoft's policy, the date for cessation of issuance isn't 2017, it's 2016. Mozilla's policy is clearer and even more to the point "CAs should not be issuing new SHA-1 certificates", without a date attached, and also notes "If a CA still needs to issue SHA-1 certificates for compatibility reasons, then those SHA-1 certificates should expire before 2017", which is more than the Microsoft policy requires (and is in line with our proposed UI changes and what we proposed to the CA/Browser Forum 6 months ago, to much reaction and rejection)

Again, going back to the earlier point, the site operator who obtained their 5 year certificate from TrendMicro in 2011 (or your CA of choice, since in either case, it's permissible and widely practiced, whether or not TrendMicro practices it), which expires in July 2016, needs to be aware that they, too, are affected by SHA-1 deprecation, as they will be unable to get a SHA-1 certificate when it comes time to renew their certificate.

They need to actively be communicating with their CA and working on SHA-256 transition plans, much the same as those with certificates expiring after 2017 (who will outright fail).

It would be truly unfortunate for a TrendMicro customer, possessing a certificate expiring during that busy Christmas shopping period of November-to-December 2016, with a wide variety of internal legacy systems, to find that they cannot get a certificate that will work in their infrastructure, because they failed to begin transitioning their infrastructure. Even if UAs support SHA-256, we both know (as do many of the CAs, as evidenced by things like Symantec's acknowledge BR violation) that legacy systems represent a real issue for CA's customers, beyond just user agents, and so we hope through our combined efforts, we will see the Internet as a whole transition to a more secure environment.

I can't see how delaying the messaging, which, as noted, affects Chrome users far beyond just CAs, and which affects CAs' customers far beyond just Chrome, would serve either of our respective goals.

Cheers,
Ryan

rowl...@gmail.com

não lida,
28 de ago. de 2014, 21:37:1128/08/2014
para securi...@chromium.org, blin...@chromium.org, net...@chromium.org, rsl...@chromium.org
Ryan,

You keep insinuating it's the CAs resisting improvements, but I think that is missing the point everyone is trying to make. Look at what's happened over the past year:
1. All website owners had to transfer to 2048 bit certs to comply with the Mozilla and Microsoft policy. This is despite the fact there were known incompatibilities with many legacy devices, particularly payment terminals.
2. Heartbleed required everyone to revoke and replace their certificate. This was a result of a security vulnerability in OpenSSL, not an issue with CAs or browsers.
3. Internal names deprecation was accelerated for certain gTLDs. Any entity using a name was forced to upgrade their non-complaint device and use an FQDN.
4. Microsoft announced a policy that all certs must be SHA2 as of 2017. CAs communicated this policy and replaced SHA1 certificates expiring in 2017 with new SHA2 certs.
5. Google announced a brand new policy that SHA1 certs would receive a warning. Again, each of these customers will need to replace their certs in the next 12 weeks.

Although the reason behind each of these replacement certs is valid, a website partnering with a completely compliant CA will have replaced their certificates five times this year!

I don't think the CAs posting here are necessarily concerned about burdnes on the CA - improved security is important and bearing these costs is part of participating in the industry. What's concerning is the sporadic timing of these events and the ability of website owners to comply with the changes, especially two separate SHA2 transitions. Having to replace a certificate five times is difficult for enterprises with set roll-out periods to swallow. Not every company is Google, and most can't make this many changes to their infrastructure without causing issues. Seemingly sporadic and uncoordinated improvements makes TLS, something most people already don't understand, even more difficult to effectively deploy and maintain.

The CAB Forum was founded to consolidate these type of announcements and changes. If the browsers can coordinate (one of the purposes of having a Browser forum), the entire community would become more successful in implementing these changes.

Jeremy

kirk...@trendmicro.com

não lida,
28 de ago. de 2014, 21:44:4928/08/2014
para rsl...@chromium.org, Chris Palmer, security-dev, blink-dev, steve...@gmail.com, net-dev, CABFPub (public@cabforum.org)

Ryan, I think you have misinterpreted both Microsoft’s and Mozilla’s policies.

 

Microsoft says “issue no new SHA-1 certs on or after 1/1/2016” – but SHA-1 certs issued before that date that expire by 12/31/2016 are ok – they don’t need to be switched out, now or later.  Only SHA-1 certs expiring in 2017 are invalid.

 

Mozilla’s policy is more or less the same – SHA-1 certs will be treated as valid through 12/31/2016.  CAs should refrain from issuing any new ones now (even those expiring in 2016), but may do so if the customer says it’s necessary for compatibility reasons.  Only SHA-1 certs expiring in 2017 are invalid.

 

So 2016 SHA-1 certs are ok with both browsers – but 2017 certs are not.

 

I can assure you that any Trend Micro customer who has a SHA-1 cert expiring in Nov. or Dec. 2016 (there are no such customers today – we only issue one-year and two-year certs) will know from us well in advance what is coming.  Maybe we will pull back our maximum validity date for new SHA-1 certs to earlier than Nov. 2016 – it’s something to think about.

 

I can also assure you that a Trend Micro customer with SHA-1 certs expiring in the first half of 2016 would much rather receive reminders and pestering notices from us over the next 18 months to change to SHA-256 (as they will) than to have to change hundreds of 2016 certs today and again in 2015  – no question about it.

 

From: sle...@google.com [mailto:sle...@google.com] On Behalf Of Ryan Sleevi
Sent: Thursday, August 28, 2014 5:22 PM
To: Kirk Hall (RD-US)
Cc: Chris Palmer; rsl...@chromium.org; security-dev; blink-dev; steve...@gmail.com; net-dev
Subject: Re: Intent to Deprecate: SHA-1 certificates

 

 

 

On Thu, Aug 28, 2014 at 4:55 PM, kirk...@trendmicro.com <kirk...@trendmicro.com> wrote:

TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.

Ryan Sleevi

não lida,
28 de ago. de 2014, 21:45:0628/08/2014
para Jeremy Rowley, security-dev, blink-dev, net-dev, Ryan Sleevi
On Thu, Aug 28, 2014 at 6:37 PM, <rowl...@gmail.com> wrote:
Ryan,

You keep insinuating it's the CAs resisting improvements, but I think that is missing the point everyone is trying to make.  Look at what's happened over the past year:
1. All website owners had to transfer to 2048 bit certs to comply with the Mozilla and Microsoft policy.  This is despite the fact there were known incompatibilities with many legacy devices, particularly payment terminals.
2. Heartbleed required everyone to revoke and replace their certificate.  This was a result of a security vulnerability in OpenSSL, not an issue with CAs or browsers.
3. Internal names deprecation was accelerated for certain gTLDs. Any entity using a name was forced to upgrade their non-complaint device and use an FQDN.
4. Microsoft announced a policy that all certs must be SHA2 as of 2017.  CAs communicated this policy and replaced SHA1 certificates expiring in 2017 with new SHA2 certs.
5. Google announced a brand new policy that SHA1 certs would receive a warning.  Again, each of these customers will need to replace their certs in the next 12 weeks.

Although the reason behind each of these replacement certs is valid, a website partnering with a completely compliant CA will have replaced their certificates five times this year!

Don't you think that should highlight something concerning? Both 1 and 3 were issues that CAs had significant advance notice of, and could have been gradually phased in with their customers. I truly feel for the users, but it seems unfair to suggest that the CA could not have been proactively messaging this over several years.

Regarding 4, we know that some CAs did, but a vast majority did not, and even more CAs have opposed this, as demonstrated by the CA/Browser Forum discussions. If you were one of the CAs that did, I applaud you. However, your users with SHA-1 certificates expiring in 2016 are just as much in need of beginning to migrate, and be aware of the need for that.

However, I want to make sure you realize that, again, this policy is more than just CAs. When we deprecated MD5 - with fewer than 1% of the certificates our users recorded (via the opt-in metrics reporting) - we still saw large and significant disruptions caused by this. It's in the interest of the entire industry, and not just CAs, to welcome the migration away from SHA-1.

rowl...@gmail.com

não lida,
28 de ago. de 2014, 22:55:0728/08/2014
para securi...@chromium.org, blin...@chromium.org, net...@chromium.org, rsl...@chromium.org
I think nearly all of the CAs provided advanced notice of each of these events to the customer well in advance of any of these changes - and the fact most of them couldn't make the transitions until the end illustrates the very concern (and why each of the dates were chosen). Many of these certificate users are supporting legacy devices. They are slow to transition simply because doing so is nearly impossible for their community. For the 1024 bit transition, we saw many certificate users elect to use private roots rather than transition, deciding the difficulty in installing a root in every trust store is easier than migrating the equipment. I think the fact that TERENA is listed as a major issuer of these certificates is a significant indicator that there are certain communities that are simply not prepared to meet a 2014 SHA2 deadline.

All of our customers using a SHA1 cert are well aware of the need transition to SHA2. In fact, that's why we don't have certificates expiring in 2017 - they've already started making the change. The certs you identified as expiring in 2016 are using that time to transition. A warning isn't necessary - it's already in the works.

Each of them are on a path towards implementing. Accelerating this process to 12 weeks (a UI degradation is a deprecation) interferes with all of those deprecation plans and cycles. The pain isn't on the CA here (any of our customers can replace their SHA1 with a SHA2 for free). It's on the website owners scrambling to meet a new deadline.

Chris Palmer

não lida,
29 de ago. de 2014, 00:41:2829/08/2014
para rowl...@gmail.com, rsleevi, net-dev, security-dev, blink-dev

On Aug 28, 2014 6:37 PM, <rowl...@gmail.com> wrote:

> You keep insinuating it's the CAs resisting improvements,

On the Mozilla list we've got Kathleen trying to cope with CAs who are trying to hide the particulars of their non-compliance with the BRs — requirements which CAs themselves helped draft. So that doesn't exactly look good, you have to admit.

> 1. All website owners had to transfer to 2048 bit certs to comply with the Mozilla and Microsoft policy.  This is despite the fact there were known incompatibilities with many legacy devices, particularly payment terminals.

As we noted at the time, what POS machines (e.g.) are willing to/have to accept is irrelevant to the public web PKI.

> 2. Heartbleed required everyone to revoke and replace their certificate.  This was a result of a security vulnerability in OpenSSL, not an issue with CAs or browsers.

Yes, that was very sad for everyone. Say, do CAs want to help us find and fix bugs in crypto libraries? It's a big job, so any engineering help you can offer is welcome.

> 3. Internal names deprecation was accelerated for certain gTLDs. Any entity using a name was forced to upgrade their non-complaint device and use an FQDN.

CAs could have avoided this problem by not issuing certificates for names, and IP addresses, that they could not possibly have verified.

> 4. Microsoft announced a policy that all certs must be SHA2 as of 2017.  CAs communicated this policy and replaced SHA1 certificates expiring in 2017 with new SHA2 certs.

Maybe some CAs, but we know for sure some others were hoping SHA-1 deprecation would go away, or that we'd forget about it. If everyone had taken it as seriously as you, we wouldn't be having this anxiety right now.

> 5. Google announced a brand new policy that SHA1 certs would receive a warning.  Again, each of these customers will need to replace their certs in the next 12 weeks.

Only if one ignores fairly clear statements from 6 months ago. Keep in mind that it's already 12 *years* after we've known from public literature that SHA-1 is significantly weaker than its designed guarantee. Who knows what the spooks have known, for how long.

> Although the reason behind each of these replacement certs is valid, a website partnering with a completely compliant CA will have replaced their certificates five times this year!

Software is a process, not a product. We browsers have to ship a new stable release every 6 – 8 weeks, because that's what it takes.

Chris Palmer

não lida,
29 de ago. de 2014, 00:53:4729/08/2014
para Jeremy Rowley, blink-dev, security-dev, rsleevi, net-dev


> Only if one ignores fairly clear statements from 6 months ago. Keep in mind that it's already 12 *years* after we've known from public literature that SHA-1 is significantly weaker than its designed guarantee.

Oops, 9 years now; 12 years in 2017. Sorry about that.

kirk...@trendmicro.com

não lida,
29 de ago. de 2014, 01:09:0529/08/2014
para Chris Palmer, Jeremy Rowley, blink-dev, rsleevi, net-dev, CABFPub (public@cabforum.org)

Chris – a serious question.  Is it true that  google.com is still using SHA-1 in both end-entity and intermediate certificates today (as has been posted to this site)?  If so, how can Google be so condemning of ordinary websites that are also using SHA-1 certs today, even though there has been discussion of SHA-1’s potential weakness, as you say, for several years?

 

So many of the postings on this topics have shown a strong antipathy toward CAs – toward ALL CAs, without making any distinctions.  Google is painting everyone with the same brush.  How can we turn this around, and create a more collaborative environment among browsers, browser users, CAs, website owners?

 

Google’s current policy will be creating a kind of chaos for many website owners in the next few weeks who have no idea why this is happening.  It will be affecting websites that have already started transition plans to SHA-256 certs before 2017.  Isn’t there a better way?

 

From: securi...@chromium.org [mailto:securi...@chromium.org]
Sent: Thursday, August 28, 2014 9:54 PM
To: Jeremy Rowley
Cc: blink-dev; security-dev; rsleevi; net-dev
Subject: Re: Intent to Deprecate: SHA-1 certificates

 

> Only if one ignores fairly clear statements from 6 months ago. Keep in mind that it's already 12 *years* after we've known from public literature that SHA-1 is significantly weaker than its designed guarantee.

Oops, 9 years now; 12 years in 2017. Sorry about that.

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

TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.

steve...@gmail.com

não lida,
29 de ago. de 2014, 09:46:5229/08/2014
para blin...@chromium.org, securi...@chromium.org, net...@chromium.org, rsl...@chromium.org
It has become clear that this is not a discussion or a venue for discussion, so there is no point to this thread being open any longer.  A proper statement communicated directly to all CAs should be the next step prior to Google taking action that damages the trust reputation of thousands of certificate buyers. 

The unwillingness to account for logistics and seasonal issues of major businesses that fuel the economy SSL enables in a reasonable timeframe is now documented for CAs to show to our customer bases by including a link to this thread in our customer broadcasts.  It has been clearly demonstrated that the CA population did not construe the February CABF meeting to imply that the planned action will occur.  Each of us now has a base of response from other CAs such that none of us appear negligent in interpretation of the February message.

bruce....@entrust.com

não lida,
29 de ago. de 2014, 12:43:1929/08/2014
para securi...@chromium.org, blin...@chromium.org, net...@chromium.org, rsl...@chromium.org
Ryan Hurst has posted what the Chrome SHA1 warning will look like, http://unmitigatedrisk.com/?p=474. Can this be confirmed? In any case, can images for the warning be provided which will help support messaging.
Thanks, Bruce.

Adrienne Porter Felt

não lida,
29 de ago. de 2014, 12:46:3229/08/2014
para bruce....@entrust.com, security-dev, blink-dev, net-dev, Ryan Sleevi
No, that cannot be confirmed yet. We're still hammering out precise details of UI treatment and timing. Please wait for an official blog post.

rowl...@gmail.com

não lida,
29 de ago. de 2014, 12:51:5429/08/2014
para securi...@chromium.org, rowl...@gmail.com, rsl...@chromium.org, net...@chromium.org, blin...@chromium.org
> > You keep insinuating it's the CAs resisting improvements,
>
> On the Mozilla list we've got Kathleen trying to cope with CAs who are trying to hide the particulars of their non-compliance with the BRs — requirements which CAs themselves helped draft. So that doesn't exactly look good, you have to admit.

[JR] While it's true that not all CAs are equal, from the Mozilla forum, it sounds like the non-compliant CAs are primarily those that don't participate in the CAB Forum. I think everyone here supports Browsers enforcing BR compliance (which is why the link about using UI to show compliance is non-controversial). Regardless, whether a few CAs are less capable of adapting to meeting industry standards is not really relevant to the impact this will have on website operators and end users.

>
> > 1. All website owners had to transfer to 2048 bit certs to comply with the Mozilla and Microsoft policy.  This is despite the fact there were known incompatibilities with many legacy devices, particularly payment terminals.
>
> As we noted at the time, what POS machines (e.g.) are willing to/have to accept is irrelevant to the public web PKI.
[JR] I don't disagree with your conclusion (or with the requirement or timeline). My point is that the 1024 bit cert users were required to update for the change in policy.

>> 2. Heartbleed required everyone to revoke and replace their certificate.  This was a result of a security vulnerability in OpenSSL, not an issue with CAs or browsers.
>
> Yes, that was very sad for everyone. Say, do CAs want to help us find and fix bugs in crypto libraries? It's a big job, so any engineering help you can offer is welcome.
[JR] We should be helping. I know we've contributed in the past, and I hope we are still doing so. We contribute wherever we can, including in industry standards groups and in projects that progress security (such as CT).

> > 3. Internal names deprecation was accelerated for certain gTLDs. Any entity using a name was forced to upgrade their non-complaint device and use an FQDN.
>
> CAs could have avoided this problem by not issuing certificates for names, and IP addresses, that they could not possibly have verified.
[JR] The rightness or wrongness has been debated several times over at the CAB Forum. Regardless of which side you fall on, this was still a transition that affected a significant number of website operators who thought they were totally compliant with industry standards.

> > 4. Microsoft announced a policy that all certs must be SHA2 as of 2017.  CAs communicated this policy and replaced SHA1 certificates expiring in 2017 with new SHA2 certs.
>
> Maybe some CAs, but we know for sure some others were hoping SHA-1 deprecation would go away, or that we'd forget about it. If everyone had taken it as seriously as you, we wouldn't be having this anxiety right now.
[JR] I appreciate that. I can't speak for the other CAs so I'm not sure what others have done to transition.

> > 5. Google announced a brand new policy that SHA1 certs would receive a warning.  Again, each of these customers will need to replace their certs in the next 12 weeks.
>
> Only if one ignores fairly clear statements from 6 months ago. Keep in mind that it's already 12 *years* after we've known from public literature that SHA-1 is significantly weaker than its designed guarantee. Who knows what the spooks have known, for how long.
[JR] I think from the messages received, there was obviously some confusion on the statements. Although the debate on the clarity of the statements is interesting, I don't think it helps us move forward with where we are at now. My main concern is the website operators who don't know the 2016 date is coming. I'd really like to work with Google in finding a less-painful way for hundreds of thousands of domains to move to SHA2, especially over the next 12 weeks.

> > Although the reason behind each of these replacement certs is valid, a website partnering with a completely compliant CA will have replaced their certificates five times this year!
>
> Software is a process, not a product. We browsers have to ship a new stable release every 6 – 8 weeks, because that's what it takes.
[JR] Google software ships every 6-8 weeks, but there are hardware concerns, server software considerations, and the technical skills of small/medium businesses in upgrading everything. I appreciate how easy it has become to get new browser updates and hope that soon all software vendors will follow suite.

I guess I've said my two cents by now. Really, I'm just hoping we can find a way as an internet community to work together to make this easier on everyone. I imagine there will always be some resistance to change, but, for the most part, I think everyone here is just looking for ways to make this happen without causing a lot of confusion and panic. I appreciate your consideration on this and look forward to figuring something out that benefits everyone.

Brian Smith

não lida,
29 de ago. de 2014, 13:15:4629/08/2014
para Chris Palmer, Ryan Sleevi, blink-dev, security-dev, net-dev
On Mon, Aug 25, 2014 at 3:59 PM, 'Chris Palmer' via net-dev
<net...@chromium.org> wrote:
> On Mon, Aug 25, 2014 at 3:46 PM, Brian Smith <br...@briansmith.org> wrote:
>
>> 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.
>
> Well, what about Twitter? I don't have a sufficiently-old computer to
> be sure, but it looks like Twitter uses an EE cert signed with SHA-256
> + RSA.
>
> Maybe Twitter is distinguishing SHA-256 capable vs. non-capable
> clients, and serving different chains? Otherwise, a site as important
> as Twitter seems to be OK with not working on old platforms.
>
> And if that's true, maybe nobody else needs to care, either? Very few
> sites can claim to be a bigger deal than Twitter...

In the last week, I've talked to quite a few people that seem to think
that Chrome-on-XP-SP<3 marketshare is big enough to care about, even
if Twitter doesn't seem very concerned about it. Also note that I've
been told that https://api.twitter.com does use SHA-1 certificates at
least for some clients (I was told that this was done for Blackberry
clients, specifically. I don't know the details). Also see Nick's
email in this thread, of which I quote the relevant part here:

On Fri, Aug 22, 2014 at 12:36 PM, Nick Sullivan <ni...@cloudflare.com> wrote:
> 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.

Also, I am not concerned about websites that have already switched to
(or enabled) HTTPS. I am more concerned about websites that haven't
yet provided an HTTPS mode, like baidu.com (Alexa #5), amazon.com
(Alexa #8), and qq.com (Alexa #9), and websites that haven't switched
to HTTPS-by-default yet (e.g. Wikipkedia, which is Alexa #6). It seems
likely that these types of websites are less likely to be willing to
trade off their Chrome-on-SP<3 users to do SHA-2. I worry that they
may, instead, just avoid switching to HTTPS-by-default, which would be
a negative result.

Therefore, I think it is likely worthwhile to find some solution so
that a site can use SHA-1 certificates for Chrome-on-Windows-XP-SP<3.
I think there are three types of solutions:

1. Some kind of indicator of the lack of SHA-2 support could be added
to the TLS 1.2 handshake of Chrome on SP<3; either a proposed standard
mechanism (preferable) or a totally proprietary mechanism.

2. On XP<3, when certificate validation fails and the end-entity
certificate was signed with a SHA-2-based signature algorithm, Chrome
could fall back to the NSS-based certificate verification that is is
(was?) using on Linux-ish platforms, as the NSS-based verification
logic does support SHA-2. The presumption you would have to make here
is that nobody using SP<3 is using group policy to disable root CAs
that are trusted by NSS, and/or they just don't care too much about
managing root CAs. Some websites (websites using custom trust anchors)
still wouldn't work on SP<3, but most public websites would work
(evidence: pretty much all websites have been working with Firefox for
a long time, and Firefox used the NSS-based certificate verification
for a long time.)

3. Similar to #2, on XP<3 you could fall back to using the
mozilla::pkix verification logic in conjunction with the Windows
certificate store instead of the NSS certificate store.

I feel like #1 is something that doesn't require too much effort. I
think #3 and #2 are more complete solutions (since everything would
"just work"), but probably not worth the effort, risk, or delay they
would bring.

Again, I think asking websites to drop support for Chrome on Windows
XP SP<3 is not unreasonable, but nobody I've talked to seems to like
that idea, because there is a risk that it would cost them lost
revenue. Perhaps they could be reassured if they had some evidence
that Chrome on XP<3 marketshare is very low, but I think that might
not be the case.

Cheers,
Brian

Ryan Sleevi

não lida,
29 de ago. de 2014, 13:20:1029/08/2014
para Brian Smith, blink-dev, net-dev, security-dev, Chris Palmer

Or

4) Chrome doesn't support XP<SP3, as an insecure and out of date system, and helps the user install the necessary security patches, such as through a user alert when they launch Chrome warning they are out of date and will be unable to access sites and securely browse the web.

Brian Smith

não lida,
29 de ago. de 2014, 13:53:4729/08/2014
para Ryan Sleevi, blink-dev, net-dev, security-dev, Chris Palmer
On Fri, Aug 29, 2014 at 10:20 AM, Ryan Sleevi <rsl...@chromium.org> wrote:
>> 1. Some kind of indicator of the lack of SHA-2 support could be added
>> to the TLS 1.2 handshake of Chrome on SP<3; either a proposed standard
>> mechanism (preferable) or a totally proprietary mechanism.
>
> Or
>
> 4) Chrome doesn't support XP<SP3, as an insecure and out of date system, and
> helps the user install the necessary security patches, such as through a
> user alert when they launch Chrome warning they are out of date and will be
> unable to access sites and securely browse the web.

Like I said, I think that is fine.

Going back to your original email:

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

So websites that are unwilling to drop support for Chrome-on-SP<3
users can work around this issue by giving all Chrome users (or all
users) a SHA-1-based certificate with notAfter < 2016-01-01, waiting
to switch to SHA-2 only in late 2015, right? Hopefully by 2016
Chrome-on-SP2 usage will be low enough that no websites will care
about dropping support for that configuration. I was hoping to find a
solution that didn't encourage people to wait until 2016 to do SHA-2,
but I can understand why some people would prefer that, as it is
simplest for everybody involved.

Anyway, I don't mean to muck up your thread. Multiple people have
asked me for advice about this issue, so I thought it would be worth
recording the results of that brainstorming here where other people
can find it.

Cheers,
Brian

Ryan Sleevi

não lida,
29 de ago. de 2014, 14:02:5729/08/2014
para Brian Smith, blink-dev, security-dev, net-dev, Chris Palmer


On Aug 29, 2014 10:53 AM, "Brian Smith" <br...@briansmith.org> wrote:
>
> On Fri, Aug 29, 2014 at 10:20 AM, Ryan Sleevi <rsl...@chromium.org> wrote:
> >> 1. Some kind of indicator of the lack of SHA-2 support could be added
> >> to the TLS 1.2 handshake of Chrome on SP<3; either a proposed standard
> >> mechanism (preferable) or a totally proprietary mechanism.
> >
> > Or
> >
> > 4) Chrome doesn't support XP<SP3, as an insecure and out of date system, and
> > helps the user install the necessary security patches, such as through a
> > user alert when they launch Chrome warning they are out of date and will be
> > unable to access sites and securely browse the web.
>
> Like I said, I think that is fine.
>
> Going back to your original email:
>
> > - 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.
>
> So websites that are unwilling to drop support for Chrome-on-SP<3
> users can work around this issue by giving all Chrome users (or all
> users) a SHA-1-based certificate with notAfter < 2016-01-01, waiting
> to switch to SHA-2 only in late 2015, right?

Yes.

> Hopefully by 2016
> Chrome-on-SP2 usage will be low enough that no websites will care
> about dropping support for that configuration.

I think no website should care now, the percentage is so low, but as mentioned, this is also about Chrome no longer supporting this config.

At some point, we as an industry have to be able to deprecate things, and I'm not sure what more can be done for these users that hasn't already been said.

Put differently, if Chrome doesn't support users on XP<SP3, what's the issue?

> I was hoping to find a
> solution that didn't encourage people to wait until 2016 to do SHA-2,
> but I can understand why some people would prefer that, as it is
> simplest for everybody involved.
>
> Anyway, I don't mean to muck up your thread. Multiple people have
> asked me for advice about this issue, so I thought it would be worth
> recording the results of that brainstorming here where other people
> can find it.
>

That's the entire point of this thread - to find and understand the issues from the community.

Sure, the vast majority of this thread has been spent correcting misstatements and inaccuracies, or explaining that the issue is broader than one particular market (e.g. it includes ISVs, enterprises, schools, antivirus, etc) or one particular class of user (that 2016 cert holders are as affected as 2017 cert holders, even though things don't go away until 2017)

However, understanding real affects, seeing proposals for real timelines and what and how that time will be used differently than the past 6 months (CA/B Forum), 3 years (Baseline Requirements), or 9 years (known broken) is all helpful in factoring in the many tradeoffs and goals.

In particular, thanks for exploring real and meaningful solutions that help balance the full concerns, as well as providing real details for when and where those solutions don't work.

> Cheers,
> Brian

Brian Smith

não lida,
29 de ago. de 2014, 14:21:5729/08/2014
para Ryan Sleevi, blink-dev, security-dev, net-dev, Chris Palmer
On Fri, Aug 29, 2014 at 11:02 AM, Ryan Sleevi <rsl...@chromium.org> wrote:
>Brian Smith wrote:
>> Hopefully by 2016
>> Chrome-on-SP2 usage will be low enough that no websites will care
>> about dropping support for that configuration.
>
> I think no website should care now, the percentage is so low, but as
> mentioned, this is also about Chrome no longer supporting this config.
>
> At some point, we as an industry have to be able to deprecate things, and
> I'm not sure what more can be done for these users that hasn't already been
> said.
>
> Put differently, if Chrome doesn't support users on XP<SP3, what's the
> issue?

It was expressed to me like this (paraphrasing): "We prefer customers'
computers to be secure. But we prefer to be able to let customers give
us money much more than we prefer their computer to be secure." Also,
it seems websites have trouble differentiating XP<3 traffic from SP3
traffic, so they do not know, like you do, that the percentage is so
low that it isn't worth supporting.

(Incidentally, I have a hypothesis that AES-NI hardware is negatively
correlated with SP<3, and so the fact that Chrome's cipher suite list
is in a different order when AES-NI is present might be helpful for
people who are still interested in switching to SHA-2 with reduced
risk, though it isn't going to be perfect.)

Cheers,
Brian
Mais mensagens estão sendo carregadas.
0 nova mensagem