Log diversity requirements for Mozilla

[Gervase Markham]

I'd like to have a specific discussion about what, if any, log diversity
requirements Mozilla should have.

As our CT Policy's explanatory notes explain:

"When CT is fully deployed, it will not be necessary to trust log
operators, because malicious logs will be detectable. However, this
requires certain technical infrastructure to be in place which are not
there today, and so at the moment logs are effectively trusted in
themselves. One way of mitigating this problem is having a log diversity
requirement, which is designed to reduce the possibility of two logs
being coerced to, or collaborating to, act wrongly, and this being
usable in an attack. The current draft of the policy does not have such
a requirement."

The magic figure of two is because both Mozilla and Google require at
least two SCTs to be presented, and so anyone doing an attack would
obviously coerce the minimum number of logs they needed.

It seems like we have the following options:

0) Specify nothing. CAs will still do Google/non-Google because Google
requires it, and that's good enough. Eventually, gossip will solve the
problem.

1) Google/non-Google requirement. Upon consideration, it seems wrong for
Mozilla to require CAs to get a service from a particular supplier. This
is also effectively equivalent to option 0) because the effective CT
policy is the union of all CT policies.

2) Operator diversity. Require that the logs not all be operated by the
same entity (and we would need to define what that means). This would be
effectively equivalent to option 1), and therefore to option 0), except
that if Google removed their requirement (perhaps because Chrome
implemented gossip), ours could remain.

3) Mozilla/non-Mozilla requirement. I.e., set up a set of Mozilla logs
and require these to be used. Even if we wanted to pay the significant
technical, personnel and financial cost of setting up enough logs for
this to work (we'd need to be robust against log failure; Google has
five (?), and it seems like they need that many!), the end result would
be CAs logging to Google and Mozilla as their two logs, and most other
logs being driven from the market, or only used for longer-lived certs.
This does not seem conducive to a healthy log ecosystem. It's also not a
great example and doesn't scale - will Microsoft require use of a
Microsoft log, and Opera an Opera log, and so on?

4) Geographic diversity. Require the logs not all to be located in the
same country. I think that when people propose this, what they actually
mean is option 5).

5) Jurisdictional diversity. Require that one single government not have
the power to coerce all the logs. The way one might implement this is as
follows: request all log operators (perhaps in consultation with their
lawyers) to produce a list of ISO country codes, the governments of
which have the power to compel the private key of a log. So if a log
operator has their HQ in France but their data centre (where the key
sits) in Spain, they might say "(fr, es)". Another log operator which
was a US company with data centres in the US might simply say "(us)".
The code would associate this set of jurisdictions with each log, and
would require that the same country code not appear in the list of _all_
the logs whose SCTs are presented with a certificate.


Thoughts?

Gerv

[Rob Stradling]

On 28/11/16 12:01, Gervase Markham wrote:
<snip>

> 2) Operator diversity. Require that the logs not all be operated by the
> same entity (and we would need to define what that means). This would be
> effectively equivalent to option 1), and therefore to option 0), except
> that if Google removed their requirement (perhaps because Chrome
> implemented gossip), ours could remain.

Some CAs are also log operators. Whilst some potential diversity
requirements might be controversial, I'd like to think that it would be
non-controversial to require, at the very least, that each (EV)
certificate must be accompanied by at least 1 SCT from a log that is not
operated by that certificate's issuer.

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

[Gervase Markham]

On 28/11/16 12:21, Rob Stradling wrote:
> On 28/11/16 12:01, Gervase Markham wrote:
> <snip>
>> 2) Operator diversity. Require that the logs not all be operated by the
>> same entity (and we would need to define what that means). This would be
>> effectively equivalent to option 1), and therefore to option 0), except
>> that if Google removed their requirement (perhaps because Chrome
>> implemented gossip), ours could remain.
>
> Some CAs are also log operators. Whilst some potential diversity
> requirements might be controversial, I'd like to think that it would be
> non-controversial to require, at the very least, that each (EV)
> certificate must be accompanied by at least 1 SCT from a log that is not
> operated by that certificate's issuer.

