Mozilla CT Policy: discussion location

[Gervase Markham]

mozilla.dev.security.policy has become the /de facto/ place for
discussion root program policy relating to the Web PKI, not just for
Mozilla, because people want to take advantage of the expertise of the
members here. Mozilla is very happy to host these wider discussions, in
the name of making the Internet and the Web PKI a more secure and
better-functioning place.

Similarly, ct-pol...@chromium.org has so far been the place for
discussing CT policy. Ryan has kindly offered to permit Mozilla to have
our CT policy discussions on that list, taking advantage of the
expertise there.

So, I have drafted a version 0.0.1 of the Mozilla CT policy, and will
soon post it to ct-pol...@chromium.org. If you want to be part of that
conversation, you will need to subscribe, which you can do here:
https://groups.google.com/a/chromium.org/forum/#!forum/ct-policy

I am unfortunately not aware of an NNTP mirror of this group, and Gmane
is currently in a transition which means that adding new groups is not
supported. If anyone knows of such a mirror, please let me know.

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla CT Policy

[Ryan Sleevi]

On Tue, Nov 8, 2016 at 12:07 PM, Jakob Bohm  wrote:
> I was responding to your simplistic argument that the existence of
> ownership change detection failures made diversity requirements
> worthless.  I was not calculating their actual worth compared to other
> measures.

Then that's an argument simply for appearances sake, without providing
any actual value - and the simplistic argument is all that's necessary
to show that it's an unreasonable burden without tangible value.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla CT Policy

[Jakob Bohm]

On 08/11/2016 20:51, Ryan Sleevi wrote:

On Tue, Nov 8, 2016 at 11:24 AM, Jakob Bohm  wrote:

Diversity requirements are about reducing the likelihood of
simultaneous coercion, as it can never be ruled out that some powerful
organization already engaged in such things could use some of its
backhanded tactics to subvert a log operator that is entirely outside
its direct jurisdiction.

History has taught us that such things do happen from time to time.


Having written the original diversity requirement for Chrome, I'm
quite familiar with what they are intended to be used for - I'm just
saying that, as a practical matter, if you work through an actual
threat model, you'll find that they fail rather considerably in
everything other than 'feel good'.

As it specifically relates to CT, it might help if you fully
articulate what you anticipate the threat is - right now, it is
presumably legal coercion - and then think about how, using the
existing logs, you would quantify that risk.

The counter-argument against diversity requirements is that, rather
than relying of policy elements around unquantifiable or, for an
organization of both Mozilla and Google's side, unrealistic, data
points, you can instead rely on technical measures that provide the
same assurances. Such as checking inclusion proofs of STHs, checking
consistency of STHs, and gossiping views. After exhausting those
technical solutions, question again whether policy is correct.

Similarly, once your threat model is actually articulated, evaluate
the risk of an arbitrary (as it necessarily is) diversity requirement
and its harm on the ecosystem or cost to Mozilla to maintain the
appearances of it, against the practical and perceived risks of being
more liberal.

Trust is a spectrum, and the calculus can be quite difficult, but
again - as the example of WoSign/StartCom/Qihoo showed - it can be
incredibly expensive and unrealistic to think it will be enforced
solely through goodwill. It took nearly 8 months for Mozilla to obtain
sufficient evidence of the relationship between those organizations.
And if you think that's unacceptably long, then perhaps the policy
isn't the right answer, because that's a bit of an optimistic look at
how things go, with multiple people dedicating significant amounts of
time to understand the issues.



I was responding to your simplistic argument that the existence of
ownership change detection failures made diversity requirements
worthless.  I was not calculating their actual worth compared to other
measures.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla CT Policy

[Ryan Sleevi]

On Tue, Nov 8, 2016 at 11:24 AM, Jakob Bohm  wrote:
> Diversity requirements are about reducing the likelihood of
> simultaneous coercion, as it can never be ruled out that some powerful
> organization already engaged in such things could use some of its
> backhanded tactics to subvert a log operator that is entirely outside
> its direct jurisdiction.
>
> History has taught us that such things do happen from time to time.

