[cabfpub] Request for six month delay on new Google SHA-1 deprecation policy
kirk_hall at trendmicro.com
kirk_hall at trendmicro.com
Thu Aug 28 15:22:30 MST 2014
[Reposting from Google SHA-1 list]
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
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: 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]
From: sleevi at google.com [mailto:sleevi at google.com] On Behalf Of Ryan Sleevi
Sent: Thursday, August 28, 2014 3:10 PM
To: Kirk Hall (RD-US)
Cc: security-dev; blink-dev; steve.medin at gmail.com; net-dev; Ryan Sleevi
Subject: Re: Intent to Deprecate: SHA-1 certificates
On Thu, Aug 28, 2014 at 2:34 PM, Kirk Hall <kirk_hall at trendmicro.com<mailto:kirk_hall at 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.
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev+unsubscribe at chromium.org<mailto:security-dev+unsubscribe at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 168 bytes
Url : https://cabforum.org/pipermail/public/attachments/20140828/856fcfef/attachment-0001.png
More information about the Public