> -----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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
