Chrome CT 2020 Plans

[Devon O'Brien]

Hello ct-p...@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-p...@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-p...@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-p...@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-certific...@google.com, but we will refer discussions to ct-p...@chromium.org if we feel they’re better addressed in the community forum.

-Devon

[Jacob Hoffman-Andrews]

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!

[Kat Joyce]

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-policy+...@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.

[Doug Beattie (Globalsign)]

On Tuesday, January 21, 2020 at 10:16:20 PM UTC-5, Jacob Hoffman-Andrews 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.

 

Is there more information on removing the explicit dependencies on the Google CT Logs?  I'm assuming this means that the requirement to have at least one Google and one non-Google SCT is going away.  Is that right?

 

[Devon O'Brien]

Hi Doug,

That is indeed the requirement being referenced in this proposal. As I mentioned in the original post, this is an aspirational goal and there are several dependencies in the way of moving to remove this particular bit of our CT Policy. Fundamentally, the biggest obstacle to removing this dependency is solving SCT auditing in the wild. As anyone who's paid attention to this space for a while probably knows by now, there have been several proposals for this put forward, each with their own set of security, privacy, and performance tradeoffs. There are other concerns to address as well before we can make this policy change, but this is the biggest obstacle by a wide margin.

I look forward to being able to share more concrete plans at the next CT Days, so keep your eyes peeled to ct-policy@ for announcements about that later this year.

[Doug Beattie (Globalsign)]

Hi Devon,

OK, I get it now.  I didn't make the connection between removing the requirement to get SCTs from both Google and non-Google CT logs and the SCT Auditing topic.

While everyone has full access to all CT logs to see which precertificates were posted, you don't have the final issued certificate to understand which SCTs are being used in the wild from all of those SCTs that you can obtain from the CT logs.  

I guess we can wait for the next CT Days meeting, but what at the highest level will auditing SCTs in the wild do that you can't do by looking at all of the SCTs issued from the CT logs?  Is it possible that there are SCTs in the wild that are not available in the CT logs because of certain malicious log operators (or certain failures)?  Is that what the SCT Auditing topic is about?

I've been concerned for a while about the requirement to use Google CT logs because it's possible that the Google logs "all" go down for some reason (we've seen multiple Google logs go off-line at the same time in the past).  You said that those that watch this list for a while have seen various proposals with their own set of pros and cons, but for me, it's hard to go back in time and collect them all up.  Were they discussed at the last CT Day and documented in notes that I could look at?

What can we do to remove this dependency, and how can we move forward with an updated Google CT policy which does not require a Google SCT? Is SCT auditing the only approach or are there other options?  What about making the minimum number of SCTs 3 so that it becomes highly unlikely that all 3 logs fail or are hacked the same way?  2 different log operators?  Posting all issued certificates to CT logs?

Doug

[Devon O'Brien]

On Thursday, February 6, 2020 at 8:38:48 AM UTC-8, Doug Beattie (Globalsign) wrote:

Hi Devon,

OK, I get it now.  I didn't make the connection between removing the requirement to get SCTs from both Google and non-Google CT logs and the SCT Auditing topic.

While everyone has full access to all CT logs to see which precertificates were posted, you don't have the final issued certificate to understand which SCTs are being used in the wild from all of those SCTs that you can obtain from the CT logs.  

I guess we can wait for the next CT Days meeting, but what at the highest level will auditing SCTs in the wild do that you can't do by looking at all of the SCTs issued from the CT logs?  Is it possible that there are SCTs in the wild that are not available in the CT logs because of certain malicious log operators (or certain failures)?  Is that what the SCT Auditing topic is about?

This is exactly correct. Sections 7.3 and 5.4 of RFC 6962 (https://tools.ietf.org/html/rfc6962) provide additional context for the role of Auditors in detecting misbehaving CT Logs. Inherently, CT strives to not add additional layers of trusted third parties, which is why there is so much overhead of the append-only Merkle tree backing the CT Logs as well as the associated availability requirements. In order for a CT-enforcing user agent to not rely on the honesty of a CT Log, there needs to be a way to audit SCTs 'in the wild' to ensure, to a high level of confidence, that CT Logs aren't minting SCTs and failing to incorporate them in a way that will be detected by Auditors, which tend to be monolithic and predictably positioned (i.e. a CT Log knows which servers are auditing them and when).

The current 'one Google Log' requirement is a boot strap to get CT operational and ubiquitous, which can be removed under the right set of circumstances.

I've been concerned for a while about the requirement to use Google CT logs because it's possible that the Google logs "all" go down for some reason (we've seen multiple Google logs go off-line at the same time in the past).  You said that those that watch this list for a while have seen various proposals with their own set of pros and cons, but for me, it's hard to go back in time and collect them all up.  Were they discussed at the last CT Day and documented in notes that I could look at?

I don't want to speak for the Google CT Log Operators, but I can guess that they probably don't want to be on the critical path here either. Regarding previous Auditing proposals, they have been discussed in a variety of fora across 5-7 years now, so it will take me a bit of time to pull together all of the reference materials for previous proposals. To give a preview, some of the most notable ones are:

1. User Agents sharing SCTs with a centralized auditing server

2. User Agents directly querying CT Logs for audit information

3. Embedding inclusion proofs in certificates

4. Using a Private Information Retrieval (PIR) or Private Set Membership (PSM) scheme to allow SCTs to be audited in a more privacy-preserving manner

This is a non-exhaustive list and there are variations of these as well that offer different trade-offs, such as using STH Discipline to regulate STHs for inclusion and consistency proofs. This is still an open question for CT and we are hoping to tackle this in earnest in the later half of this year. We welcome input from the CT community on practical solutions to this problem that are both private and performant.

What can we do to remove this dependency, and how can we move forward with an updated Google CT policy which does not require a Google SCT? Is SCT auditing the only approach or are there other options?  What about making the minimum number of SCTs 3 so that it becomes highly unlikely that all 3 logs fail or are hacked the same way?  2 different log operators?  Posting all issued certificates to CT logs?

These suggestions have been tossed around at CT Days since ~2016 Requiring more SCTs adds overhead to certificates & TLS handshakes, and also makes the whole ecosystem more brittle since there is not a very large set of distinct Log Operators to choose from. All initial attempts at defining a "Log Diversity Requirement" failed due to the inability to reliably quantify which Logs are operated independently of any other Logs. We have minimal insight and no third-party auditing into these details, and we've already seen multiple M&A events result in previously independent CT Logs no longer being independent.

By no means am I trying to shut down this line of thinking, but several years of this being a looming issue have not resulted in a viable, performant, and privacy-preserving solution. We're committing to working on this problem this year and are hopeful that cooperation with the CT community can result in a clear path. 

-Devon