On 07/06/2017 17:41, Ryan Sleevi wrote:
On Wed, Jun 7, 2017 at 11:25 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

Note that I also had a second, related, point: The possibility that such
a new piece of infrastructure was, for other reasons, not endorsed by
Mozilla, but of great interest to one of the other root programs (not
all of which are browser vendors).

Conversely consider the possibility that some other root programs had a
similarly restrictive policy and refused to support the introduction of
CT PreCertificates.  This could have stopped a useful improvement that
Mozilla seems to like.

The Golden rule would then imply that Mozilla should not reserve to
itself a power it would not want other root programs to have.


So much rhetoric, so little substance...


As much as I love an application of the Golden Rule as the next person, I
think it again misunderstands the realities on the ground in the Web PKI,
and puts an ideal ahead of the practical security implications.
 > Root programs do sometimes disagree. For example, Microsoft reserves the
right to revoke certificates it disagrees with. That right means that other
browser programs cannot effectively use CRLs or OCSP for revocation, as to
do so is to recognize Microsoft's ability to (negatively) affect their
users. They have means of working out those disagreements.

Bad example, but illustrates that reasonable agreement is not always
obtainable.


You're positioning the hypothetical as if it's inflexible - but the reality
is, each root program exists to first and foremost best reflect the needs
of its userbase. For Microsoft, they've determined that's best accomplished
by giving themselves unilateral veto power over the CAs they trust. For
Mozilla, recognizing its global mission, it tries to operate openly and
best serving the ecosystem.


I'm saying that if someone not interested in some good protocol had veto
power over CAs using that protocol, then that someone could be
inflexible to the detriment of everyone else.  Hence the desire not to
establish a precedent for such veto power.

The goodness of Mozilla does not minimize that precedent, only increases
the danger it might be cited by less honorable root programs.

The scenario you remark as undesirable - the blocking of precertificates -
is, in fact, a desirable and appropriate outcome. As Nick has noted, these
efforts do not spring forth like Athena, fully grown and robust, but
iteratively develop through the community process - leaving ample time for
Mozilla to update and respond. This, too, has ample evidence of it
happening - see the discussions related to CAA, or the validation methods
employed by ACME.

So what would/should the CT project have done if some inflexible root program had vetoed its deployment?

And ample time to respond does not guarantee a fair response, especially
when considering the extension of such veto power to less flexible root
programs.


The idealized view of SDOs - that they are infallible organizations or
represent some neutral arbitration - is perhaps misguided. For example,
it's trivial to publish an I-D within the IETF as a draft, and it's not
unreasonable to have an absolutely terrible technology assigned an RFC (for
example, an informational submission documenting an existing, but insecure,
technology). As Nick mentions, the reality - and far more common occurrence
- is someone being clever and a half and doing it with good intentions, but
bad security. And those decisions - and that flexibility - create
significantly more risk for the overall ecosystem.

When talking about the IETF as an SDO, I am obviously talking about IETF
standards track working groups, not individual submission RFCs or BOF
talks at IETF meetings.


I suspect we will continue to disagree on this point, so I doubtful can
offer more meaningful arguments to sway you, and certainly would not appeal
to authority. I would simply note that the scenarios you raise as
hypotheticals do not and have not played out as you suggest, and if the
overall goal of this discussion is to ensure the security of Mozilla users,
then the contents, provenance, and correctness of what is signed plays an
inescapable part of that security, and the suggested flexibility is
inimical to that security.



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

Reply via email to