[Cryptography] certification by N=0,1,2... authorities

[John Denker]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In the context of "TB2F CAs as (un)official browser policy",
on 03/23/2015 04:35 PM, Tom Mitchell wrote:

> Is there a useful system designed that could demand two or three
> certificates?

There are about five ways of interpreting that question;
see below for some interpretations and some partial answers.

> It seems to me that a collection of central authority resources
> will always have an event at one or from time to time where
> the notion of trust is not going to be absolute.
> 
> The odds of it happening to three simultaneously seems remote.

I don't think the odds are remote at all.  In the recent
"superfish" fiasco, a bogus CA was inserted into the list
of "trusted" CAs.  How much extra work do you think it 
would have been to insert two (or more) bogus CAs?

More is not always better;  I am reminded of the guy who
thought quadruple-rot13 would be better than triple-DES.

  OTOH an N=2 authority scheme, if done right, could 
  have some value.  The devil is in the details.

Returning to the first question:  Broadly speaking, such
things have been designed, and even deployed.  The PGP 
web-of-trust (WoT) is a familiar example.

More narrowly speaking, given the context I assume the 
question intended to focus on browsers in particular
or x.509 in general.  Even in that case, the mechanism
for such a thing has been "designed";  see the discussion
of "mesh structures" at
  http://tools.ietf.org/html/rfc4158#section-1.5.2

However, no browser implements such a thing, and before
implementing it one would need to come up with a policy
(not just a mechanism) ... and it's not clear what a
sensible policy would be.  We need to have a discussion
of What's Your Threat Model and conversely What's Your 
Use Case.

Here's one use case that pops to mind:  Suppose that
country X has been at war with country Y for the last
50 years or so.  Such a thing is not particularly hard
to imagine.  Now suppose that the root of trust in the
major browsers includes a lot of CAs that are domiciled
in or otherwise dependent on country Y, and that many
sites across the world depend on such CAs.  This puts
X in a bad situation;  they can't trust those CAs, but
they also can't just throw them out, if they want to 
get any work done.

It would be nice to have some means whereby country X
could double-check the work of various foreign CAs.
The idea is simple enough, but we are a long way from 
being able to do this.  Mozilla, for instance, doesn't
even have a way to revoke a certificate that is in
its root-of-trust list!  And they have no intention
of fixing it.  They say this "doesn't make sense" ... 
even in connection with an example (i.e. superfish)
where it would make a great deal of sense.  Amazing.
  https://bugzilla.mozilla.org/show_bug.cgi?id=1134506#c32

I'll tell you what doesn't make sense:  Having more
than 150 "roots" doesn't make sense.  It defies the
definition of "root", in botany as well as in computer
science.  A browser should have *one* root, representing
the Lord High Certzilla.  If it wants to trust some
other CAs, it should /sign/ their certificates. (Such 
a signature would of course be revocable.)  This is 
the logical x.509 way to represent what is actually 
going on.

  The fact that the Mozilla Foundation pays Digicert
  Inc. to certify the mozilla.org domain is comical,
  given that for practical purposes most people rely 
  on firefox tell them whether or not to trust Digicert.

  Similar words apply to other browsers.

======================

Continuing the discussion of N-way certification, we
have just consider the possibility of N greater than
one, but we should also consider the case of N less
than one.

A familiar example of this is ssh.  Although it knows
about authorities, most people don't use it that way.
Instead they rely on a ToFU model:  Trust on First Use.
A better word for this is pinning, since really it
signifies /same/ as first use, whereas the degree of 
"trust" is another matter entirely.

Here's a use-case where N=0 authorities makes sense:
Suppose Joe User is dealing with a wireless base station. 
It needs to be configured using a web interface.  How
do we secure that?  x.509 was designed with e-commerce
in mind, but the base station doesn't fit that model
at all.  It doesn't come with a domain name, nor 
should it.  Joe may not give it a name at all, and 
even if he did, the name is not certified.  Obtaining 
and installing a certificate is orders of magnitude 
more work than Joe will do, or should do.

In contrast, the SSH pinning model works reasonably well
in this case.  Joe resets the device to some standard
state, and then connects to it on a secure air-gapped
wired network.  He makes an ssh connection.  He can
trust this (for the appropriately limited purposes) 
on first use, because of the air gap.  From then on,
he can ssh to the thing in confidence.  The ssh key 
does not certify the domain name or even the IP address;
it merely signifies that the box is the same box as
last time.