This seems strictly weaker than 2), although I don't think 2) would be
particularly controversial. One disadvantage of 2) is that you have to
work out which CAs and logs are under common ownership, but that issue
remains with your version, doesn't it?

Gerv

[Rob Stradling]

I agree that 2) doesn't look controversial today, because Chrome
currently requires at least 1 Google log plus at least 1 non-Google log.
But you were speculating a possible future in which Chrome drops this
diversity requirement.

Yes, my suggestion is strictly weaker than 2). But, just in case 2)
does become controversial, I think it would be better to settle on a
weaker, non-controversial diversity requirement than on no diversity
requirement at all.

[Richard Salz]

Yes, my suggestion is strictly weaker than 2).  But, just in case 2) does become controversial, I think it would be better to settle on a weaker, non-controversial diversity requirement than on no diversity requirement at all.

Or propose it and wait to see if it *is* controversial. I strongly prefer multiple logs not under the same ownership.  I am wonder how that would be implemented in the code with becoming, well, kinda gross. :)

[Eran Messeri]

My understanding is that a log diversity requirement is in Chromium's policy to deal with two potential risks:

(a) Difficulty of correctly operating CT logs (logs issuing SCTs but failing to publish entries repeatedly).

(b) CT logs being coerced to issue SCTs without logging the corresponding entries.

(Note this is my own view, others on the CT team/Chrome team may have a different understanding).

The implication of (a) is the public doesn't get to see issued certificates on a regular basis, while (b) implies a particular certificate is hidden from the public.

My understanding is that the Google/Non-Google requirement was put in place mostly to avoid (a), under the assumption that the CT logs operated by Google are less likely to lose submissions.

Now that there are more stable CT log implementations and almost all CT logs are mirrored, it seems to me there's less justification to require logging to one Google log.

However to protect (as much as possible) against (a) and (b), it seems to me at least two SCTs are still desirable. 

The closest option is (2) - operator diversity, which would pretty much cover (a) and covers (b) to a greater extent than allowing SCTs from logs operated by the same operator.

To better protect against (b), option (5) seems more suitable, but it seems to me like a lot of work for everybody involved - log operators, monitors and User Agents.

The mechanism intended to protect against (b) is log auditing and gossip (I'm still working on log auditing in Chrome  - https://crbug.com/506227). I personally believe we could get better results there than if we were to spend efforts trying to figure out which logs are in which jurisdictions.

On Mon, Nov 28, 2016 at 12:57 PM, Richard Salz <rich...@gmail.com> wrote:

Yes, my suggestion is strictly weaker than 2).  But, just in case 2) does become controversial, I think it would be better to settle on a weaker, non-controversial diversity requirement than on no diversity requirement at all.

Or propose it and wait to see if it *is* controversial. I strongly prefer multiple logs not under the same ownership.  I am wonder how that would be implemented in the code with becoming, well, kinda gross. :)

--
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/CAFH29toL-4O6tRC5BxV-%2BuWipedZ978bJWaFgmggCdEOpM%2BjTw%40mail.gmail.com.

[Ryan Sleevi]

On Mon, Nov 28, 2016 at 9:31 AM, Eran Messeri <er...@chromium.org> wrote:

My understanding is that a log diversity requirement is in Chromium's policy to deal with two potential risks:

(a) Difficulty of correctly operating CT logs (logs issuing SCTs but failing to publish entries repeatedly).

(b) CT logs being coerced to issue SCTs without logging the corresponding entries.

(Note this is my own view, others on the CT team/Chrome team may have a different understanding).

The actual concern was almost exclusively (b). (a) is just a pragmatic decision to require some risk mitigation, rather than allow CAs to engage in risky behaviour (for example, using all the logs from one operator, who is then coerced or compromised under (b), and as a result, all logs are rejected).

My understanding is that the Google/Non-Google requirement was put in place mostly to avoid (a), under the assumption that the CT logs operated by Google are less likely to lose submissions.

Now that there are more stable CT log implementations and almost all CT logs are mirrored, it seems to me there's less justification to require logging to one Google log.

No, it was mostly put in place to avoid (b).