Having written the original diversity requirement for Chrome, I'm
quite familiar with what they are intended to be used for - I'm just
saying that, as a practical matter, if you work through an actual
threat model, you'll find that they fail rather considerably in
everything other than 'feel good'.

As it specifically relates to CT, it might help if you fully
articulate what you anticipate the threat is - right now, it is
presumably legal coercion - and then think about how, using the
existing logs, you would quantify that risk.

The counter-argument against diversity requirements is that, rather
than relying of policy elements around unquantifiable or, for an
organization of both Mozilla and Google's side, unrealistic, data
points, you can instead rely on technical measures that provide the
same assurances. Such as checking inclusion proofs of STHs, checking
consistency of STHs, and gossiping views. After exhausting those
technical solutions, question again whether policy is correct.

Similarly, once your threat model is actually articulated, evaluate
the risk of an arbitrary (as it necessarily is) diversity requirement
and its harm on the ecosystem or cost to Mozilla to maintain the
appearances of it, against the practical and perceived risks of being
more liberal.

Trust is a spectrum, and the calculus can be quite difficult, but
again - as the example of WoSign/StartCom/Qihoo showed - it can be
incredibly expensive and unrealistic to think it will be enforced
solely through goodwill. It took nearly 8 months for Mozilla to obtain
sufficient evidence of the relationship between those organizations.
And if you think that's unacceptably long, then perhaps the policy
isn't the right answer, because that's a bit of an optimistic look at
how things go, with multiple people dedicating significant amounts of
time to understand the issues.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla CT Policy

[Jakob Bohm]

On 08/11/2016 17:50, Ryan Sleevi wrote:

On Tue, Nov 8, 2016 at 2:05 AM, Gervase Markham  wrote:


...

...


Presumably this is one reason some people are suggesting Mozilla's
policy have a jurisdictional diversity requirement - to make such
coercion harder.


Possibly, but I encourage you to review the past CA/Browser Forum
discussions about CT, and the ct-policy list, to understand why Google
intentionally removed it's "diversity" requirement as being ambiguous
and unenforcable, and contributing more harm than good.

For any system of diversity to be relevant, you must be able to
quantify it, and you must be able to quantify it over time. As the
situation with StartCom/WoSign/Qihoo showed, both Mozilla and the
broader ecosystem are not well suited to continuously monitor the
complex legal system of ownership, let alone nexus' of business
operations. And if you can't be certain, and can't measure it, then
are you actually providing value?



Diversity requirements are about reducing the likelihood of
simultaneous coercion, as it can never be ruled out that some powerful
organization already engaged in such things could use some of its
backhanded tactics to subvert a log operator that is entirely outside
its direct jurisdiction.

History has taught us that such things do happen from time to time.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla CT Policy

[Ryan Sleevi]

On Tue, Nov 8, 2016 at 12:53 AM, Kurt Roeckx  wrote:
> On 2016-11-07 18:25, Ryan Sleevi wrote:
>>
>> This is why it's vitally important that clients fetch inclusion proofs in
>> some manner
>
>
> Have you considered a TLS extension, have the server fetch them and send to
> the client?

