[cryptography] this house believes that user's control over the root list is a placebo

Ralph Holz holz at net.in.tum.de
Sun Jun 26 05:50:27 EDT 2011


> Any model that offers a security feature to a trivially tiny minority,
> to the expense of the dominant majority, is daft.  The logical
> conclusion of 1.5 decades worth of experience with centralised root
> lists is that we, in the aggregate, may as well trust Microsoft and the
> other root vendors' root list entirely.
> Or: find another model.  Change the assumptions.  Re-do the security
> engineering.

You have avoided the wording "find a better model" - intentionally so?
Because such work would only be meaningful if we could show we have
achieved an improvement by doing it.

Which brings us to the next point: how do we measure improvement? What
we would need - and don't have, and likely won't have for another long
while - are numbers that are statistically meaningful.

On moz.dev.sec.policy, the proposal is out that CAs need to publicly
disclose security incidents and breaches. This could actually be a good
step forward. If the numbers show that incidents are far more frequent
than generally assumed, this would get us away from the "low frequency,
high impact" scenario that we all currently seem to assume, and which is
so hard to analyse. If the numbers show that incidents are very rare -
fine, too. Then the current model is maybe not too bad (apart from the
fact that one foul apple will still spoil everything, and government
interference will still likely remain undetected).

The problem is that CAs object to disclosure on the simple grounds that
public disclosure hurts them. Even Startcom, otherwise aiming to present
a clean vest, has not disclosed yet what happened on June, 15th this year.

Mozilla seems to take the stance that incidents should, at most, be
disclosed to Mozilla, not the general public. While understandable from
Moz's point of view - you don't want to hurt the CAs too badly if you
are a vendor - it still means researchers won't get the numbers they
need. And the circle closes - no numbers, no facts, no improvements,
other than those subjectively perceived.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 554 bytes
Desc: OpenPGP digital signature
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20110626/ab9f5efb/attachment.asc>

More information about the cryptography mailing list