[cabfpub] Google decision to impose a negative UI for SHA-1 certificates in 6-12 weeks

kirk_hall at trendmicro.com kirk_hall at trendmicro.com
Mon Aug 25 16:02:43 MST 2014


Ryan, I was responding to your message below on the Public list for the CAB Forum.

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi
Sent: Monday, August 25, 2014 8:51 AM
To: Dean Coclin
Cc: CABFPub
Subject: Re: [cabfpub] Agenda for Beijing F2F 16-18 September 2014


Small correction:
sudden -> recent
very little notice -> six months notice

I'm not sure that there is much to discuss, however, at least not within the Forum. Chromium has announced plans for UI changes that had previously been discussed at length in the Forum during our F2F in February. There is already a venue for discussing these changes, one which permits and encourages full public participation, and we welcome further contributions.

I suspect that such a conversation in the Forum, with or without Google's participation, would thus be nonproductive, unless the proposal is that we reexamine codifying these dates in the BRs, a move we would certainly welcome.


From: Ryan Sleevi [mailto:sleevi at google.com]
Sent: Monday, August 25, 2014 4:56 PM
To: Kirk Hall (RD-US)
Cc: CABFPub (public at cabforum.org)
Subject: Re: [cabfpub] Google decision to impose a negative UI for SHA-1 certificates in 6-12 weeks

Happy to continue discussing this in the proper forum, which, as has been noted in the past, is https://groups.google.com/a/chromium.org/d/msg/security-dev/2-R4XziFc7A/NDI8cOwMGRQJ

In which the relevant bits for the minutes were already provided. specifically https://groups.google.com/a/chromium.org/d/msg/security-dev/2-R4XziFc7A/OAvNrBvhD5QJ

On Mon, Aug 25, 2014 at 3:46 PM, kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com> <kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com>> wrote:
Ryan, you have indicated in a couple of emails that Google warned CAs six months ago about its plans for SHA-1.  I assume you mean at the CA/Browser Forum meeting at Google’s office in February?  If so, I have pasted in the minutes below – it’s not clear to me from these minutes that Google was going to require users with SHA-1 certificates expiring after 2015 to replace those certs in 2014 or have a negative UI in Google.
The Minutes from the meeting speak for themselves, but my general recollection of the discussion is as follows.

•         Everyone acknowledged that Microsoft was dropping support for SHA-1 as of January 1, 2017 (and no new SHA-1 certs could be issued starting Jan. 1, 2016 to help prepare for this change), but Microsoft said it might move the date forward or backward, depending on circumstances.  Everyone was in support of eliminating SHA-1.

•         We discussed putting a sunset date for SHA-1 in the Baseline Requirements, but  given that Microsoft said it might change the sunset date, it made little sense to fix a date in the BRs that could then be changed based on Microsoft’s future decisions.

•         Google indicated it also supported SHA-1 phase-out.

•         We then discussed different ways to notify users and complete the transition of all sites to SHA-2 (or better) by the start of 2017.
My company, Trend Micro, only issues one- and two-year certs, and we have already modified our systems so that no customer can get a SHA-1 certificate that expires after Dec. 31, 2016.  So we don’t need any help in getting all our customers to SHA-2 by 2017.  But Google’s new policy means we now have to move a large group of our customers to new one-year SHA-1 certs (or SHA-2 certs for those customers whose systems can work with SHA-2) over the next 6-12 weeks, which was totally unexpected and in the case of our customers serves no real purpose.
You have mentioned that Google is trying to avoid a “flag day” on January 1, 2017 – a worthy goal, but that was never going to happen for any of our customers.  By forcing most SSL certificate customers to change out all their SHA-1 certs in the next 6-12 weeks, Google is more or less creating a “flag day” in the next 6-12 weeks, for relatively little benefit.
Wouldn’t it make more sense for Google to impose its rules in a later Chrome release (after Chrome 39) – such as six months from now – to avoid this upcoming flag day?  Google can apply its policy of showing a negative UI for SHA-1 certs that expire in 2016 and 2017 (so Google will accomplish its stated goals of making users start the change soon, and not wait until the end of 2016), but will be giving users more time to adjust.
Please understand that CAs have virtually no trouble in issuing / reissuing short term SHA-1 certs and new SHA-2 certs to their customers, so by pushing out the date of Google’s new policy by six months Google would not be doing CAs a favor.  However, no matter how hard CAs try to tell customers what’s coming from Google in the next few weeks, not all customers will be able to respond in Google’s preferred time frame.  What’s the harm in moving this flag day out a few months so users have more time to react?
Here are the minutes from the February Forum meeting:
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 ***
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: :-)]
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.
Kirk R. Hall
Operations Director, Trust Services
Trend Micro
+1.503.753.3088<tel:%2B1.503.753.3088>


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.



_______________________________________________
Public mailing list
Public at cabforum.org<mailto:Public at cabforum.org>
https://cabforum.org/mailman/listinfo/public


<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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20140825/ebbd2d26/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 168 bytes
Desc: image001.png
Url : https://cabforum.org/pipermail/public/attachments/20140825/ebbd2d26/attachment-0001.png 


More information about the Public mailing list