Yes, but the client still has to fetch proofs (this would be from
STH-server to STH-client or from STH-server-A to STH-server-B) and
much of the data would be duplicative (because it's a merkle tree). It
would also have to be continually updated by the servers.

And of course, the simplest reason of all, which is that if it relies
on server change, it won't happen.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla CT Policy

[Ryan Sleevi]

On Tue, Nov 8, 2016 at 2:05 AM, Gervase Markham  wrote:
> On 07/11/16 17:25, Ryan Sleevi wrote:
>> Yes. An 'evil log' can provide a divided split-view, targeting only
>> an affected number of users. Unless that SCT was observed, and
>> reported (via Gossip or some other means of exfiltration), that split
>> view would not be detected.
>
> So it is therefore important not just that the client which receives the
> SCT checks it against an STH it can observe, but that it is reported
> elsewhere for others to check? Or that a client has a method of fetching
> inclusion proofs that were "observed" from elsewhere?

No, this isn't quite a correct understanding :)

If your goal is to detect a split view, exchanging STHs, not SCTs, is
sufficient. However, if you want to determine what was misissued, you
need the SCTs to show that - the STHs will just show you that there's
some unknown.

However, exchanging STHs by itself doesn't provide any security
guarantees - if you're not checking SCTs to STHs, then a log operator
never has reason to lie about the STH, and can simply omit
certificates without splitting STHs. However, if a client checks SCTs
to STHs, they can't be sure they're not getting a split view, without
also checking others' STHs.

In Chrome's case, it receives a list daily from Google of the STHs
that Google has observed, and then compares its SCTs against those
STHs from the log. As such, the log cannot hide a split view - even if
it lies about the STH to the client, it will still have to prove the
STH it gave to the client against the STH Google saw. However, here
still, the importance is that the client needs to send some signal
indicating it's receiving a split view. This is where Gossip comes in.

> Presumably this is one reason some people are suggesting Mozilla's
> policy have a jurisdictional diversity requirement - to make such
> coercion harder.

Possibly, but I encourage you to review the past CA/Browser Forum
discussions about CT, and the ct-policy list, to understand why Google
intentionally removed it's "diversity" requirement as being ambiguous
and unenforcable, and contributing more harm than good.

For any system of diversity to be relevant, you must be able to
quantify it, and you must be able to quantify it over time. As the
situation with StartCom/WoSign/Qihoo showed, both Mozilla and the
broader ecosystem are not well suited to continuously monitor the
complex legal system of ownership, let alone nexus' of business
operations. And if you can't be certain, and can't measure it, then
are you actually providing value?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla CT Policy

[Gervase Markham]

On 07/11/16 17:25, Ryan Sleevi wrote:
> Yes. An 'evil log' can provide a divided split-view, targeting only
> an affected number of users. Unless that SCT was observed, and
> reported (via Gossip or some other means of exfiltration), that split
> view would not be detected.

So it is therefore important not just that the client which receives the
SCT checks it against an STH it can observe, but that it is reported
elsewhere for others to check? Or that a client has a method of fetching
inclusion proofs that were "observed" from elsewhere?

> So if I were wanting to run an evil log, which could hide misissued
> certificates, I could sufficiently compel or coerce a quorum of
> acceptable logs 

With "quorum" effectively being the smallest number of permitted SCTs,
i.e. two.

Presumably this is one reason some people are suggesting Mozilla's
policy have a jurisdictional diversity requirement - to make such
coercion harder.

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla CT Policy

[Kurt Roeckx]

On 2016-11-07 18:25, Ryan Sleevi wrote:

This is why it's vitally important that clients fetch inclusion proofs in some 
manner


Have you considered a TLS extension, have the server fetch them and send 
to the client?



Kurt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla CT Policy

[Ryan Sleevi]

On Monday, November 7, 2016 at 9:02:37 AM UTC-8, Gervase Markham wrote:
> As in, their dishonesty would be carefully targetted and so not exposed
> by this sort of coarse checking?

(Continuing with Google/Chrome hat on, since I didn't make the previous reply 
explicit)

Yes. An 'evil log' can provide a divided split-view, targeting only an affected 
number of users. Unless that SCT was observed, and reported (via Gossip or some 
other means of exfiltration), that split view would not be detected.

Recall: In order to ensure a log is honest, you need to ensure it's providing 
consistent views of the STH *and* that SCTs are being checked. In the absence 
of the latter, you don't need to do the former - and that's infrastructure for 
monitoring primarily focuses on the STH consistency, with the 
assumption/expectation that clients are doing the SCT inclusion proof fetching.

So if I were wanting to run an evil log, which could hide misissued 
certificates, I could sufficiently compel or coerce a quorum of acceptable logs 
to 'misissue' an SCT for which they never incorporated into their STH. So long 
as clients don't ask for an inclusion proof of this SCT, there's no need for a 
split log - and no ability for infrastructure to detect. You could use such a 
certificate in targeted, user-specific attacks.

This is why it's vitally important that clients fetch inclusion proofs in some 
manner (either through gossip or through 'privacy' intermediaries, which is 
effectively what the Google DNS proposal is - using your ISP's DNS hierarchy as 
the privacy preserving aspect), and then check that the STH is consistent 
(which, in the case of Chrome, Chrome clients checking Google's DNS servers is 
effectively an STH consistency proof with what Google sees).

In the absence of this implementation, checking the SCT provides limited 
guarantee that a certificate has actually been logged - in effect, you're 
making a full statement that you trust the log to be honest. Google's goal for 
Certificate Transparency has been to not trust logs to be honest, but to verify 
- but as Chrome builds out it's implementation, it has to 'trust someone' - and 
given our broader analysis of the threat model and scenario, the decision to 
"trust Google" (by requiring at least one SCT from a Google-operated log) is 
seen as no worse than existing "trust Google" requests existing Chrome users 
are asked of (for example, trusting Chrome's autoupdate will not be 
compromised, trusting Google not to deliver targeted malicious code). [1]

Thus, in the absence of SCT inclusion proof checking (whether temporarily, as 
implementations blossom, or permanently, if you feel there can be no suitable 
privacy-preserving solution), you're trusting the logs not to misbehave, much 
like you trust CAs not to misbehave. You can explore technical solutions - such 
as inclusion proof checking - or you can explore policy solutions - such as 
requiring a Mozilla log, or requiring logs have some criteria to abide by ala 
WebTrust for CAs, or who knows what - but it's at least useful to understand 
the context for why that decision exists, and what the trust tradeoffs are with 
such a decision.


[1] As an aside, this "trust Google for binaries" bit is being explored in 
concepts like Binary Transparency, a very nascant and early stage exploration 
in how to provide reliable assurances that binaries aren't targeted. Similarly, 
the work of folks on verifiable builds, such as shown by Tor Browser Bundle, 
are meant to address the case of no 'obvious' backdoors, but the situation is 
more complex when non-open code is involved. I call this out to highlight that 
the computer industry has still not solved this, and even if we did for 
software, we have compilers hardware to contend with, and then we're very much 
into "Reflections on Trusting Trust" territory.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla CT Policy

[Gervase Markham]

On 07/11/16 16:13, Ryan Sleevi wrote:
> Yes, particularly for logs that may be compelled to be dishonest for 
> geopolitical reasons.

As in, their dishonesty would be carefully targetted and so not exposed
by this sort of coarse checking?

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla CT Policy

[Ryan Sleevi]

On Monday, November 7, 2016 at 1:59:31 AM UTC-8, Gervase Markham wrote:
> It is correct that there is not yet a plan for when Firefox might
> implement inclusion proof fetching.
> 
> One thing I have been pondering is checking the honesty of logs via
> geographically distributed checks done by infra rather than clients. Did
> Google consider that too easy to game?

Yes, particularly for logs that may be compelled to be dishonest for 
geopolitical reasons.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla CT Policy

[Gervase Markham]

On 05/11/16 19:33, Ryan Sleevi wrote:
> My understanding was that Mozilla's implementation status was similar
> to Chrome's a year ago - that is, that it doesn't implement inclusion
> proof fetching (in the background) and that work hadn't been
> scheduled/slated yet. In that case, it's a question for Mozilla about
> whether to trust that logs won't lie, or whether to verify.

It is correct that there is not yet a plan for when Firefox might
implement inclusion proof fetching.

One thing I have been pondering is checking the honesty of logs via
geographically distributed checks done by infra rather than clients. Did
Google consider that too easy to game?

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla CT Policy

[Ryan Sleevi]

On Friday, November 4, 2016 at 5:32:23 AM UTC-7, Hanno Böck wrote:
> Hi,
> 
> Great to see Mozilla committing to CT.
> 
> On Fri, 4 Nov 2016 12:19:32 +
> Gervase Markham  wrote:
> 
> > So, please add comments with additional _questions_ you think the
> > policy will need to address. What the answers should be is (for now)
> > off-topic.
> 
> Some meta-thought:
> In practice pretty much every webpage wants to be compliant with all
> major browsers. It's hard to imagine anyone saying "I'll comply with
> Chrome's CT requirements, but not with Mozilla's" (or vice versa).
> 
> Therefore practically the "real" CT requirements will be all
> requirements combined. It also probably means that diverity in CT
> requirements between different browsers doesn't make a whole lot of
> sense.
> 
> So one could ask: Should mozilla just say "we agree with everything
> Chrome does" ?

This is a very useful point to consider. As has been repeatedly stated in 
Chrome's discussion of CT, the requirement for one Google/one non-Google is due 
to the absence of SCT->STH verification, and the absence of Gossip, in current 
versions of Chrome (it's being worked on). In the absence of this, if you trust 
an SCT from a log, you're effectively trusting that log to be honest - there's 
no validation occurring that the log isn't providing a split view (perhaps to 
users inside a particular network block/country and those outside)

My understanding was that Mozilla's implementation status was similar to 
Chrome's a year ago - that is, that it doesn't implement inclusion proof 
fetching (in the background) and that work hadn't been scheduled/slated yet. In 
that case, it's a question for Mozilla about whether to trust that logs won't 
lie, or whether to verify.

In Google's case, the one-Google/one-non-Google was merely an interim stopgap 
towards that solution - because it resolves the "I don't trust other logs" 
aspect by trusting Google logs (which, at least for Chrome's threat model, is 
no different than trusting Google not to deliver hostile updates to Chrome 
users), while giving others the relief that they don't have to solely/entirely 
trust Google (by having a third-party expression).

So I think the question about 'CT Qualification' (to steal Chrome's term) is at 
least useful to consider that point, about threat models - which, admittedly, I 
haven't been very good at articulating on Chrome's ct-policy@ all the ways in 
which we expect/planned for things to go wrong, and attempted to design against 
that, as well as all the things we knew we didn't know solutions for, in which 
case, we tried to leave things open.

I'll hopefully have more news in the following weeks, on Chrome's ct-policy 
list, but I think we're interested in hosting another "CT days" event, this 
time in the US, similar to the events we held in conjunction with the ETSI CA 
days in Europe. This would hopefully provide for an opportunity of a real time 
roundtable and discussion of these sorts of issues, across browsers, log 
operators, and relying parties, to better explore how we can develop both an 
immediate and long-term healthy ecosystem. Think of it as the "CT/Log 
Roundtable", and we'll try to figure out solutions for remote participation as 
well.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla CT Policy

[Ryan Sleevi]

On Saturday, November 5, 2016 at 10:59:04 AM UTC-7, Tom Ritter wrote:
> > * Are there any CT-related services Mozilla should consider running or
> > supporting, for the good of the ecosystem?
> 
> Part answer, part question, but I don't want to forget it: Besides an
> Auditor, perhaps Mozilla should run a DNS log query front-end to
> provide diversity from Google's.
> 
> -tom

For specificity sake: Tom's talking about having Mozilla operate a set of DNS 
endpoints that implement 
https://github.com/google/certificate-transparency/blob/master/docs/DnsServer.md

To implement that, it effectively requires running a set of CT mirrors, so that 
you can provide the merkle tree inclusion proofs for arbitrary SCTs and STHs.

If not that, then it's worth Mozilla noodling how it wants to check SCTs' 
inclusion in a privacy preserving fashion. It may very well be that Mozilla 
feels that DNS doesn't afford that privacy. However, it would be super useful 
to know that and for implementors - Mozilla, Apple, others - to help 
collaboratively figure out solutions rather than inventing new ones ad-hoc :)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla CT Policy

[Tom Ritter]

On 4 November 2016 at 07:19, Gervase Markham  wrote:
> * Are there any CT-related services Mozilla should consider running or
> supporting, for the good of the ecosystem?

Part answer, part question, but I don't want to forget it: Besides an
Auditor, perhaps Mozilla should run a DNS log query front-end to
provide diversity from Google's.

-tom
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla CT Policy

[Florian M.]

Hey list,

Here are some suggestions:

Should we define log algorithm/key requirements (hashing algorithms (relevant 
with RFC6962-bis), asymmetric key type and length)?

Should we define a maximum threshold on log response delay to queries? (e.g. is 
it acceptable for a log to answer to queries with a delay of tens of seconds or 
even minutes?)

Should we authorize log trust anchor list variations? If so, should variations 
have to be publicly disclosed? Should we authorize removal of trust anchors?

Should a log be authorized to reject add-chain calls when under stress? Should 
we limit how often this happens?

Should we want to restrict the protocol version and cipher suites that are 
supported by the log HTTPs endpoints?

Cheers,
Florian
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Mozilla CT Policy

[Jeremy Rowley]

This is awesome. We're very excited to see Mozilla support CT.

How about: 
1) What version of logs should Mozilla accept (do they have to comply with
the bis)? If they are compliant with the original spec, should they be
accepted until a certain date when they must transition to the new bis? 

