Concluding the Aviator Discussion

[Ryan Sleevi]

Thanks to everyone who participated in the discussion regarding Aviator’s issue with exceeding its MMD. This was a long and productive discussion, with feedback from a wide variety of community members, and it has been incredibly helpful in determining next steps to take.

When we set out with our Certificate Transparency Policy, we wanted to provide a framework for what we believed a healthy ecosystem would or could look like. Knowing that not every aspect of Certificate Transparency would be ready on Day 1, knowing that this system needed time to bootstrap and evolve as more parties participated, we sought to provide a rough framework that addressed a number of concerns we felt were relevant, in part gleaned from lessons learned interacting with CAs in the Web PKI, while also realizing that it wasn’t going to be a perfect or complete solution. We’ve certainly seen the policy evolve over time; notably, elements regarding the ‘independence’ of logs, which was designed solely as a interim bootstrap system, prove too ambiguous and complicated to understand, and were replaced with a more consistent one-Google/one-non-Google. Similarly, when it came time to actively disqualify a log, we realized that the policy was too restrictive in some ways, and so was ‘opened up’ to provide better clarity and minimize disruption with disqualification.

When the policy was first drafted, a real concern was ensuring that log operators didn’t operate their logs the way CAs operate their OCSP, CRL, and AIA systems. That is, high latency, spontaneous downtime, inconsistency, and otherwise general apathy towards the impact they have on the ecosystem. We wanted to ensure that logs provided value - to CAs and to relying parties - by being competently operated with sufficient uptime that they positively contributed, rather than being a drain of issues to work around. In addition to these practical concerns, we noted that downtime was a way to hide mistakes, therefore, there needed to be some limit to that. 99% uptime reflects that - an available system, but one with a relatively generous budget for downtime.

In implementing the policy, we wanted to ensure that that there was flexibility to correct for mistakes and misunderstandings. Unlike the Web PKI, which has two decades of experience, and nearly a decade of intense scrutiny and supervision, the CT ecosystem is very young, and we want to foster an ecosystem that encourages and rewards experimentation, appropriately balances externalities, and mitigates outright maliciousness. Not all elements of the policy are created equal, nor meant to be enforced equally. While there are some unforgivable and completely verifiable operations - such as providing a split view of a log - others, such as failing to update a Chrome bug in a timely fashion, are the type that are less serious in isolation, and only become significant when they become repeated issues.

In this thinking, the Aviator incident is not one that represents a need for immediate disqualification and distrust, on the basis and nature of the circumstances. There’s been sufficient discussion in the linked thread exploring ways in which the current policies’ language regarding MMD is insufficiently clear, or has obvious loopholes. Whether or not an MMD represents a significant security issue to warrant immediate distrusting is clearly a point of debate, but from the point of view of Chromium, unless accompanied with other incidents, or repeated, it’s not in itself an immediate security concern and needing for a strong response.

As such, Aviator will not be disqualified for a single incident, much in the way the logs of Venafi and DigiCert have not been disqualified for single incidents, or even Symantec’s multiple issues. We believe this action is consistent with our policy and principles, with the treatment received of other logs, and most importantly, essential towards a healthier ecosystem by providing the safety to occasionally make mistakes without having to worry about immediate disqualification.

Despite this, we understand that some people will incorrectly feel this is favoring a Google-operated log, despite the evidence and arguments to the contrary. To mitigate this concern, the Google CT team responsible for operating Aviator have agreed to shut down Aviator, and will no longer accept new certificates. It will remain qualified, for purposes of determining the compliance status of a certificate, however, no new SCTs will be issued. Upon completion of ‘freezing’ the log, a known STH will be published, and the inclusion status of a given certificate can be evaluated against this STH. If a certificate cannot be provably incorporated, that will be akin to providing a split view, and will result in the immediate disqualification.

This path is not a special option; it’s the same path that would be pursued for any other log operator that wished to exit operation. Once a log is ‘frozen’, anyone, without needing any special access, can operate a full read-only mirror and provide inclusion proofs for any certificates. This is an option which is viable for all CT implementors, should they decide they don’t wish to trust Google-operated services, much in the same way that the Chrome team would trust Google-run mirrors for any third-party log that wished to be frozen.

By freezing a log, the holder of the private key is still technically capable of misissuing an SCT, so there is still an element of trust still placed. However, this trust can be verified through the existing, known means - such as fetching inclusion proofs - and detected as such through methods like gossip.

It is hoped that this represents a balance of the concerns for most users, although we understand that there are some participants who will be unsatisfied with this result. However, we think a zero tolerance policy is unacceptably prescriptive at this point in time, and leads to significantly more uncertainty and risk in operating a CT log than the value it would provide to users.

Further, it’s clear that a number of areas with respect to the policy can be improved. From discussing with other user agents, it’s become evident that not all of the threat models and concerns that the policy attempted to address are clear or obvious. From discussing with log operators, both current and potential future log operators, we’ve heard a number of concerns with the policy as written. From the general public, we’ve heard concerns about the direction the ecosystem is headed towards and providing greater transparency for that. And, of course, we have a desire to ensure the vision for CT is one that is not a Google-vision but a communal vision, while at the same time, being concerned with some of the directions and patterns we’ve seen.

Because of all of this, Google will be hosting a Certificate Transparency Summit, preferably sometime in January, to provide the opportunity to collaborate and discuss the issues related to logs and log policies, between implementers, operators, monitors, auditors, and relying parties. While a full agenda is still being developed, the goal is to focus on issues related to policies related to log inclusion and diversity, such as qualifying a certificate as sufficiently disclosed, rather than on CA-specific issues related to CT. For those unable to attend in person, we will be working on ensuring the ability for remote participation and discussion.

