Chrome CT 2020 Plans

عرض 1-3 من 3 من الرسائل
Chrome CT 2020 Plans Devon O'Brien 21/01/20 05:04 م

Hello ct-policy@chromium.org,


Happy New Year from the Chrome Security team! 


In order to share our 2020 priorities as well as to receive feedback from the broader CT community, we wanted to share with you our plans for CT for this upcoming year. 


Our main priorities are improving Chrome’s CT implementation and our infrastructure tooling with respect to the Chromium CT Policy, and somewhat ambitiously, removing its explicit dependence on Google CT Logs. Beyond this, we have plans to improve all stages of CT Log Lifecycle from better compliance monitoring, clearer ongoing requirements of Log Operators, and better public documentation for the entire Log Lifecycle, from first application to graceful turndown.


Our hope is that interested members of the community can voice their support or concerns with anything proposed here before we make significant progress on these changes. Without further ado, here are our top project goals for this year: 


-------------


Improved Compliance Monitoring

Existing Log Operators are probably familiar with Google’s CT compliance monitoring infrastructure, which periodically queries Pending and Qualified CT Logs to ensure they’re meeting several requirements described in the Chromium CT Log Policy. The Google CT Team is developing a new version of this tool, which will perform checks on a larger set of these policy requirements. Once this new tool has been deployed, we will work to make the compliance data it provides public, so the health of CT Logs can be known to CAs, Auditors, and Log Operators themselves.


In addition to this new compliance monitoring infrastructure, we’re going to re-examine the existing compliance monitoring period with an eye towards making the evaluation more meaningful as well as shortening its duration. We believe these changes will both reduce the time to entry for new CT Logs as well as increase the likelihood that Qualified CT Logs are able to stand up to real-world loads without violating availability or consistency requirements.


Updates to our CT Policy and CT Log Operator Policy. 

This year, we are planning a new version of each of these policies that clear up ambiguous language and add additional requirements. In order to provide Log Operators, CAs, Monitors, and Auditors a comfortable amount of lead time to comply with any changes, we’ll be announcing any final policy changes well in advance of their effective dates.


Topics we anticipate covering are: 

  • Adding policy language restricting the type of certificates that can be logged to CT Logs to minimize risk to the CT ecosystem from non-TLS use cases. 

  • Adding requirements to ensure that all SCTs created by a CT Log must correspond to an included log entry to allow more reliable CT Monitoring and Auditing

  • Reworking the Chromium CT Log Operator Policy to define clearer policy requirements that align with the checks performed by our new compliance monitoring infrastructure.

  • Changing the CT Log diversity requirements to no longer explicitly require SCTs from Google CT Logs, provided we can ship a stable, private SCT Auditing mechanism in that timeframe.


A new policy version will be shared to ct-policy@chromium.org for discussion and feedback and will also be discussed at CT Days 2020 before taking effect.


CT Days 2020

This year, we’re planning on hosting another CT-focused event to bring together members of the CT ecosystem to share and learn about a variety of topics related to CT. In addition to discussing many of the projects listed here, we’d like to cover several other topics such as guidance for Log Operators by Log Operators, updates on some of the work that the Google CT Team has been doing (e.g. certificate submission proxy, new compliance monitoring tool, infrastructure changes to make their logs more failure independent), and more! 


We’re still working on setting a date and location, but we’re currently planning for Summer/Fall 2020 and will send an announcement when details are firmed up. Please reach out to ct-policy@chromium.org if there are topics you’d like to see discussed or if you’d like to participate in presenting a session. 


Dynamically Updatable CT Log List

Currently, updates to Chrome’s CT Log List are implemented as source changes that land on tip of tree and ride the release waterfall through Canary, Dev, Beta, and ultimately, Stable. This year, we plan to move the CT Log List to a component that is capable of being dynamically updated via the Component Updater in addition to being delivered with each release in source.  While this will lead to a more rapid uptake for new CT Logs for most Chrome clients, the primary value is in pushing out CT Log removals faster in the event of an unrecoverable Log incident.


Technical Enforcement of Sharded CT Logs Expiry Range

As outlined in the Chromium CT Policy, sharded CT Logs are sets of CT Logs that define an expiry range, which indicates the Log’s intent to accept only certificates that expire within that specified range. One of the most important benefits of CT Log sharding is that it allows Chrome to remove shards from the list of Qualified CT Logs once the expiry date has been reached, which in turn, allows the Log Operator to spin down this Log without worrying about impact to the ecosystem. 