2) How long should logs operate before being trusted? Is there a period of
time for testing to ensure operational robustness?

3) How will Mozilla support the three options for providing proofs? OCSP
stapling v. embedment v. TLS extensions. 

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Gervase Markham
Sent: Friday, November 4, 2016 6:20 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Mozilla CT Policy

CT is coming to Firefox. As part of that, Mozilla needs to have a set of CT
policies surrounding how that will work. Like our root inclusion program, we
intend to run our CT log inclusion program in an open and transparent
fashion, such that the Internet community can see how it works and how
decisions are made. (It is quite possible that, like our root program, other
entities without the resources to run their own programs might adopt our
decisions.)

This policy will need to consider at least the following questions. The
point of this posting is to gather more _questions_, not to work out the
answers. In other words, I am trying to work out the scope of the policy,
not what the policy will be.

So, please add comments with additional _questions_ you think the policy
will need to address. What the answers should be is (for now) off-topic.

Questions I have so far:

* How do we decide which logs to trust?

  * Do we have requirements for uptime?
  * Do we have requirements for certs accepted?
  * Do we have requirements for the MMD?

* How do we decide when to un-trust a log? What reasons are valid reasons
for doing so?

* Do we want to put monitoring in place to ensure our log quality or uptime
requirements are met?

* Are there any CT-related services Mozilla should consider running or
supporting, for the good of the ecosystem?