That is, the risk of log operators being coerced - or compromised - is compelling enough to require some mitigation. Gossip and inclusion proof checking mitigate this, to an extent, by raising the costs to attackers to be significant, both technically and legally. However, in the absence of inclusion proof checking, the next best solution is to rely on a party we can trust (in effect, Google), on the basis that anything that could be accomplished via legal means could also be said to affect Chrome (e.g. compelled backdoor in native code), and on the basis that compromise of Google is unlikely, assuming the CT logs are operated to the same Google high-standards ;)

 

However to protect (as much as possible) against (a) and (b), it seems to me at least two SCTs are still desirable. 

The closest option is (2) - operator diversity, which would pretty much cover (a) and covers (b) to a greater extent than allowing SCTs from logs operated by the same operator.

The problem with (2) is that it leaves a lot of (b) open. For example, imagine three logs hosted on Amazon AWS (or Microsoft Azure or Google Container Engine), each run by different legal entities. Do they all share the same risk of compulsion (or compromise) that a single log has? For example, if you compromise AWS, could you effectively compromise those three logs? Could you compel Amazon (or Google or Microsoft) to use the key w/o the customers consent? Are these valid concerns to be worried about?

If you consider 'offline' as part of the threat model, and you use a log with a single network connection, can it be easily coerced to provide a split-view (e.g. by a nationstate)?

I agree that two SCTs (at minimum) is a mitigation for both (a) and (b), but it's unclear if it's sufficient.

 

To better protect against (b), option (5) seems more suitable, but it seems to me like a lot of work for everybody involved - log operators, monitors and User Agents. 

The mechanism intended to protect against (b) is log auditing and gossip (I'm still working on log auditing in Chrome  - https://crbug.com/506227). I personally believe we could get better results there than if we were to spend efforts trying to figure out which logs are in which jurisdictions.

Right, from a not-a-lawyer question of legality - can an entity affirmatively produce all the jurisdictions they are subject to? When a jurisdiction attempts to apply a particular policy, perhaps using a novel interpretation that the company in question disagrees with, are they at fault for not disclosing it? Can they be compelled to not report on that? Questions of legality and scope of infrastructure are largely what doomed the 'independence' requirement, but I wouldn't be sad to see some degree of operational guidance regarding independence being introduced or mandated. Just that I don't think it'll solve (b). 

[Andrew Ayer]

On Mon, 28 Nov 2016 12:01:30 +0000
Gervase Markham <ge...@mozilla.org> wrote:

> I'd like to have a specific discussion about what, if any, log
> diversity requirements Mozilla should have.
>
> As our CT Policy's explanatory notes explain:
>
> "When CT is fully deployed, it will not be necessary to trust log
> operators, because malicious logs will be detectable. However, this
> requires certain technical infrastructure to be in place which are not
> there today, and so at the moment logs are effectively trusted in
> themselves. One way of mitigating this problem is having a log
> diversity requirement, which is designed to reduce the possibility of
> two logs being coerced to, or collaborating to, act wrongly, and this
> being usable in an attack. The current draft of the policy does not
> have such a requirement."
>
> The magic figure of two is because both Mozilla and Google require at
> least two SCTs to be presented, and so anyone doing an attack would
> obviously coerce the minimum number of logs they needed.
>
> It seems like we have the following options:
>
> 0) Specify nothing. CAs will still do Google/non-Google because Google
> requires it, and that's good enough.

I'm afraid it's not good enough under adversarial conditions. Legitimate
certificates will be served with SCTs from both a Google log and a
non-Google log, but an adversary who only wants to target Mozilla users
can serve phony SCTs from whatever logs they can compromise.

> Eventually, gossip will solve the problem.

Unless SCT checking/gossip is right around the corner, option 0 seems
unacceptable.

> 1) Google/non-Google requirement. Upon consideration, it seems wrong
> for Mozilla to require CAs to get a service from a particular
> supplier.

Why? The Google logs have an open acceptance policy and do not charge
CAs for service. All CAs have to get service from Google anyways
if they want their certificates to work in Chrome. Unless a CA can
say with a straight face that they want to issue certificates that
work in Mozilla but not Chrome, I don't understand this argument.

Over the long term it would be problematic for Mozilla to rely on trusting
Google in lieu of SCT checking, but this is not expected to be a long
term policy.

