[cabfpub] Upcoming changes to Google Chrome's certificate handling

[kirk_hall at trendmicro.com]

Rick's email brings up a lot of valid points that we hadn't considered.

While we support the stronger security that CT is designed to achieve, on reflection we agree with the approach of a staged or layered introduction of CT, with testing at various points to make sure it works and is scalable.

Kirk R. Hall
Operations Director, Trust Services
Trend Micro

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Rick Andrews
Sent: Monday, November 04, 2013 5:29 PM
To: Ryan Sleevi; CABFPub
Subject: Re: [cabfpub] Upcoming changes to Google Chrome's certificate handling

Ryan,

I've already replied to Ben Laurie on the CABF Management list, but since you also asked for comments here on the public list, I present our feedback here too.

-Rick


Symantec's position on Certificate Transparency:



On September 24, 2013, Ben Laurie solicited comments on Google's plan for Certificate Transparency (CT), specifically to require the use of CT for all EV certs issued after a certain date. Symantec is in favor of making the web more secure, and in particular, helping to prevent certificate mis-issuance. In our view, there are many ways to do this, and CT should be evaluated along with other proposals and compared to them. We first present feedback on CT itself, then feedback on the plan to require CT for EV.



Certificate Transparency



After some cases of CA flaws were publicized in 2011, several proposals were made to enhance the current browser-CA-based trust model, since the incidents showed that a poorly managed CA could mis-issue a trusted certificate. Well before those events, both CAs and browsers collaborated on a set of Baseline Requirements that went into effect on July 1, 2012. In addition, both CAs and browsers have taken additional steps by themselves to help customers and users be more secure. It is noteworthy that since these steps have been taken, the empirical security of the CA/Browser ecosystem has demonstrably increased.



This trust model that has been built into browsers is a very complex system, yet in our opinion, CT proposes to address mis-issuance by building another complex system that will no doubt have its own share of complexities and challenges. We can't be sure that the combined system (browser-CA-based trust model plus CT) will necessarily be better or more secure, especially since CT cannot prevent mis-issuance, but can only help in detecting of mis-issuance. And mis-issuance can't be detected until the log servers have incorporated the certificate (within the Maximum Merge Delay) and monitors have queried all log servers. A denial of service attack against a log server could extend the time during which a mis-issued certificate could be used. We favor solutions that are preventative in nature.



We note that the CT spec offers options for delivery of CT proofs, also known as SCTs. The first option would require a CA to obtain multiple SCTs and insert them into the certificate before signing it. Other options would not impact the certificate issuance process but would allow the CA or the customer to obtain SCTs after cert issuance. We expect strong pressure to support the first option, because it has the great advantage of working with existing web servers with no configuration change. The other options require code and/or configuration changes in web servers that would greatly slow the rollout of this technology.



Our main concern with the first option is that it requires the CA to make extensive changes to its issuance process that create an external dependency outside of the trust provider's control. That process is most critical for a CA, since it is how the CA confers legitimacy onto trusted web sites and achieves its business objectives. We believe that it would be analogous to asking Google to get approval responses from external entities before it could publish an advertisement or publish web search results. There is no doubt enhanced risk in making such external calls. If responses are not received from the minimum number of log servers, the CA would not be able to issue the certificate. (We note that CAs already consult external services like Dun & Bradstreet and whois in their authentication processes, but those services have proven to be extremely reliable, and even if they weren't, they are not essential to the process - there are workarounds.)



The CA could mitigate the risk of relying on external services by running its own log servers. Google has generously offered source code for this purpose. Each CA would have to choose between running one or more log servers themselves or relying on log servers run by others. The former involves considerable cost, the latter involves considerable risk. The expense of building and maintaining such log servers will be outside the reach of many small CAs, since the log servers would have to have an extremely low failure rate and would have to respond with very little latency even under very high load. As a high performance and highly-scaled player, one could argue that Symantec stands to benefit from this regulatory requirement. However, we believe investment choices must be paired with an analysis of the benefits created and new costs incurred from a potential solution. In this case we do not see how CT raises the bar enough to justify added risk, costs and complexity.



Symantec is reluctant to invest large sums in unproven technology that introduces substantial ecosystem rigidity and potential for points of failure. Note that even if external logs work perfectly with 100% uptime, other factors (ISP failure, DOS attacks, etc.) could prevent the CA from obtaining enough SCTs to issue the certificate. The CA could run some internal log servers and rely on some external log servers, but Symantec believes that combines the worst features of both options. We admire Google solutions that combine simplicity, speed and user-centric design. Our fear is that CT will sour SSL customers on the trust ecosystem, while not delivering on what we believe should be the number one goal: preventing mis-issuance at the source.



