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

Marsh Ray marsh at extendedsubset.com
Sun Jun 26 13:26:40 EDT 2011

On 06/25/2011 03:48 PM, Ian G wrote:
> On 21/06/11 4:15 PM, Marsh Ray wrote:
>> This was about the CNNIC situation,
> Ah, the "I'm not in control of my own root list" threat scenario.
> See, the thing there is that CNNIC has a dirty reputation.

That's part of it. But there are some deeper issues.

Deeper issue A applies equally if you *are* the government of China.
Would it make sense for you to be trust root CAs controlled by other
governments? Of course, this might seem a more academic question if you
in China since your OS is likely MS Windows made in the US anyway.

Deeper issue B is a simple engineering failure calculation. Even if you
only trust reliable CAs that will protect your security 99 years out of
100 (probably a generous estimate of CA quality), then with 100 such
roots you can expect to be pwned 63% of the time.
(1 - 0.99^100) = 0.63

> But CNNIC passed the test to get into the root lists.

That tells me it was a bad test.

> Which do you want? A CA gets into a root list because it is nice and
>  pretty and bribes its way in? This was the old way, pre 1995. Or
> there is an objective test that all CAs have an equivalent hurdle in
> passing? This was the post 1995 way.

There's no dichotomy here. Cash payments can make a fantastically
objective test.

> There's no easy answer to this. Really, the question being asked is
> wrong.


> The question really should be something like "do we need a
> centralised root list?"

Well something is going to get shipped with the browser, even if it's
something small and just used to bootstrap the more general system.

How about these questions:
When is a centralized root list necessary and when can it be avoided?
How can the quality of root CAs be improved?
How can the number of root CAs be reduced in general?
How can the number of root CAs be reduced in specific situations?

and most importantly:
How can we give the people who need it the skills and information needed
to assess the security of their connection?

> This is the geek's realisation that they cannot control their list of
>  "trusted" CAs.

It's more prosaic than you make it sound.

When engineers sit down to review the security of a real-world product,
often with sharp people from the customer's side present, occasionally
someone thinks to ask the question: "OK, so supposing there are no
killer defects in the implementation, and all the crypto works as
expected, who has keys to the damn thing?"

If the product's implementation relies on SSL/TLS (e.g., has a
management port with a web interface), then be prepared to have this

To me this is a validation of the cipherpunks' foresight of taking the
attack model at face value. What was once considered spy-fantasy
paranoia by many is, in reality, a textbook engineering calculation
after all.

> Their judgement is undermined, as MS Windows' root list has gone the
> next step to dynamic control, which means that the users' ability to
> verify the root is undermined a bit more by not having an ability to
> stop the future dynamic enhancements.

You can go to "Add/remove Windows Components" (or whatever they call it
these days) and remove the "Automatic Certificate Update" feature. But
if you do this you need to be prepared to troubleshoot some pretty
mysterious breakages many months later after you've forgotten about it.

> In practice, if we assume a centralised root list, this is probably
> the better result.

Maybe sometimes. But when?

This is very hard to quantify because it's all theoretical until the
instant that the client software tries to make a connection to a
specific server and receives a specific certificate from the next-hop
router. Does the client software accept the connection or fail it and
tell the user that they're possibly being attacked?

 From a UI designer's perspective, this is as close as to a "launch the
nuclear missiles" moment as they're ever likely to encounter because
showing the scary page to a browser user instead of the page they
requested probably seems pretty much like the end of the world to these

Here's an example of some thinking by UI design types. It's obviously
biased, but it confirms my own biased experience :-) so I'll link it:

> It works quite simply: 1 billion users don't check the root list, at
>  all. They rely entirely on the ueber-CA to generate a good root
> list.

Isn't this basically the system we have now with the browser vendor
acting as the ueber-CA?

> A tiny fraction of that number (under 1 million, or 0.1%) know about
>  something called a root list, something perversely called "trust"
> bits, and the ability to fiddle those bits. They do that, and imagine
> that they have achieved some higher level of security. But, this
> technique has difficulty establishing itself as anything more than a
> placebo.
> Any model that offers a security feature to a trivially tiny
> minority, to the expense of the dominant majority, is daft.

Heh. Unless the dominant majority has a dependency on this tiny minority 
that they are unaware about:

http://www.cisco.com/en/US/products/sw/secursw/ps5318/index.html :
> Cisco Router and Security Device Manager (SDM) is a Web-based
> device-management tool for Cisco routers [...]
> It ships preinstalled on all new Cisco 850 Series,
> Cisco 870 Series, Cisco 1800 Series, Cisco 2800 Series, and Cisco
> 3800 Series integrated services routers.

The people who legitimately manage Cisco routers are a tiny minority, 
perhaps you would consider them "trivial". Yet the dominant majority of 
users' internet traffic is passing through a Cisco router at some point.

Now maybe it's different for ISP core router admins, but the existence 
of this product strongly implies that at least some admins are 
connecting to their router with their web browser over HTTPS and typing 
in the same password that they use via SSH.

Gee, how the heck do you suppose Cisco admins are going to get a unique 
and valid certificate on every router like that?

A lower layer (IP routing) depending on a higher layer (TCP port 443 and 
PKI) for it secure functioning. This is the type of layering violation 
and cyclic dependency that will take down the entire internet if we're 
not careful. Let's hope it doesn't take down the power grid along with it.

> 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.

The party that decides the quality of the authentication is the party 
that writes the check for it. This is often not the party with the most 
to lose and is almost never the end user.

In other words, Microsoft and Mozilla are looking out for their own 
interests. Their interests diverge in significant ways from the 
interests of secure sites, ISPs, corporate firewall admins, governments, 
and even their own end users.

> Or: find another model. Change the assumptions. Re-do the security
> engineering.

We need some new ideas, that's for sure.

- Marsh

More information about the cryptography mailing list