> This is also effectively equivalent to option 0) because
> the effective CT policy is the union of all CT policies.

Not quite, because this policy is enforced by software. If Mozilla
opts not to enforce another browser's CT policy, Mozilla users will
be vulnerable to certs that don't comply with that browser's policy.

The effective CT policy is the union of all CT policies only for well-behaved
CAs, not for attackers.

> 2) Operator diversity. Require that the logs not all be operated by
> the same entity (and we would need to define what that means). This
> would be effectively equivalent to option 1), and therefore to option
> 0), except that if Google removed their requirement (perhaps because
> Chrome implemented gossip), ours could remain.
>
> 3) Mozilla/non-Mozilla requirement. I.e., set up a set of Mozilla logs
> and require these to be used. Even if we wanted to pay the significant
> technical, personnel and financial cost of setting up enough logs for
> this to work (we'd need to be robust against log failure; Google has
> five (?), and it seems like they need that many!), the end result
> would be CAs logging to Google and Mozilla as their two logs, and
> most other logs being driven from the market, or only used for
> longer-lived certs. This does not seem conducive to a healthy log
> ecosystem. It's also not a great example and doesn't scale - will
> Microsoft require use of a Microsoft log, and Opera an Opera log, and
> so on?

I agree this would be terrible for the ecosystem.

> 4) Geographic diversity. Require the logs not all to be located in the
> same country. I think that when people propose this, what they
> actually mean is option 5).
>
> 5) Jurisdictional diversity. Require that one single government not
> have the power to coerce all the logs. The way one might implement
> this is as follows: request all log operators (perhaps in
> consultation with their lawyers) to produce a list of ISO country
> codes, the governments of which have the power to compel the private
> key of a log. So if a log operator has their HQ in France but their
> data centre (where the key sits) in Spain, they might say "(fr, es)".
> Another log operator which was a US company with data centres in the
> US might simply say "(us)". The code would associate this set of
> jurisdictions with each log, and would require that the same country
> code not appear in the list of _all_ the logs whose SCTs are
> presented with a certificate.

I think that #1 is the most practical option. #2 and #5 may be
more principled, but it's quite difficult to define operational and
jurisdictional control, and to verify the accuracy of the information
provided by log operators. Mozilla and the community could end up
spending a lot of time and effort on this, which seems rather pointless
for what is intended to be only a temporary requirement. Meanwhile, #1
is easy to implement and all CAs will be complying with it anyways.

Regards,
Andrew

[Gervase Markham]

On 28/11/16 23:29, Ryan Sleevi wrote:
> Right, from a not-a-lawyer question of legality - can an entity
> affirmatively produce all the jurisdictions they are subject to? When a
> jurisdiction attempts to apply a particular policy, perhaps using a
> novel interpretation that the company in question disagrees with, are
> they at fault for not disclosing it?

No. If we were to implement 5), I think we would need to assume that the
log produced the list at the time of submission in good faith. After
all, hopefully, they produce said list when not under compulsion; in
this threat model, the compulsion comes later.

I think that logs would be permitted to add jurisdictions to the list
over time if they felt it appropriate, but not remove them.

> on that? Questions of legality and scope of infrastructure are largely
> what doomed the 'independence' requirement,

As in, the legality of imposing it? Or merely legal questions
surrounding how you would define it and who would be accountable for the
accuracy of the information?

Gerv

[Gervase Markham]

On 29/11/16 04:21, Andrew Ayer wrote:
> I'm afraid it's not good enough under adversarial conditions. Legitimate
> certificates will be served with SCTs from both a Google log and a
> non-Google log, but an adversary who only wants to target Mozilla users
> can serve phony SCTs from whatever logs they can compromise.

Very good point.

> Why? The Google logs have an open acceptance policy and do not charge
> CAs for service. All CAs have to get service from Google anyways
> if they want their certificates to work in Chrome. Unless a CA can
> say with a straight face that they want to issue certificates that
> work in Mozilla but not Chrome, I don't understand this argument.

There's a difference between Mozilla mandating that people use a Google
service, and Google mandating it.