If a CA deploys their own log server, that server needs to handle not just the load from the CA but from all the monitors that will frequently hit it. CT imposes no restrictions on log monitors, so the log server operator has to plan for very high load.



Another concern with the first option is the extent to which CT will increase certificate size. Adding the recommended three SCTs to a certificate will increase the size approximately 300 bytes. This comes at a time when several high profile customers and Mozilla have asked us to reduce the size of our certificates. Option 1 also increases the burden on CAs by requiring each certificate to be signed twice. Signing infrastructure is one of the largest investments that a CA makes, since keys are generally kept in expensive Hardware Security Modules. Option 1 would require CAs to double that investment.



But the CA can choose a second option for SCT delivery, in which SCTs are not obtained at certificate issuance time. The web site owner, or the CA on behalf of the web site owner, could obtain SCTs sometime after the certificate is issued. But unless the customer uses a web server that supports delivery of SCTs via a custom TLS extension (meaning that they would have to upgrade or at least reconfigure their web server to support CT), they would not be able to serve SCTs to clients.



A third option would allow SCTs to be carried inside of an OCSP response message. While that option has the appeal of leaving the certificate issuance process untouched, CAs would need to make extensive revisions to their OCSP response architectures to obtain the necessary SCTs and embed them in the OCSP response. The level of effort would be roughly equivalent to the effort required to support the first option, incorporating SCTs in the certificate. Some CAs use third party software to create and publish OCSP responses, and wouldn't have the ability to affect the changes needed to support this option. It seems that CT-compliant browsers would need to support all three options for SCT delivery, in order for each CA to adopt the option that best suits it.



The specification is unclear on who would audit the log servers, verifying that the log server's log included a certificate for which it issued an SCT, and that it was done within the MMD time. Perhaps that will be done by the browser, asynchronously. But this function is crucial - without it, users are simply trusting log servers instead of CAs. Symantec is unwilling to invest large sums in a technology for which it's still unclear how crucial tasks will be performed.



Also missing from the specification is a mechanism that can be used by a monitor to determine the location of all log servers. If a monitor misses any log servers, it may miss one or more mis-issued certificates. New log servers may appear from time to time, while existing log servers may become untrusted if auditors detect any improper function. It's essential that monitors have a way to always know the full set of trusted log servers, but no mechanism is detailed in the CT specification.



Symantec is also concerned about privacy. It's true that most TLS certificates are public information, but CT logs collect all TLS certs in a convenient, easily accessible database. We are concerned about the possibility of the misuse of this information, for example, creating an easy way to target certificate owners with unwanted solicitation.

Requiring CT for EV certificates



In regards to requiring CT for EV, we note that there has been active discussion recently in the CAB Forum on adding run-time checks before displaying the EV treatment. It appears that this would be one such run-time check. There has been and continues to be strong opinion (maybe even consensus) in the CAB Forum that EV is about validation only, not enhanced run-time checks. Symantec believes that adding run-time checks will enhance security, but we would prefer to begin with checks for which there is probably broad consensus (key size, validity period, wildcard, etc.) rather than beginning with a heavyweight CT requirement.



As mentioned above, CAs are free to choose the option of delivering SCTs outside of the certificate issuance process, but customers may then be forced to upgrade or at least reconfigure their web server just to preserve EV treatment. Since few customers will be happy about that, Symantec believes that CAs will have no choice but to forgo this option and obtain SCTs at certificate issuance time. That will force CAs to choose between considerable expense and unacceptable risk, as described above.



Given all the concerns described here, Symantec strongly believes it is unadvisable to mandate the use of CT. At the very least, we believe additional study is required on how to overcome the challenges of CT.



More technical details need to be worked out. For example, the specification says "this document does not describe how clients obtain the logs' public keys"; it's also not clear who would serve as auditors, and unless the logs are constantly audited, the integrity of the system is degraded or lost. We note that all CAs are required to be audited, and it would be equally important to insure that all log servers are audited.



We hope that Google will continue to discuss this within the CAB Forum and try to work towards consensus among other browser vendors and CAs. The EV Guidelines were crafted by that Forum, and we believe that any change to the EV guidelines or to the requirements for display of the EV treatment should be debated and agreed to by the Forum, not unilaterally by Google.



Symantec's proposals



