On 06/06/2017 22:08, Ryan Sleevi wrote:
> On Tue, Jun 6, 2017 at 2:28 PM, Jakob Bohm via dev-security-policy <
>
dev-secur...@lists.mozilla.org> wrote:
>>
>> I am saying that setting an administrative policy for inclusion in a
>> root program is not the place to do technical reviews of security
>> protocols.
>
>
> Of course it is. It is the only one that has reliably worked in the history
> of the Web PKI. I would think that would be abundantly evident over the
> past five years.
>
I have yet to see (but I haved studied ancient archives) the root
program and or the CAB/F doing actual review of technical security
protocols and data formats.
>
>> And I proceeded to list places that *do* perform such peer
>> review at the highest level of competency, but had to note that the list
>> would be too long to enumerate in a stable root program policy.
>>
>
> Except none of them are, as evidenced by what they've turned out. The only
> place where Mozilla users are considered, en masse, is in Mozilla policy.
> It is the one and only place Mozilla can ensure its needs are appropriately
> and adequately reflected.
>
>
>> SDO? Unfamiliar with that TLA.
>>
>
> Standards defining organization.
>
Ah, like the very examples I gave of competent protocol review
organizations that should do this.
>
>> And why should Mozilla (and every other root program) be consulted to
>> unanimously preapprove such technical work? This will create a massive
>> roadblock for progress. I really see no reason to create another FIPS
>> 140 style bureaucracy of meaningless rule enforcement (not to be
>> confused with the actual security tests that are also part of FIPS 140
>> validation).
>>
>
> This is perhaps the disconnect. It's not meaningless. A significant amount
> of the progress made in the past five years in the Web PKI has come from
> one of two things:
> 1) Mozilla or Google forbidding something
> 2) Mozilla or Google requiring something
>
Yes, but there is a fundamental difference between Mozilla/Google
enforcing best practices and Mozilla/Google arbitrarily banning
progress.
> The core of your argument seems to be that you don't believe Mozilla can
> update it's policy in a timely fashion (which this list provides ample
> counter-evidence to this), or that the Mozilla community should not be
> consulted about what is appropriate for the Mozilla community (which is, on
> its face, incorrect).
>
No, I am saying the the root program is the wrong place to do technical
review and acceptance/rejection of additional CA features that might
improve security with non-Mozilla code, with the potential that at some
future point in time Mozilla might decide to start including such
facilities.
For example, the Mozilla root program was not the right place to discuss
if CAs should be allowed to do CT logging at a time when only Google
code was actually using that.
The right place was Google submitting the CT system to a standard
organization (in this case the IETF), and once any glaring security
holes had been reviewed out, begin to have some CAs actually do this,
before the draft RFC could have the implementations justifying
publication as a standards track RFC. Which is, I believe, exactly what
happened. The Mozilla root policy did not need to change to allow this
work to be done.
One litmus-test for a good policy would be "If this policy had existed
before CT, and Mozilla was not involved with CT at all, would this
policy had interfered with the introduction of CT by Google".
> Look, you could easily come up with a dozen examples of improved validation
>>> methods - but just because they exist doesn't mean keeping the "any other
>>> method" is good. And, for what it's worth, of those that did shake out of
>>> the discussions, many of them _were_ insecure at first, and evolved
>>> through
>>> community discussion.
>>>
>>>
>> Interestingly, the list of revocation checking methods supported by
>> Chrome (and proposed to be supported by future Firefox versions) is
>> essentially _empty_ now. Which is completely insecure.
>>
>
> Not really "interestingly", because it's not a response to the substance of
> the point, but in fact goes to an unrelated (and technically incorrect)
> tangent.
>
> Rather than engage with you on that derailment, do you agree with the
> easily-supported (by virtue of the CABF Validation WG's archives) that CAs
> proposed the use of insecure methods for domain validation, and those were
> refined in time to be more appropriately secure? That's something easily
> supported.
>
I am not at all talking about "domain validation" and the restrictions
that had to be imposed to stop bad CA practices.
I am talking about allowing non-Mozilla folk, working with competent
standard defining organizations to create additional security
measures requiring signatures from involved CAs.
>
>> Within *this thread* proposed policy language would have banned that.
>
>
>> And neither I, nor any other participant seemed to realize this specific
>> omission until my post this morning.
>>
>
> Yes, and? You're showing exactly the value of community review - and where
> it would be better to make a mistake that prevents something benign, rather
> than allows something dangerous, given the pattern and practice we've seen
> over the past decades.
>
That is a retorical trick. While the fact that I found one concrete
omission does add to the policy review process. It also remains a valid
example of how easily something like that could (and was) missed.
>
>> However the failure mode for "signing additional CA operational items"
>>>> would be a lot less risky and a lot less reliant on CA competency.
>>>>
>>>
>>>
>>> That is demonstrably not true. Just look at the CAs who have had issues
>>> with their signing ceremonies. Or the signatures they've produced.
>>>
>>
>> Did any of those involve erroneously signing non-certificates of a
>> wholly inappropriate data type?
>>
>
> I'm not sure I fully understand or appreciate the point you're trying to
> make, but I feel like you may have misunderstood mine.
>
> We know that CAs have had issues with their signing ceremonies (e.g.
> signing tbsCertificates that they should not have)
Which is not applicable.
> We know that CAs have had issues with integrating new technologies (e.g.
> CAA misissuance)
Which is not proof that all new technologies should therefore be
preemptively banned or require preapproval by organizations with
no interest in using those technologies.
> We know that CAs have had considerable issues adhering to the relevant
> standards (e.g. certlint, x509lint, Mozilla Problematic Practices)
Which is not a reason to retard the creation of new standards.
>
> Signing data is heavily reliant on CA competency, and that's in
> unfortunately short supply, as the economics of the CA market make it easy
> to fire all the engineers, while keeping the sales team, and outsourcing
> the rest.
>
Which is why I am heavily focused on allowing new technology to be be
developed by competent non-CA staff (such as IETF), then field tested in
cooperation with a few CAs with sufficient engineers, before deciding if
it is good enough, and well enough documented, to be deployed by all the
other CAs.
>
>> I am not an AV vendor.
>>
>> Technical security systems work best with whitelists wherever possible.
>>
>> Human-to-human policy making works best with blacklists wherever
>> possible.
>>
>> Root inclusion policies are human-to-human policies.
>>
>
> Root inclusion policies are the embodiment of technical security systems.
> While there is a human aspect in determining the trustworthiness for
> inclusion, it is the technical competency that is the core to that trust.
> The two are deeply related, and the human aspect of the CA trust business
> is deeply flawed - as the past decade of issuance shows you.
They are a human-to-human policy on what and how technical systems may
be deployed. They are not the actual technical embodiments of those
requirements.
>
> The mitigation for this was, is, and will be technical mitigation for human
> failures. You want to remove humans from the loop, not depend on them.
>
"2. A robot must obey the orders given it by human beings except where
such orders would conflict with the First Law." (Asimov)
>
>> Just trying to preserve existing ontologies. Prior to this thread,
>> failures in OCSP and CRL operations were never classified as
>> "mis-issuance", because it shares nothing relevant with "mis-issuance".
>>
>> For example you cannot "revoke a mis-issued OCSP response" within 24 hours
>> by adding it to CRLs etc. It's nonsense.
>>
>
> Of course they were! They were and are part of the Baseline Requirements as
> policy violations (e.g. 'unrevoking' a certificate, a CRL with a
> certificateSuspension, etc).
"Unrevoking a certificate" is a previously common practice banned by a
BR, completely separately from the rules about issuance and
mis-issuance.
>
> The ontology you seek to preserve wasn't actually an enshrined policy. If
> your debate is that the word 'issue' can only apply to certificates, and
> that OCSP responses are 'signed', as are CRLs, then all you've stated is
> that there is 'misissuance' and 'missigning', which are technically
> identical activities, but utilize different verbs.
>
> A CA that unrevokes an intermediate has violated the Mozilla Root
> Certificate Policy. That's always been the case.
>
Yes, but that's not the only thing that can go wrong in CRL and OCSP
signing. A key example from the past year was when the revocation of
one of Globalsign's cross-certs caused their OCSP software to
erroneously report millions of valid certificates as revoked. Stopping
this damage was not a BR-violating unrevocation of those millions of
certificates, and was accepted as a purely technical incident that did
not jeopardize security. None of the "mis-issuance" policy requirements
were invoked.
Similarly, the fact that until recently it was not prohibited for OCSP
responders to reply "valid" for unknown certs did not imply that each
such incident was a "mis-issuance", and none of the "mis-issuance"
policy requirements were invoked. Nor should they be invoked if it is
found that some CAs fail to implement the new policy of not doing that.
Signing bad CRLs and/or bad OCSP responses may be purely technical
incidents, or may be security incidents. And there are policy rules for
that which differ significantly from the rules for mis-issuing an actual
certificate and/or an actual precertificate.