> Over the long term it would be problematic for Mozilla to rely on trusting
> Google in lieu of SCT checking, but this is not expected to be a long
> term policy.

Nothing endures like the temporary :-)

> The effective CT policy is the union of all CT policies only for well-behaved
> CAs, not for attackers.

Again, a point well made. This makes option 2), as a minimum, make a lot
more sense.

Gerv

[Matt Palmer]

On Mon, Nov 28, 2016 at 12:01:30PM +0000, Gervase Markham wrote:
> It seems like we have the following options:
>
> 0) Specify nothing. CAs will still do Google/non-Google because Google
> requires it, and that's good enough. Eventually, gossip will solve the
> problem.

Do you (or anyone else on list) have any indications of when the gossip spec
is likely to land? My impression from the trans WG list is that it's slowly
moving forward, chewing through the thorny problems to be solved, but I
don't have an impression of how far away from "done" things are. It might
be useful to have some idea of where that's up to, to inform our thinking
around the need for diversity.

> 1) Google/non-Google requirement.

I was a bit uncomfortable with Mozilla mandating dependence on another
browser vendor when I read the initial draft, but I couldn't think of an
alternative so I didn't bring it up. I'm glad it's being raised now.
<grin>

> Upon consideration, it seems wrong for Mozilla to require CAs to get a
> service from a particular supplier.

Is this specifically s/particular supplier/particular third-party supplier/,
or do you feel that this should (in general) preclude Mozilla from mandating
that a CA use a Mozilla service (which is option 3)? I'm assuming it's the
former, but I want to make sure I'm clear on exactly where you think the
line is.

> This is also effectively equivalent to option 0) because the effective CT
> policy is the union of all CT policies.

Should this be the other way around, ie. picking option 0 (no diversity)
would effectively be picking option 1 because Chromium's going to continue
to mandate Google/non-Google? I don't really see this as an important
distinction, because no matter what Mozilla chooses, I presume Chromium's
gonna Chromium, so "union of all policies" is going to cause everyone to log
Google/non-Google.

> 3) Mozilla/non-Mozilla requirement. I.e., set up a set of Mozilla logs
> and require these to be used. Even if we wanted to pay the significant
> technical, personnel and financial cost of setting up enough logs for
> this to work (we'd need to be robust against log failure; Google has
> five (?), and it seems like they need that many!), the end result would
> be CAs logging to Google and Mozilla as their two logs, and most other
> logs being driven from the market, or only used for longer-lived certs.
> This does not seem conducive to a healthy log ecosystem. It's also not a
> great example and doesn't scale - will Microsoft require use of a
> Microsoft log, and Opera an Opera log, and so on?

Yeah, this is an ugly option that only ends in tears. I wouldn't worry too
much about the "log market", though; open access logs operated by altruistic
third parties seem to be the way things are going to go.

> 2) Operator diversity. Require that the logs not all be operated by the
> same entity (and we would need to define what that means). This would be
> effectively equivalent to option 1), and therefore to option 0), except
> that if Google removed their requirement (perhaps because Chrome
> implemented gossip), ours could remain.

I think the practical impossibility of cataloguing the webs of control and
influence, given the behind-the-scenes dealings that go on amongst
companies, makes this a complete non-starter.

> 4) Geographic diversity. Require the logs not all to be located in the
> same country. I think that when people propose this, what they actually
> mean is option 5).
>
> 5) Jurisdictional diversity. Require that one single government not have
> the power to coerce all the logs. The way one might implement this is as
> follows: request all log operators (perhaps in consultation with their
> lawyers) to produce a list of ISO country codes, the governments of
> which have the power to compel the private key of a log. So if a log
> operator has their HQ in France but their data centre (where the key
> sits) in Spain, they might say "(fr, es)". Another log operator which
> was a US company with data centres in the US might simply say "(us)".
> The code would associate this set of jurisdictions with each log, and
> would require that the same country code not appear in the list of _all_
> the logs whose SCTs are presented with a certificate.

Whilst legal compulsion is a risk, from my mental catalogue of spectacular
CA malfeasance (the closest analogue to a misbehaving log) it's more common
for intrusion and customer satisfaction to cause problems than legal
proceedings.