Symantec believes that log servers do provide some benefits for domain owners who want to monitor the issuance of certificates for their domain. But the proposed method of populating log servers is, in our opinion, complex and expensive. We suggest a compromise in which the owner of a log server populates that server with certificate information found via a web crawl. In fact, Google has been populating a log server this way for the last few months, and it has already discovered a suspicious certificate chain. Symantec is considering the possibility of performing a periodic web crawl and populating its own log server with all certificates found. This approach requires a much smaller initial investment and results in a much simpler system. A monitor would have to monitor a single log server, and it need only be monitored by the log owner, not the public at large.



Symantec also would prefer to invest in technology that has the aim of adding even more mechanisms to prevent mis-issuance before it happens. To that end, we are building support for Certificate Authorization Authentication (CAA), a relatively simple idea that has the potential to prevent mis-issuance. We will urge other CAs to seriously consider adopting CAA as well, and we suggest that the CAB Forum make use of CAA a Baseline Requirement. Absent that, if the browsers shared the goal of preventing mis-issuance at the source they could require use of CAA for inclusion in root programs. Alternatively, CAs that utilize CAA could be differentiated by browsers through simple user-centric markings in the browser and/or user choice on what roots to trust while browsing. CAA is not a panacea but does create a straightforward method for concerned domain owners to limit the potential for mis-issuance. At Symantec we are always continuing to investigate other technologies.



We note that public key pinning and HSTS have been very effective in detecting mis-issuance for some web properties, especially Google. The main shortcoming of pinning appears to be scalability, but Symantec suggests that a modest investment in addressing the scalability problem would pay huge dividends. We support the continued adoption of key pinning and HSTS, and we continue to investigate other solutions for improving the browser-CA trust model.



We close by offering that these comments are in the spirit of a robust public discussion on the future of web security and have no doubt that all parties including Google desire a safer Internet. We hope to continue an active dialogue that looks for ways to reduce risk while continuing to enable the web security ecosystem to flourish and scale to provide even more benefit for the Internet. We invite feedback and comment on our statements and look forward to continuing the discussion.


From: Ryan Sleevi [mailto:sleevi at google.com]
Sent: Tuesday, September 24, 2013 3:50 AM
To: Rick Andrews
Cc: CABFPub; Ben Laurie
Subject: RE: [cabfpub] Upcoming changes to Google Chrome's certificate handling


Indeed, as we finalize dates and implementation, a corresponding policy update will follow.

At this time, we're soliciting feedback on the plans regarding Certificate Transparency, and wanted to provide broad notice to interested parties - in addition to individual efforts to reach out to CAs that are EV enabled within Google Chrome.

Cheers,
Ryan
On Sep 24, 2013 3:42 AM, "Rick Andrews" <Rick_Andrews at symantec.com<mailto:Rick_Andrews at symantec.com>> wrote:
Ryan,

Since not all CAs are members of the CA/Browser Forum, will you be publishing this to a Chrome policy web site? I see https://sites.google.com/a/chromium.org/dev/Home/chromium-security/root-ca-policy; I presume that's your policy page?

-Rick