Hopefully, this will provide the opportunity to better understand and discuss the needs of all participants, and lead to productive and significant improvements to the policy and the overall ecosystem.

[Gervase Markham]

Hi Ryan,

On 15/11/16 01:51, Ryan Sleevi wrote:
> Thanks to everyone who participated in the discussion regarding
> Aviator’s issue with exceeding its MMD. This was a long and productive
> discussion, with feedback from a wide variety of community members, and
> it has been incredibly helpful in determining next steps to take.

Thanks for this writeup. This seems like a good outcome to me.

Is it known whether the managers of Aviator plan to start a new log
using that infra (and hand over the job of serving the read-only version
of the log to other hardware) or are things going to stay the same?

Gerv

[Rob Stradling]

On 15/11/16 01:51, Ryan Sleevi wrote:

<snip>
> ...the Google CT team responsible for operating Aviator have agreed

> to shut down Aviator, and will no longer accept new certificates.

When will this shutdown occur?

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Ryan Sleevi]

On Tue, Nov 15, 2016 at 1:23 AM, Gervase Markham <ge...@mozilla.org> wrote:

Is it known whether the managers of Aviator plan to start a new log
using that infra (and hand over the job of serving the read-only version
of the log to other hardware) or are things going to stay the same?

Did you mean hardware or software?

In either event, I don't know, because it did not seem particularly relevant to the issue or to the overall trust equation, nor would it be something that would be publicly or independently verifiable. What is verifiable is the consistency of the operation and the adherence to being 'frozen', and that's a relatively simple matter to validate. 

With respect to Chrome's specific trust decision, the Chrome team is satisfied that they have a suitable mirror of Aviator to use in evaluating any trust decision, as do a number of independent entities (and it's quite easy to clone), so the significance of uptime, for a frozen log, is much less significant or relevant. The requirement exists primarily to ensure a suitable ecosystem for CAs and relying parties - freezing obviates the former concern, and the existence of a Chrome mirror of the data, at least from a Chrome perspective, largely obviates the latter.

[Gervase Markham]

On 16/11/16 03:52, Ryan Sleevi wrote:
> Did you mean hardware or software?

Either :-)

> In either event, I don't know, because it did not seem particularly
> relevant to the issue or to the overall trust equation, nor would it be
> something that would be publicly or independently verifiable.

Indeed not - I agree it's not relevant to the decision. I'm just
interested :-)

Gerv

[Eran Messeri]

Below are my educated guesses, which have not been vetted by the rest of the CT team yet:

* The read-only version of Aviator will be served over the same infrastructure that Aviator currently runs on (both hardware and software). That's simply because moving it may be more work than making it read-only.

* Two new Google logs were recently added to Chromium (both based on the same codebase, but not the same hardware physically - different logs are usually distributed among different datacenters), so CAs can already migrate to them. I don't know if we'll submit another one for inclusion.

But as I mentioned, please take my reply with a grain of salt - the team may come to different conclusions as work to comply with Chrome's decision progresses.

Gerv

--
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+unsubscribe@chromium.org.
To post to this group, send 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/c0a69aca-bbbf-a6a7-bde5-9fab1272a1ed%40mozilla.org.

[Doug Beattie (Globalsign)]

We'd also like to know when the Aviator shutdown will happen so we can plan accordingly.  I'm assuming the log status will be updated when the log is frozen (and hopefully a bit before for planning purposes): https://bugs.chromium.org/p/chromium/issues/detail?id=389514 

Doug

[Ryan Sleevi]

On Tue, Nov 15, 2016 at 3:23 AM, Rob Stradling <rob.st...@comodo.com> wrote:

On 15/11/16 01:51, Ryan Sleevi wrote:
<snip>
> ...the Google CT team responsible for operating Aviator have agreed
> to shut down Aviator, and will no longer accept new certificates.

When will this shutdown occur?

Apologies for not seeing this message.  This shutdown will occur on 2016/12/01.

[Ryan Sleevi]

On Mon, Nov 21, 2016 at 5:24 AM, Doug Beattie (Globalsign) <douglas...@gmail.com> wrote:

We'd also like to know when the Aviator shutdown will happen so we can plan accordingly.  I'm assuming the log status will be updated when the log is frozen (and hopefully a bit before for planning purposes): https://bugs.chromium.org/p/chromium/issues/detail?id=389514 

Doug

Hi Doug,

Could you be more precise what you mean by "the log status will be updated"? There's several possible meanings for that, so I'm hoping you can clarify. 

[Doug Beattie (Globalsign)]

Ryan,

The sequence of comments on that page provides a good history of change control for the status and the adding of roots.  I would assume (could be wrong) you'd place a comment that all roots were removed and/or that the log has been "frozen".  When the Wosign log was removed you made an entry like this, so maybe just linking to your formal announcement of the status is sufficient to let people know that look at this server inclusion log.

"We've shared this on https://groups.google.com/a/chromium.org/d/msg/ct-policy/LE0AlqMHISQ/L7EGfOQvCQAJ and on pub...@cabforum.org to ensure all affected parties are informed."

[Ryan Sleevi]

Thanks for clarifying what you meant. I was unclear if you meant a page on certificate-transparency.org, the formal update to ct-policy just sent, the bug, to https://www.chromium.org/Home/chromium-security/certificate-transparency, or to some other page. 

--

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+unsubscribe@chromium.org.
To post to this group, send 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/284b261f-8f76-4c7f-b6e6-61aa4496c072%40chromium.org.