* Do we want to require a certain number of SCTs for certificates of
particular validity periods?

* Do we want the Google/non-Google diversity requirement? Or any other
diversity reqirement?

* Which certs, if any, should we require CT for, and when?

* Do we want to allow some CAs to opt into CT before those dates?

* Do we want to require some CAs to do CT before those dates?

Gerv

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla CT Policy

[Han Yuwei]

在 2016年11月4日星期五 UTC+8下午8:20:11，Gervase Markham写道：
> CT is coming to Firefox. As part of that, Mozilla needs to have a set of
> CT policies surrounding how that will work. Like our root inclusion
> program, we intend to run our CT log inclusion program in an open and
> transparent fashion, such that the Internet community can see how it
> works and how decisions are made. (It is quite possible that, like our
> root program, other entities without the resources to run their own
> programs might adopt our decisions.)
> 
> This policy will need to consider at least the following questions. The
> point of this posting is to gather more _questions_, not to work out the
> answers. In other words, I am trying to work out the scope of the
> policy, not what the policy will be.
> 
> So, please add comments with additional _questions_ you think the policy
> will need to address. What the answers should be is (for now) off-topic.
> 
> Questions I have so far:
> 
> * How do we decide which logs to trust?
> 
>   * Do we have requirements for uptime?
>   * Do we have requirements for certs accepted?
>   * Do we have requirements for the MMD?
> 
> * How do we decide when to un-trust a log? What reasons are valid
> reasons for doing so?
> 
> * Do we want to put monitoring in place to ensure our log quality or
> uptime requirements are met?
> 
> * Are there any CT-related services Mozilla should consider running or
> supporting, for the good of the ecosystem?
> 
> * Do we want to require a certain number of SCTs for certificates of
> particular validity periods?
> 
> * Do we want the Google/non-Google diversity requirement? Or any other
> diversity reqirement?
> 
> * Which certs, if any, should we require CT for, and when?
> 
> * Do we want to allow some CAs to opt into CT before those dates?
> 
> * Do we want to require some CAs to do CT before those dates?
> 
> Gerv