> -----Original Message-----
> From: public-bounces at cabforum.org<mailto:public-bounces at cabforum.org> [mailto:public-bounces at cabforum.org<mailto:public-bounces at cabforum.org>]
> On Behalf Of Ryan Sleevi
> Sent: Tuesday, September 24, 2013 3:09 AM
> To: CABFPub
> Subject: [cabfpub] Upcoming changes to Google Chrome's certificate
> handling
>
> I'm writing this message to provide notice to members of the
> CA/Browser Forum about exciting changes we have planned for future
> releases of Google Chrome and Google Chrome OS, in addition to the
> Chromium projects these products are based upon, in the hope of
> minimizing any surprises or inconvenience these may cause.
>
> We look forward to continuing to work with members of the CA/Browser
> Forum to improve online security, and welcome feedback regarding these
> plans.
>
> Regards,
> Ryan Sleevi, Chris Palmer, Adam Langley, and Ben Laurie on behalf of
> the Google Chrome team
>
>
> * Changes to Cryptographic Algorithm Minimum Requirements:
>
> As specified in Appendix A of the Baseline Requirements, 31 December
> 2013 is the sunset period for the issuance of certificates containing
> RSA key sizes less than 2048 bits. Beginning in early 2014, Chrome
> will begin warning users who attempt to access sites with certificates
> issued by publicly-trusted CAs, that meet the Baseline Requirements'
> effective date, and with key sizes smaller than those specified in
> Appendix A.
>
> The anticipated logic is as follows:
> - The end-entity certificate has a notBefore date after the Effective
> Date of 1 July 2012 of the Baseline Requirements
> - AND the end-entity certificate has a notAfter date after 31 December
> 2013
> - AND
>  - EITHER the end-entity certificate has a key size weaker than those
> specified in Appendix A (eg: RSA key that is less than 2048 bits)
>  - OR an intermediate certificate in the validated chain has a key
> size weaker than those specified in Appendix A (eg: an RSA key that is
> less than 2048 bits)
>
> While we would like to extend this requirement to also include root
> certificates with sizes of less than 2048 bits, unfortunately not all
> Root Programs have been updated to remove 1024-bit root certificates.
> This exception for root certificates is temporary, and all CAs must
> immediately ensure that they are providing appropriately strong root
> certificates to Root Programs. Note that future versions of Google
> Chrome and Google Chrome OS MAY remove trust for root certificates
> with RSA keys less than 2048 bits, independent of platform
> configuration, as described at
> http://www.chromium.org/Home/chromium-security/root-ca-policy#TOC-
> Removal-of-Trust
> , so this should not be seen as a permanent exception.
>
> While it would be ideal if this caused no issues for users, our
> current data suggests the enforcement of minimum key sizes will impact
> small percentage of sites - roughly, less than 0.1% of sites surveyed
> - due to CAs failing to adopt the technical requirements of the
> Baseline Requirements at the effective date. We want to ensure that
> CAs are aware of the upcoming changes and working with their customers
> to ensure that the CA is capable of passing a Baseline Requirements
> audit.
>
> In addition, we anticipate applying these restrictions to so called
> 'legacy' certificates at a to-be-determined later date, as part of the
> natural sunsetting of weaker key sizes and algorithms. A hard cut date
> for such certificates has not yet been determined.
>
> Note that these programmatic checks will also cover the DSA and ECDSA
> minimum size requirements, as also specified in Appendix A, but our
> data suggests this should cause no disruptions.
>
>
> * Improving the Security of EV Certificates
>
> All values in [] are TBD.
>
> In order to improve the security of Extended Validation (EV)
> certificates, Google Chrome intends to require Certificate
> Transparency (CT) for all EV certificates issued after [date TBD].
>
> Once we have gained experience with EV certificates we will publish a
> plan to bring CT to all certificates.
>
> We are soliciting feedback on the following plan.
> - Google is already running a pilot CT log.
> - By Dec 2013 Google will deploy three geographically diverse
> production CT logs which will accept all certificates issued by CAs
> accepted by any major browser (which are [Chrome, Internet Explorer
> versions [?], Safari, Firefox and Opera]).
> - Google invites other organisations to deploy CT logs in order to
> improve robustness.
> - On [date TBD] Chrome will begin providing CT status information
> through the UI.
> - By [date TBD] all EV certificates with validity periods beyond [date
> TBD] should be logged in at least [one] qualifying log (see below).
> - On [date TBD] Chrome will create a whitelist of valid EV
> certificates already issued without an embedded SCT [issued by CAs
> participating in CT] from all qualifying logs.
> - On [date TBD] Chrome will cease to show the EV indicator for
> certificates not in the whitelist and not CT qualified according to
> the criteria below.
>
> Qualifying Logs
>
> A log is qualified if its URL, public key and Maximum Merge Delay
> (MMD) are known to and accepted by Chrome.
>
> Chrome will accept a log's URL, public and MMD key if
> - The log has not been shown to have acted in bad faith.
> - The log is run by an entity believed to be capable of keeping the
> log up at least [99.9%] of the time.
> - The log has an MMD of no more than [24 hours].
> - The log conforms to RFC 6962.
>
> Qualifying Certificate
>
> A certificate is CT qualified if the TLS handshake it is presented in
> satisfies at least one of
> - [Three] or more SCTs from different qualifying logs [or logs that
> once were qualifying] [operated by distinct entities] are embedded in
> the certificate.
> - [One] or more SCTs are embedded in a stapled OCSP response as
> specified in RFC 6962.
> - [One] or more SCTs are sent via the RFC 6962 TLS extension.
>
> And at least one SCT for the certificate validates and was issued by a
> qualifying log.
>
> Timeouts
>
> Chrome will regularly synchronise its list of qualifying logs with
> Google's servers.  If the last successful synchronisation was more
> than [10 weeks] ago, the client will [stop checking CT] and [cease to
> show EV indications].
>
> Google will keep an authoritative list of qualifying logs and post
> changes to that list on the public CA/B Forum mailing list.
> _______________________________________________
> 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: <http://lists.cabforum.org/pipermail/public/attachments/20131105/cbb61bce/attachment-0003.html>