So now we see what the real issue is:  What is the
/meaning/ of a key, and what is the /meaning/ of a
signature?  This issue affects PGP, x.509, ssh, and
all the rest.  When I sign John Smith's PGP key, what
does that mean?  Does it mean the guy's name really
is John Smith?  Does it mean I would trust the guy
with ten dollars?  Does it mean I would trust the
guy with ten thousand dollars?  Very often I would
like to signify nothing other than the fact that this
is the same John Smith that I've dealt with before,
i.e. pinning.

  In the real world, there are ways of figuring out
  what a signature means.  Signing the front of a
  check means one thing.  Signing the back means
  another.  Signing a petition to recall the governor
  means yet another.  Et cetera.

For configuring the wireless base station, pinning
alone is just fine.  For e-commerce, we really ought
to be using two factors:  authority plus pinning.
Two factors all different works better than two
factors all alike.  Firefox claims to do pinning, 
but if you look into it you discover they only pin 
a handful of sites.  There exist add-ins such as
  http://patrol.psyced.org/
but I find it hard to take that one seriously; 
 -- At the height of irony, they don't bother to 
  secure their own site with https (with or without 
  pinning).  Evidently they don't really think
  https is important.
 -- They don't bother to sign commits to their 
  git repo. 
 -- If you clone the code in their repo, the "make" 
  command fails.
 -- No work has been done on the project in 3+ years.

There's also another form of pinning, for sites that
want to be pinned:
  https://developer.mozilla.org/en-US/docs/Web/Security/Public_Key_Pinning
but I want to pin the other 99.999% of the sites.

Does anybody know of a pinning add-in that they
trust to do something useful?  Perhaps some smart 
person on this list could write something using 
certpatrol as a starting point or otherwise.  (I'm 
busy at the moment.)

  For completeness, we should note that the same
  guys who subverted the root-of-trust in the
  superfish case could almost as easily have
  defeated any pre-installed pinning mechanism.
  As Ken Thompson pointed out, once people start
  messing with your supply chain, you're screwed,
  and it is hard to get unscrewed.

Still, I do not understand why browsers make it so hard 
to use authority+pinning ... or pinning alone (as in 
the case of Joe's wireless base station).

There is a big gap between algorithms and implementations.
I reckon we have all the algorithms we need to make
stuff secure if we wanted ... but sometimes I think
we're not even trying.  The spies and the gangsters
of the world must be laughing themselves silly:  More
than 150 "roots" with no way to revoke them, and not
the slightest interest in fixing it?  Bwa-ha-ha-ha-ha.
Talk-talk-talk about cover traffic as a defense against
traffic analysis, talk about it for years and years 
but don't do anything about it.  Bwa-ha-ha-ha-ha.
Still no serious pinning.  Bwa-ha-ha-ha-ha.

Also, if you need help meeting your recommended daily 
allowance of ridiculousness:  The cobblers have holes
in their shoes:
  -- www.mit.edu is still offering export-grade ciphers
  -- csail.mit.edu is still offering SSLv3
  -- cybersecurity.csail.mit.edu doesn't offer HTTPS at all

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIVAwUBVRGq0fO9SFghczXtAQL59g/9HCUePEFllDYcf3w+irIjTic4+tV0+zoE
/mfRvFFhzisfVj5fGEEZNsM9YNWY4Wll9dw10B1JAryIZJmuC5yu2XlL+7ud0+AX
Oj0mxfgLHKS/ws7OSdicvRXo9/tHCPqt4DG3USrF6fV6MzKCoeut1/0k7SVqH9LF
7mbpaCGN7x+sCHM7pUyRsZKkYHVaFE6oLfkAZet6900hWA9+BBlHLL/4pPvl3s5R
kTt6SL2J7H08g1CmDKZQGbEiPWLeVIWebl3WxOiNgrn9Lcj2SsX90GpJ+o9i2WoG
O0nOImc0LDZ74Npfqy9Lak6TOtxXeC4yNVRweKQ36zSanlgsEa1pNOJWxZ96uHH0
cDoFutPPnGqnAfekxqAerNlqIFg+OA90wTwg+eNoy9Im/HEoXjHki4LPC6oRqmpC
K314r160IdFbnqK1OZ3Xe4iMTwCl9SB8aBC128xyZf6SZta46pAWz97bXUWcAIeJ
oo6ZJSgpfPGkcQTVO83L7kCyb5fQwazbRz/6SUOqWMneGJxT2fXXZ9cZg5ySz5Bq
FZuDiRXaQ6LFX+v+FiqaVjtX+ygfUQgdC/zT6cG7yeQAe+qQJIH6PDGVLpgUsPJw
Ca0RGflY1Qep7A2un3ASxJ+6gyrYByoD6ySSbAnbW6T94eOp0wjlGns9LGToz634
K0g8zA6m2HM=
=pRg9
-----END PGP SIGNATURE-----