1. What will happen if CT validation failed? Can we add a security excpetion 
about this?

2. Is SLA required for Mozilla chosen CT operator?

3. If CT is required, can we request a CT embedded certificate from CAs because 
some webserver don't support TLS extension.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla CT Policy

[Jakob Bohm]

On 04/11/2016 15:42, Hanno Böck wrote:

On Fri, 4 Nov 2016 14:09:55 +0100
Jakob Bohm  wrote:


* How do we allow organization internal non-public CAs to not reveal
  their secret membership/server lists to public CT systems or
otherwise run the (administratively and technically) expensive
processes required of public CAs.  For example many medium or large
companies have in-house CAs issuing certificates for communicating
with their internal servers, VPNs, extranets etc.  Such internal CAs
may very from primitive off-line CAs (no online active components
such as OCSP responders or CT loggers) to off-the-shelf enterprise CA
packages such as Microsoft Windows Server Certificate Services, xca
or EJBCA.

* How do we prevent public CAs from misusing the exceptions for
private CAs?


Isn't that already solved?

Browsers already treat manually installed roots differently, e.g.
bypassing key pinning. Chrome's CT requirements don't apply to locally
installed roots.

This seems to be the obvious solution. CT is there to have transparency
of certificates by the browser-accepted CAs. If you have your own CA
that souldn't be touched by that at all.