Given that a log is accessible over the Internet, I'd say it's at least as
likely that someone's going to exfiltrate (or cause to be misused, say in a
HSM) the log's private key than it is for a secret legal order to cause a
log to misbehave. Thus, the set of countries "which have the power to
compel the private key of a log" for every log would be "any country capable
of penetrating a log's infrastructure", which is likely to be a fairly long
list, especially once third-party contracting is included.

In summary: all of these options suck, simply because this is a really
complex problem. Using the concept of "the simplest thing that could
possibly work", I'm inclined to advocate for option 0 (no specific diversity
requirement) because it imposes the least additional obligation on everyone
involved.

I know that this approach devolves to "I trust Google to keep the Internet
safe", and it surprises even me to be saying that. However, the resources
required to implement any other approach suggested so far (and I don't have
any other ideas to add to the pile) would be better spent in making
diversity requirements unnecessary -- either helping move the gossip system
towards completion, or developing other approaches to making logs the
untrustable third parties they should be.

- Matt

[Andrew Ayer]

On Tue, 29 Nov 2016 14:35:34 +0000
Gervase Markham <ge...@mozilla.org> wrote:

> > Why? The Google logs have an open acceptance policy and do not
> > charge CAs for service. All CAs have to get service from Google
> > anyways if they want their certificates to work in Chrome. Unless
> > a CA can say with a straight face that they want to issue
> > certificates that work in Mozilla but not Chrome, I don't
> > understand this argument.
>
> There's a difference between Mozilla mandating that people use a
> Google service, and Google mandating it.

I see there's a difference, but that doesn't answer the question
of why it's wrong.

> > Over the long term it would be problematic for Mozilla to rely on
> > trusting Google in lieu of SCT checking, but this is not expected
> > to be a long term policy.
>
> Nothing endures like the temporary :-)
>
> > The effective CT policy is the union of all CT policies only for
> > well-behaved CAs, not for attackers.
>
> Again, a point well made. This makes option 2), as a minimum, make a
> lot more sense.

If Mozilla went with #2, all CAs are certain to comply with it by
logging to one Google log and one non-Google log as long as Chrome has
that requirement. Mozilla would expend effort trying to figure out
organizational control, but in the end no CA would take advantage of the
flexibility #2 offers over #1, and Mozilla users would be at risk if an
assumption of organizational independence turned out to be incorrect.
That seems like all downside to me.

Here's another option: every log's metadata contains the log's
ostensible operator. Mozilla defines a list of approved operator pairs.
To satisfy the diversity requirement, SCTs must be presented from a log
operated by each operator in an approved pair. Initially, Google would
be paired with every other operator. If a CA wants to use a different
pair, they could propose it. Mozilla would publicly discuss the proposal,
evaluate the independence of the operators, and then approve or reject it.

This option does not mandate service from Google, and it defers the
work and risk of option #2 until a demand actually materializes for it,
which might never occur.

Regards,
Andrew

[Tom Ritter]

On 28 November 2016 at 19:23, Matt Palmer <mpa...@hezmatt.org> wrote:
> On Mon, Nov 28, 2016 at 12:01:30PM +0000, Gervase Markham wrote:
>> It seems like we have the following options:
>>
>> 0) Specify nothing. CAs will still do Google/non-Google because Google
>> requires it, and that's good enough. Eventually, gossip will solve the
>> problem.
>
> Do you (or anyone else on list) have any indications of when the gossip spec
> is likely to land? My impression from the trans WG list is that it's slowly
> moving forward, chewing through the thorny problems to be solved, but I
> don't have an impression of how far away from "done" things are. It might
> be useful to have some idea of where that's up to, to inform our thinking
> around the need for diversity.

I had thought this was announced on [trans] but we (the authors) are
'done' with it. There may be a few TODOs in the draft, but it's at the
stage where we want people to read it carefully and discuss the finer
points of the implementation _as well as_ the merits of its approach
overall.

For an example of the latter - the spec is very complicated. SCT
Feedback and STH Pollination are complementary but each one is
non-trivial to implement well. Google (I think) has a plan to bypass
the need for pollination by pushing STHs to the clients but I am not
certain it stands up against the type of threat model we are (attempt
to) defend against in our draft. I'd like to discuss this (on
[trans]!) and see if my thinking is correct or not.