In an effort to align technical implementation with policy, Chrome is planning to reject TLS certificates whose expiry date falls after the expiry range for sharded CT Logs. By utilizing a “fail fast” approach in which certificates expiring after the Log’s range are never able to validate, we will no longer risk the situation in which retiring a CT Log causes in-the-wild certificate breakage. 


SCT Auditing

Chrome and the Google CT Team are taking a two-pronged approach to auditing SCTs that are encountered by Chrome. Since SCTs are a strong proxy for browsing history, they cannot be shared directly with an Auditor without careful consideration of the privacy implications.


As there are still several unknowns around creating a feasible, privacy-preserving SCT auditing mechanism, the first approach we’re pursuing is to share SCTs from Chrome clients where users have opted in to share information to improve Chrome Security. This will enable our infrastructure to audit SCTs encountered in the wild by Chrome to more reliably detect lack of SCT inclusion and split views.


Ultimately, we’re not satisfied with forcing users to choose between their privacy and security when it comes to CT, so the second phase is to research, design, and ultimately deploy a privacy-preserving mechanism to audit SCTs. 


-------------


As always, please reach out to ct-policy@chromium.org with questions or suggestions about policy, implementation, or any other CT-related topic! If you need to reach the Chrome CT Team directly, we can be reached at chrome-certificate-transparency@google.com, but we will refer discussions to ct-policy@chromium.org if we feel they’re better addressed in the community forum.


-Devon

Re: [ct-policy] Chrome CT 2020 Plans Jacob Hoffman-Andrews 21/01/20 07:16 م
On 1/21/20 5:04 PM, Devon O'Brien wrote:
somewhat ambitiously, removing its explicit dependence on Google CT Logs.
 Congrats! This is a big deal, and very exciting. I'm glad you're working on it.
 
The Google CT Team is developing a new version of this tool, which will perform
checks on a larger set of these policy requirements. 
The Let's Encrypt team has also developed a monitoring tool, for the purposes of monitoring our own log, called ct-woodpecker: https://github.com/letsencrypt/ct-woodpecker/. It's designed to be applicable to any log, and to be usable by log operators or monitors. In addition to checking STH freshness and submitting certificates from a test root, it also checks for inclusion of those certificates, and for MMD violations. Hopefully this is useful for your team, either by direct adoption or as a source of reference ideas.

By the way, one thing I would really appreciate as a log operator is guidance on expected response times for various endpoints.

 
Once this new tool has
been deployed, we will work to make the compliance data it provides public,
so the health of CT Logs can be known to CAs, Auditors, and Log Operators
themselves.


In addition to this new compliance monitoring infrastructure, we’re going
to re-examine the existing compliance monitoring period with an eye towards
making the evaluation more meaningful as well as shortening its duration.

 These are excellent!
Re: [ct-policy] Chrome CT 2020 Plans Kat Joyce 29/01/20 04:09 ص
On Wed, Jan 22, 2020 at 3:16 AM Jacob Hoffman-Andrews <js...@letsencrypt.org> wrote:
On 1/21/20 5:04 PM, Devon O'Brien wrote:
somewhat ambitiously, removing its explicit dependence on Google CT Logs.
 Congrats! This is a big deal, and very exciting. I'm glad you're working on it.
 
The Google CT Team is developing a new version of this tool, which will perform
checks on a larger set of these policy requirements. 
The Let's Encrypt team has also developed a monitoring tool, for the purposes of monitoring our own log, called ct-woodpecker: https://github.com/letsencrypt/ct-woodpecker/. It's designed to be applicable to any log, and to be usable by log operators or monitors. In addition to checking STH freshness and submitting certificates from a test root, it also checks for inclusion of those certificates, and for MMD violations. Hopefully this is useful for your team, either by direct adoption or as a source of reference ideas.

Jacob - just wanted to chime in and say yes, we are very aware of this tool, and it is indeed a great point of reference!  It's awesome, so a massive thank you to you and the team for creating it!
 

By the way, one thing I would really appreciate as a log operator is guidance on expected response times for various endpoints.

 
Once this new tool has
been deployed, we will work to make the compliance data it provides public,
so the health of CT Logs can be known to CAs, Auditors, and Log Operators
themselves.


In addition to this new compliance monitoring infrastructure, we’re going
to re-examine the existing compliance monitoring period with an eye towards
making the evaluation more meaningful as well as shortening its duration.

 These are excellent!

--
You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ct-p...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/CAN3x4QkK4nac4aV0_pW_k2GO0urec6v2ppH-fjgznvFgu%2Bozdw%40mail.gmail.com.