Sometimes the people designing implementations forget about this use
case and do things that are bad in that context.  For example it is
routine (actually required) for public CAs to have working OCSP servers
and report revoked certificates to services such as Mozilla OneCRL.
But it is very difficult for a small scale in-house offline CA to do
either, while trivial to publish a short regular CRL on an existing
internal HTTP server next to the document listing this weeks lunch menu
and the employee handbook.


(By the way I always found the "secret server name" idea wrong and I
would generally recommend against local CAs in almost all cases. It
adds a lot of complexity and I assume it often creates more problems
than it solves.)



Think of it this way:

90%+ of all the worlds computers are not public servers, they are
workstations, file servers, printers, firewalls, databases, phones etc.
etc.  Many of those may have certificate protected interfaces such as
management web pages, encrypted mail/news services, certificate based
IPsec etc. etc.

Many general computer management and/or server suites contain the logic
to fully or almost fully automate the handling of certificate issuance
and use for those servers.  Microsoft Windows Server is one such
"suite" that has the whole thing built in and can use it to secure
internal network traffic.

The very name/existence of a server may reveal confidential information
(besides being a target of outside network attacks).  Imagine if
someone had spotted the name "development.webbrowser.google.com" in a
CT log before Chrome was publicly announced.

While keeping the existence of something secret is no substitute for
actually protecting it, it is often a reasonable first layer of
defense, leaving much less work for the actual defensive measures to
handle.  It can mean the difference between getting hit by 200 script
kiddies / day and 10 script kiddies / day, making it easier to spot
serious attacks, and requiring less CPU and bandwidth resources to
deflect and log that background noise.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla CT Policy

[okaphone . elektronika]

Well, these are logs. So:

- Is it necessary to require that log items can't be modified after they have 
been created? (Or is that implied by the cryptography being used.) How about 
deleted?

- Is is perhaps a good idea to require a certain minimum accuracy (or other 
characteristics, timestamps only increase) for it's clock?

- Maybe you should consider what will happen if/when an important log stops to 
be available at some point in the future. Will anything break?

- And I already mentioned it, but availability of 99% is not as good as it 
sounds. It means three and a half days down in a year is allowed.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla CT Policy

[Kurt Roeckx]

On Fri, Nov 04, 2016 at 12:19:32PM +, Gervase Markham wrote:
> 
> * Do we want to require a certain number of SCTs for certificates of
> particular validity periods?

What happens to the SCT requirements if a log is distrusted? Is the
date of the distrust taking into account? Is that the same for all
distrust cases?


Kurt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla CT Policy

[Tom Ritter]

On 4 November 2016 at 07:19, Gervase Markham  wrote:
> * How do we decide when to un-trust a log? What reasons are valid
> reasons for doing so?

Do we want different types of distrust for a log? That is, a "We don't
trust you at all anymore" distrust vs a "We don't trust signatures
issued after this date" distrust.


> * Do we want to require a certain number of SCTs for certificates of
> particular validity periods?

Do we want to trest different types of SCTs differently for this
purpose? (precert vs OCSP vs TLS Extension.)

