[Cryptography] improved CAs and CRLs ... was: Verisimilitrust

[John Denker]

On 01/12/2016 03:15 AM, Ben Laurie wrote:

>>  To put it another way, if the CA goes away, the revocation info
>> still gets to the browser.  If the browser vendor goes away, the revocation
>> info doesn't get to the browser any more ("CRL/OCSP checks are not
>> performed").

> Or, to put it another way: if CAs didn't do the majority of
> revocations, who would do it instead? Not the browser vendors, that's
> for sure.

You guys are needlessly talking past each other.  In general, there
is such thing as *multifactor causation*.  Factors can exist in
series and/or in parallel.  You can't explain the overall situation
by picking on one factor or the other.  Today we are considering
a situation where users are depending on the CAs *and* the browser
maker to do the right thing.  The CA _originates_ the revocations,
and then the maker inserts a _meddling proxy_ in series.

Note the contrast:
 *) If the CAs went away, then
   -- In the short term, users might coast along using old CRLs.
   -- There would be no _new_ revocations, since the maker doesn't
    even pretend to originate such things.
 *) If the makers' proxy went away, the user is screwed, short term
  and long term, because there is no direct access to the CAs.

The proxy messes with the CRLs to promote what the makers call
"efficiency".  This makes the normal, non-revoked case faster,
at the cost of making revocations slower and less reliable.

> It is unsurprising that browser vendors are reluctant to rely on CAs
> to revoke their own roots.

Oh, it's much worse than that.  To revoke a CA, you can rely on
neither the CA nor the browser.  When the "superfish" rogue CA 
was discovered, the mozilla guys had no idea what to do about it.
They have no mechanism to revoke it ... and they don't consider
this to be a problem.  To this day, the issue is classified as
"RESOLVED WONTFIX"
  https://bugzilla.mozilla.org/show_bug.cgi?id=1134506

In other words, "not my job".
  https://www.av8n.com/physics/not-my-job.htm

> the core issue: how do you bind domain names (or identities
> or whatever) to keys and deal with the inevitable errors in doing so
> without introducing some kind of third party? What realistic system do
> you propose to replace the CA gravy train with?

A perfect solution is provably impossible:  If somebody wants
to put you in a Truman Show Matrix, he can probably do it, at
least occasionally.  However, we should not let the perfect be
the enemy of the good.

I'm not sure "replacing" CAs is the correct focus ... but there 
are lots of things we could do to improve the situation.

 *) As previously discussed, properly-implemented NameConstraints
  would alleviate a number of problems ... not just the current
  Borat CA problem.

 *) Pinning would help.  Again we have the idea of multiple
  factors.  You can do better with pins *and* authorities than
  with either one separately.

  People have lots of experience with pinning in the context
  of SSH.  Note that SSH is *not* pinning-only;  it knows about
  authorities too.

  Mozilla has made some very tentative steps toward pinning.

 *) Redundant signatures.  People are familiar with multiple 
  signatures in the context of PGP ... and from long-established
  business practices:  When a salesman (Chico) takes a client
  to lunch, to get reimbursed he has to submit a voucher, signed
  by Chico and by his boss (Harpo) ... unless Harpo was at the
  lunch, in which case it has to be signed by the higher boss
  (Groucho).  This is not rocket surgery.  I would like to see
  high-value certs countersigned by a second CA.  This would 
  make it harder for a rogue CA to get traction.  Not impossible,
  but harder.

  Within X.509 there exists a mechanism for doing this sort of
  thing ... although as we would expect from X.509 it is a mess.
  I'm not sure how widely supported it is.

 *) Root control.
  Right now, e-commerce merchants are certified by the so-called
  CAs ... while the CAs themselves are, for practical purposes,
  pseudo-certified by the browser makers and/or software distro
  bundlers.  It doesn't have to be that way.  For starters, 
  there should be only *one* root.  That's what the word "root"
  is supposed to mean, as should be obvious from the botanical
  etymology if nothing else.  Rather than hard-coding the hundreds
  of CAs, the browser maker and/or bundler should *sign* the CA
  certificates.  This would make clear the chain of responsibility,
  and would establish a mechanism for revocation of rogue CAs
  (which is at present grievously and ludicrously lacking).

  It is trivial to take an existing self-signed "root" certificate,
  turn it into a signature request, and then sign it.

 *) More root control.
  Furthermore, imagine Zeppo works for the Freedonia Self-Defense
  Forces.  It would make sense for his browser to trust certain
  CAs not because they call themselves CAs, nor because they are 
  pseudo-certified by some foreign bundler ... but rather to
  trust only sites and CAs that have been approved and signed 
  by the FSDF Information Assurance department.

     Seriously, the last time I deployed a cryptosystem I cared
     about, this is how it worked.  It was PK without the PKI.
     The keys were trusted because and only because I issued
     them!  No gravy-training required.

  Again, there exist mechanisms for doing this.

 *) Signature chain continuity.
  When a merchant wants to start using a new key (because of
  impending expiration or whatever) the new key should be
  signed by some authority *and* by the old key!  This would
  greatly increase the attacker's cost in some situations.
  It's relatively easy for the Bad Guys to coerce one of the
  oh-so-very-many CAs to issue a certificate for MITMing my
  traffic ... but it greatly raises their cost and risk if they
  have to mount a black-bag job to get my old key.

 *) et cetera.  See this forum's previous nice, long-running
  discussion of pathetically obvious problems, many of which
  are fixable.