-tom

[Gervase Markham]

On 29/11/16 20:39, Andrew Ayer wrote:
> I see there's a difference, but that doesn't answer the question
> of why it's wrong.

For an organization which is generally in favour of choice and
innovation, single supplier mandates are something ideally to be
avoided. Particularly if the supplier is technically a competitor (even
though we collaborate well too :-).

> If Mozilla went with #2, all CAs are certain to comply with it by
> logging to one Google log and one non-Google log as long as Chrome has
> that requirement.

But Chrome may not always have it.

> Here's another option: every log's metadata contains the log's
> ostensible operator. Mozilla defines a list of approved operator pairs.
> To satisfy the diversity requirement, SCTs must be presented from a log
> operated by each operator in an approved pair. Initially, Google would
> be paired with every other operator. If a CA wants to use a different
> pair, they could propose it. Mozilla would publicly discuss the proposal,
> evaluate the independence of the operators, and then approve or reject it.

This operator significantly reduces CA flexibility. Say a CA issuing a
2-year cert logs to the first Google log (of 3) which responds, and the
first two non-Google logs (of 6) which respond. The number of
combinatorial assessments they would need to get in order to enable this
is... not small. In the end, you're better off just saying "We think
logs X, Y and Z are co-owned" and letting the owner(s) challenge you if
they think you are wrong.

Gerv

[Gervase Markham]

On 29/11/16 01:23, Matt Palmer wrote:
> Do you (or anyone else on list) have any indications of when the gossip spec
> is likely to land?

I don't have a sense of that.

>> Upon consideration, it seems wrong for Mozilla to require CAs to get a
>> service from a particular supplier.
>
> Is this specifically s/particular supplier/particular third-party supplier/,
> or do you feel that this should (in general) preclude Mozilla from mandating
> that a CA use a Mozilla service (which is option 3)? I'm assuming it's the
> former, but I want to make sure I'm clear on exactly where you think the
> line is.

I think that mandating the use of a Mozilla service is less problematic,
because we know the service will always be run in line with our
principles :-) But it would be more preferable still not to mandate any
single supplier.

> I think the practical impossibility of cataloguing the webs of control and
> influence, given the behind-the-scenes dealings that go on amongst
> companies, makes this a complete non-starter.

I'm not as pessimistic as you :-)

Gerv

[Matt Palmer]

On Wed, Nov 30, 2016 at 04:16:21PM +0000, Gervase Markham wrote:
> On 29/11/16 01:23, Matt Palmer wrote:
> >> Upon consideration, it seems wrong for Mozilla to require CAs to get a
> >> service from a particular supplier.
> >
> > Is this specifically s/particular supplier/particular third-party supplier/,
> > or do you feel that this should (in general) preclude Mozilla from mandating
> > that a CA use a Mozilla service (which is option 3)? I'm assuming it's the
> > former, but I want to make sure I'm clear on exactly where you think the
> > line is.
>
> I think that mandating the use of a Mozilla service is less problematic,
> because we know the service will always be run in line with our
> principles :-) But it would be more preferable still not to mandate any
> single supplier.

OK, thanks for that clarification.

> > I think the practical impossibility of cataloguing the webs of control and
> > influence, given the behind-the-scenes dealings that go on amongst
> > companies, makes this a complete non-starter.
>
> I'm not as pessimistic as you :-)

Few people are. That doesn't mean I'm *wrong*, though, merely that I'm not
much fun at parties.

Using the recent WoSign/Startcom merger as an example, how is a change of
control even that straightforward expected to be detected in near-real-time,
so that colluding logs can be quickly distrusted before damage is done? I
know that the web of control was discovered, through the detective work of
several people, but that was only after significant attention was raised
about the acquisition in concert with other issues.

If an acquisition was executed in a more stealthy manner, as would be the
case if, say, someone *did* actually want to issue shady CT-enabled certs,
do you realistically believe that Mozilla, would be capable of noticing that
in a timely manner? If so, how do you believe that would occur?

- Matt