> * Do we want to allow some CAs to opt into CT before those dates?

Do we want to allow some websites to opt into CT before those dates?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla CT Policy

[Martin Rublik]

On Fri, Nov 4, 2016 at 3:42 PM, Hanno Böck  wrote:

>
> Isn't that already solved?
>
> Browsers already treat manually installed roots differently, e.g.
> bypassing key pinning. Chrome's CT requirements don't apply to locally
> installed roots.
>
> How about public technically constrained sub CAs?

(By the way I always found the "secret server name" idea wrong and I
> would generally recommend against local CAs in almost all cases. It
> adds a lot of complexity and I assume it often creates more problems
> than it solves.)
>
> Agree

Martin
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla CT Policy

[Hanno Böck]

On Fri, 4 Nov 2016 14:09:55 +0100
Jakob Bohm  wrote:

> * How do we allow organization internal non-public CAs to not reveal
>   their secret membership/server lists to public CT systems or
> otherwise run the (administratively and technically) expensive
> processes required of public CAs.  For example many medium or large
> companies have in-house CAs issuing certificates for communicating
> with their internal servers, VPNs, extranets etc.  Such internal CAs
> may very from primitive off-line CAs (no online active components
> such as OCSP responders or CT loggers) to off-the-shelf enterprise CA
> packages such as Microsoft Windows Server Certificate Services, xca
> or EJBCA.
> 
> * How do we prevent public CAs from misusing the exceptions for
> private CAs?

Isn't that already solved?

Browsers already treat manually installed roots differently, e.g.
bypassing key pinning. Chrome's CT requirements don't apply to locally
installed roots.

This seems to be the obvious solution. CT is there to have transparency
of certificates by the browser-accepted CAs. If you have your own CA
that souldn't be touched by that at all.

(By the way I always found the "secret server name" idea wrong and I
would generally recommend against local CAs in almost all cases. It
adds a lot of complexity and I assume it often creates more problems
than it solves.)

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla CT Policy

[Hanno Böck]

Hi,

Great to see Mozilla committing to CT.

On Fri, 4 Nov 2016 12:19:32 +
Gervase Markham  wrote:

> So, please add comments with additional _questions_ you think the
> policy will need to address. What the answers should be is (for now)
> off-topic.

Some meta-thought:
In practice pretty much every webpage wants to be compliant with all
major browsers. It's hard to imagine anyone saying "I'll comply with
Chrome's CT requirements, but not with Mozilla's" (or vice versa).

Therefore practically the "real" CT requirements will be all
requirements combined. It also probably means that diverity in CT
requirements between different browsers doesn't make a whole lot of
sense.

So one could ask: Should mozilla just say "we agree with everything
Chrome does" ?

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Mozilla CT Policy

[Gervase Markham]

CT is coming to Firefox. As part of that, Mozilla needs to have a set of
CT policies surrounding how that will work. Like our root inclusion
program, we intend to run our CT log inclusion program in an open and
transparent fashion, such that the Internet community can see how it
works and how decisions are made. (It is quite possible that, like our
root program, other entities without the resources to run their own
programs might adopt our decisions.)

This policy will need to consider at least the following questions. The
point of this posting is to gather more _questions_, not to work out the
answers. In other words, I am trying to work out the scope of the
policy, not what the policy will be.

So, please add comments with additional _questions_ you think the policy
will need to address. What the answers should be is (for now) off-topic.

Questions I have so far:

* How do we decide which logs to trust?

  * Do we have requirements for uptime?
  * Do we have requirements for certs accepted?
  * Do we have requirements for the MMD?

* How do we decide when to un-trust a log? What reasons are valid
reasons for doing so?

* Do we want to put monitoring in place to ensure our log quality or
uptime requirements are met?

* Are there any CT-related services Mozilla should consider running or
supporting, for the good of the ecosystem?

* Do we want to require a certain number of SCTs for certificates of
particular validity periods?

* Do we want the Google/non-Google diversity requirement? Or any other
diversity reqirement?

* Which certs, if any, should we require CT for, and when?

* Do we want to allow some CAs to opt into CT before those dates?

* Do we want to require some CAs to do CT before those dates?

Gerv

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy