(I work for Mozilla, but this email doesn't necessarily reflect the views of Mozilla).
Hi Steve, I appreciate Symantec taking the time to put this together. There's a lot of unpack here, so I wanted to zoom in on one portion of it. When discussing the feedback you received from enterprise customers, and the impact that Google's proposed change would have, one of the challenges you highlight is for customers who have pinned certificates, from mobile apps to embedded devices. I find this a bit perplexing, Google's current proposal does not remove trust in the existing Symantec roots, it merely accelerates the expiration of existing end-entity certs, and caps the lifetime of future certs. While I'm happy to grant that re-issuance can be a time consuming procedure for large organizations which have failed to automate certificate issuance and deployment (hopefully this is something they're working on!), this challenge is more or less unrelated to needing to change pinned roots/trust stores. In short, Symantec appears to be describing potential fallout from a total distrust, which is not what Google's Intent to Deprecate thread proposed. Can you speak to why Symantec chose to focus on this issue? Thanks, Alex On Wed, Apr 26, 2017 at 8:48 PM, Steve Medin via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > -----Original Message----- > > From: dev-security-policy [mailto:dev-security-policy- > > bounces+steve_medin=symantec....@lists.mozilla.org] On Behalf Of > > Gervase Markham via dev-security-policy > > Sent: Friday, April 21, 2017 6:17 AM > > To: mozilla-dev-security-pol...@lists.mozilla.org > > Subject: Symantec Conclusions and Next Steps > > > [snip] > > > > Symantec have also written to Mozilla to say the following: > > > > "We have been working hard on a thorough and thoughtful proposal that > > responds to community questions and concerns regarding our compliance > > and issuance practices. In drafting this proposal, we’ve thoughtfully > > considered the feedback posted on the Mozilla forums along with comments > > on the Google forums and other community feedback. We’ve also solicited > > input from our customers who are the ones that would bear the impact of > > changes, whether as a result of our proposal or any other. > > > > We plan to send a proposal for Mozilla’s and the community’s > consideration > > on Wednesday April 26th that addresses these important areas: > > > > * The Integrity of our EV Validation Process > > * Validity of Existing Certificates > > * Increased Transparency > > * Move to Shorter Validity Certificates > > * Continuous Improvement of our CA Operations" > > > > This date is in the middle of next week. We permitted WoSign to propose a > > remediation plan; I think it is reasonable to do the same for Symantec. > So we > > will wait to hear what they have to say, and then discuss appropriate > action in > > the light of it. > > > > Gerv > > > > Symantec CA Response to Google Proposal and Community Feedback > > We take our role as a key player in the trust ecosystem of the Internet > very seriously. We believe that secure and compliant issuance of SSL/TLS > certificates is fundamental to the security of the Internet and that we > have a responsibility to collaborate with our customers and the broader > community to continuously improve industry standards, and specifically our > practices, for certificate issuance. > > On March 23, Google posted a blog outlining a proposal to change how > Symantec’s SSL/TLS certificates are recognized in Chrome. Their proposal > stemmed from prior certificate mis-issuances that occurred in our > Certificate Authority (CA) business, which we have taken extensive > remediation measures to correct. We have carefully reviewed Google’s > proposal and sought input from the broader browser and user community on > this topic, which has informed our continuous improvement planning. This > post outlines important measures that we propose to implement in our CA > business. We believe our proposal addresses the concerns raised by Google > about our CA business without imposing undue business disruption on our > customers and Chrome users that we believe would result if Google > implements its proposal. > > Feedback from our Enterprise Customers > > In addition to our review of public commentary on these issues, we have > also sought input and feedback from Symantec customers on the compatibility > and interoperability impact of the significant changes that could result > from the implementation of Google’s proposal. These customers include many > of the largest financial services, critical infrastructure, retail and > healthcare organizations in the world, as well as many government agencies. > This cohort is an important constituency that we believe has been > under-represented to date in the public commentary that has been posted to > the Google and Mozilla boards since large organizations rarely authorize > employees to engage in such public discussions, particularly in an area > related to security. We first solicited feedback to understand the > disruption that a browser-initiated trust change, like the one proposed by > Google, would cause organizations that opt to replace their existing > SSL/TLS certificates in order to maintain interoperability with all > browsers. We learned that these organizations’ publicly facing web > applications, while extensive, only represent a fraction of their > dependency on publicly trusted Symantec roots. Many large organizations > have complex, and potentially undocumented and little-known dependencies on > their certificate infrastructure. Examples of complex dependencies on > Symantec public roots that our customers have shared or we have identified > include: > > - Embedded devices that are pinned to certificates issued by a Symantec > public root to communicate to resources over the Internet or Intranet. > Replacing these certificates would result in immediate failures and the > need to recode and reimage the firmware for these devices. > - Mobile applications that have pinned certificates. Replacing server > certificates would require these applications to be recoded, recompiled and > redistributed. > - Critical infrastructure organizations that use certificates issued off > of Symantec roots to validate internal and external resources. In many > cases the applications being used are pinned to Symantec certificates. > - Some large organizations use certificates chained to Symantec public > roots for nearly all internal applications and communications. Many of > these organizations are under regulatory requirements to encrypt even > internal communications. > > Additionally, many of these organizations estimate that just the planning > process to prepare to move to a new certificate authority could take many > months and in some cases years because of unknown and undocumented > dependencies. Moreover, few large enterprises that we’ve received feedback > from have implemented the level of certificate lifecycle automation > required to enable safe and cost-effective adoption of shorter validity > certificates. We believe that it is important for the broader community to > understand and give more weight to these compatibility and interoperability > risks, particularly given the fact that many of these organizations are > prohibited from commenting publicly on these topics. > > To give a perspective of scale, Symantec secures more than 80% of the > world’s ecommerce transactions through its certificate infrastructure. > Additionally, Symantec is the world’s largest provider of Organization > Validation (OV) and Extended Validation (EV) certificates which are > primarily used by large enterprises. Many of these certificates sit inside > corporate and government networks and are an important part of the trust > fabric of internal communications. > > In short, our assessment based on customer feedback is that the > interoperability and compatibility failures that could result from a > large-scale certificate replacement or invalidation event would be > significant and unpredictable. > > Our Proposal to the Community > > We understand the importance of providing transparency into our CA > operations and responding to community questions and feedback to inspire > trust. We propose to undertake the following actions in response to browser > concerns and customer feedback as well as to increase trust and confidence > in our processes and our commitment to the compliance frameworks set forth > by the CA/B forum and browser root programs. > > Our EV Process > > Symantec has some of the most comprehensive Extended Validation processes > in the industry. We have, on occasion, been criticized for the time it > takes us to validate EV certificates while some of our competitors boast > rapid (15-20 minute) validation times for EV. We believe that issuing an EV > certificate represents the highest bar of certificate validation in the > industry and that the process used to validate these certificates must be > conducted with the appropriate care. The widespread adoption of Certificate > Transparency for EV certificate issuance now makes it possible for > independent third parties to compare the accuracy of these issued > certificates. One such organization, Netcraft, has been evaluating EV > issuance over time. Their graph at https://www.symantec.com/ > connect/sites/default/files/users/user-2785391/CA%20Blog.png (source: > http://trends.netcraft.com/www.symantec.com) represents their findings of > Symantec EV certificate compliance compared to the rest of the industry. > > The Netcraft numbers demonstrate strong EV requirements compliance for > Symantec relative to our peers. Our point-in-time and recent period-in-time > audits have demonstrated that we are issuing EV certificates in accordance > with industry requirements. We are confident in our EV issuance practices, > which we have informally benchmarked against other CAs. We believe our EV > validation processes are among the most thorough ones employed by any CA. > Nevertheless, to reassure the browser community regarding our EV issuance > practices we propose to undertake the following: > > 1. We will commission a third party auditor to perform a backward-looking > audit of all active EV certificates that have been issued by Symantec to > give comfort around the validity and integrity of our EV certificates and > our EV certificate issuance practices. This action is proposed as an > alternative to Chrome’s suggestion to remove EV treatment of past or future > issued EV certificates, which we believe is unjustified. We believe this > additional audit of our EV certificates provides full transparency into our > EV certificate practices and reaffirms confidence that our active Symantec > EV certificates are trustworthy. Our intention is to complete this third > party audit by August 31, 2017. > Registration Authority Authenticated and Issued Certificates > > Historically, Symantec has issued SSL/TLS certificates either directly or > through Registration Authority (RA) partners who have issued such > certificates on Symantec’s behalf. We want to provide assurance that all > Symantec certificates are properly issued. With these issues in mind: > > 2. We will commission a third party auditor to attest to the list of > active certificates that had been issued by any prior SSL/TLS RA partner, > including CrossCert, Certisign, Certsuperior and Certisur. The purpose of > this action is to provide transparency regarding existing certificates > validated by RA personnel. We believe this action also provides additional > assurance regarding the efforts we have already undertaken to revalidate > all active CrossCert certificates as well as review 100% of the > certificates issued by the other former RA partners. Further, we will ask > our external auditors to audit 100% of the work we have done to revalidate > or review and, where necessary, remediate active certificates issued by all > of these former SSL/TLS RA partners. Our intention is to complete this > third party audit by August 31, 2017. > > Increased Transparency > > We recognize that an accurate understanding of our past incidents is > important to enable an objective evaluation of any proposal regarding this > topic. We have responded to, and will continue to review and respond to the > salient questions posed on the https://wiki.mozilla.org/CA:Symantec_Issues > post at the mozilla.dev.security.policy forum to provide further > transparency into our past compliance incidents. > > Furthermore, we understand the importance of providing increased > transparency into our CA operations. As part of our effort to do so, we > will do the following: > > 3. We will conduct a six month period-in-time WebTrust audit for the > period from December 1, 2016 to May 31, 2017. We will thereafter move to a > cadence of quarterly WebTrust audits (in lieu of annual period-in-time > audits), beginning with the period from June 1, 2017 through August 31, > 2017, until such time as we receive four consecutive quarterly WebTrust > audits without qualification. The purpose of this action is to provide > greater transparency regarding our operations and new certificates issued > by Symantec going forward. > > 4. We will publish a quarterly letter to update the community on the > progress of our third party audits identified in this proposal and the > progress of our continuous improvement program that incorporates the other > actions in this proposal. > > 5. We will work through the CA/B Forum to recommend new (or where > applicable, updated) guidelines for appropriate customer exception requests > to baseline requirements. While the CA/B forum has developed a process for > exception requests, we believe it should consider further guidelines to > assess the risk associated with these requests and determine conditions > under which the CA/B forum might expeditiously approve exception requests. > > 6. We will endeavor to improve the timeliness of our responses to the > browser community as well as the level of technical detail we provide in > them, balancing the interest of the community to receive prompt responses > to their questions with the time required to perform the investigative > steps necessary to provide thorough responses to such questions. > Move to Shorter Validity Certificates > > We support the added option of shorter validity certificates, as do > several browsers and others in the ecosystem. Shorter validity certificates > can reduce exposure in the case of an undetected key compromise, enable > faster adoption of improvements to industry standards (e.g. move to ECDSA > or SHA3), and drive more rapid remediation of potential TLS-related > vulnerabilities (like Heartbleed) that can require certificate replacement. > > 7. By August 31, 2017, we will begin to broadly offer SSL/TLS certificates > with three month validity periods to give our customers greater choice and > flexibility in the validity periods of the certificates they purchase and > deploy from Symantec. From the customer feedback we have received to date, > we believe this offering may be most attractive to customers that have > already enabled automation, such as customers and partners integrated with > our APIs and e-commerce customers with less complex environments. In > addition, we will continue our investments in automation to enable > organizations with even the most complex infrastructure to practically and > cost-effectively adopt shorter validity certificates. Our near term > investments will focus on modernizing our certificate issuance systems and > workflows to enable faster issuance, and developing tools that enable > customers to rapidly and securely implement their certificates and > configure their systems. > > 8. We will perform a domain revalidation of all issued certificates that > have a validity period longer than nine months at the nine-month mark (at > no additional cost to our customers). This approach is intended to balance > the customer impact of replacing certificates, for those not ready to move > to shorter validity certificates, with visibility that ensures that > certificates are being used appropriately. We commit to working with the > browser community regarding appropriate transparency mechanisms (e.g., an > extension of CT logging, OCSP extension, signed DNS text record, or signed > revalidation list) that provide an attestation to this revalidation and > ensure accountability of our implementation of this action. An initial > certificate validation is one level of authentication. Certificate domain > revalidation post-deployment further extends the trustworthiness of the > initial certificate, which is a positive extension of the CA trust model. > > Continuous Improvement of our CA Operations > > We seek to continuously improve our systems and processes around > certificate issuance. With this in mind: > > 9. We are further increasing our investment in the Security and Risk > function of our CA operations, with a focus on our security and compliance > controls and risk assessments. As a first step, we are commissioning a > third party to conduct a process and systems risk assessment of our CA > operations. The scope of this assessment will include an inventory of our > systems and use cases, and a review of the security controls we have in > place with respect to all of our PKI services, including SSL/TLS > certificates. This third party assessment will also incorporate red teaming > and penetration testing of our processes and systems beyond what we do > already. The purpose of this third party risk assessment, which we expect > to complete by October 31, 2017, is to provide increased confidence in the > risk management posture of our CA operations beyond WebTrust audit reports. > > 10. We will update our Root Program to more directly compartmentalize > different certificate use cases. This update will involve creating > dedicated roots and/or sub-CAs, for example, to segment customers who today > use our publicly trusted hierarchies for closed ecosystems like set-top > boxes, for customers who have mixed ecosystems like point-of-sale systems > and ATMs which connect to the same servers as browser-based applications, > for customers who choose to use longer validity certificates, or for > customers who serve disproportionately large web traffic. As certificates > expire, we will issue new certificates that chain to the use > case-appropriate roots. > > 11. Industry analysts estimate that 50% or more of all network attacks > targeting enterprises this year will take advantage of SSL/TLS encryption > to bypass security controls. We believe that CAs have a necessary and > critical role to play in validating whether an encrypted website is > malicious. Symantec’s technology infrastructure includes a Global > Intelligence Network that analyzes websites, domains, servers and web > services at scale and runs both real-time and background checks on such > external hosts, including over a billion previously unseen and > uncategorized websites a day. Our Global Intelligence Network includes > technology that categorizes websites into over 80 categories – e.g., > “Financial Services,” “Education,” “Malicious Sources/Malnets” or > “Suspicious” – based on linguistic analysis, inter-site relationships, > host-attribute analysis and reputation and history. Modules within our > Global Intelligence Network analyze site content such as images, video and > embedded links and can run in-depth content analysis in over 50 languages > to help categorize sites and identify potential risk. We will begin to use > our Global Intelligence Network to identify encrypted websites that have an > increased threat risk based on our rating categorization and take > appropriate action to mitigate risk for our certificates associated with > such sites. > > Even though our past mis-issuance events have not, to our knowledge, > resulted in customer harm, we consider compliance with industry standards a > critical responsibility of our CA business. We believe our multi-faceted > proposal addresses the concerns regarding the trustworthiness of Symantec’s > past and future SSL/TLS certificate issuances. We also believe our proposal > appropriately balances these concerns with the significant compatibility > and interoperability risks, as well as customer burden, which would result > from any proposal that limits the trust of existing Symantec SSL/TLS > certificates, imposes shorter validity periods on newly issued Symantec > certificates and/or removes EV recognition for our certificates in browsers. > > We welcome constructive feedback to our proposal, which we understand may > take time for the Internet community to fully consider. In the meantime, we > will continue to solicit feedback from our customers and partners, which > are important stakeholders that will be impacted by changes to our > operations, whether as a result of our proposal or any other. > > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
