[Cryptography] identification / authentication / trust / authorization +- PKI +- CA

[John Denker]

On 10/01/2016 09:35 PM, Peter Gutmann wrote:

> [0] Now I know some people are going to claim PKI isn't a failure, and to some
>     extent that's correct, since there was never any mission statement for PKI
>     beyond "you asked for PKI, here is some" it's not really possible to say 
>     it's failed.  Or succeeded.  Or anything really.  However given that twenty 
>     years of evidence indicates it has no effect on phishing, malware, or much 
>     of anything else that you'd sort of expect it to deal with, I'm going to 
>     say it's been a failure.

I 99% agree with that in spirit.  There is however a counterargument
that should be given "some" consideration.  It starts with the following
vague mission statement:

  "We would like to conduct e-commerce on the scale of 300 billion dollars
  per year, so we need a setup that is (a) easy enough for consumers to use,
  (b) secure enough that consumers will type in the credit-card numbers,
  and (c) secure enough that merchants will want to play along."

In the context of that rather vague mission statement, one could argue that
PKI, as implemented by the current CA/browser scheme, has been a success.

One counter-counterargument is that what we have now is so poorly designed
that it could collapse at any moment.  The canaries in the coal mine died
a long time ago;  we are now seeing miners drop dead (e.g. WoSign/StartCom).
Steps that could be taken to help forestall an explosion are not being
taken.

A related argument is that the CA/browser model is being extended beyond
e-commerce, extended to more demanding applications where it cannot handle
the load.


On 10/02/2016 05:45 AM, Jerry Leichter wrote:

> 2.  The vast majority of my connections to a site occur *after* the
> first.  Why would I need a CA for those?  What I really want is
> ssh-style key continuity.  The CA simply gets in the way here - and
> in fact the introduce a whole level of extra vulnerability, because
> it *may* lead to to trust a fake site *even when I have reliable
> information about the real one*.  Oh, and of course the site doesn't
> need the CA to change keys - it simply needs to sign the new ones
> using its old ones, maintaining continuity.

Excellent.  That makes several important points.

On 10/01/2016 11:43 AM, Peter Bowen wrote:

>> I'm very open to other solutions, work for a member of the CA/Browser
>> Forum, and am not known for being quiet at the Forum.  Please suggest
>> solutions!

When you say "we really need pinning and we really need certificate
transparency" how to they respond?

When you say "we need much wider use of X.509v3 Name Constraints" how
do they respond?

    I mean seriously, does the Hong Kong Post Office really need
    unrestricted authority over every domain-name in the world?

When you say "the browser should have one true root, and the existing
CAs should exist at the /second/ level, /signed/ by the one true root"
how do they respond?

   This would create a revocation mechanism that does not currently exist.

   Also, this wouldn't make superfish impossible, but it would make
   it much harder to pretend that it was an innocent mistake.  Bad
   guys would have to hack the browser in ways that would flagrantly
   violate Mozilla's trademark.

When you mention cross-signing, how do they respond?

  This does not solve all the world's problems, since an advanced
  persistent threat can subvert two CAs almost as easily as one
  ... but it does help with a few things, such as when the old CA
  signs off on the transfer to a new CA.

When you mention having the old leaf certificate cross-sign its
replacement, how do they respond?

  This is a Big Deal, because it means the attacker would need to
  subvert the key owner (not just the CA).

>> The key challenge is how does a human using a web browser authenticate
>> a connection to a website that they have never previously visited?

I would not have called that "the" key challenge.

>> This the core problem that browsers are trying to solve by using PKIs.

Yes, people /want/ to solve that problem using PKI.  It could be argued
that e-commerce is a real thing, so "some" version of the problem has
been solved.

On the other hand, there are still lots of vulnerabilities.  So we
are faced with the challenge of redesigning and rebuilding an aircraft
on the fly.


There are at least three crucial concepts that must be distinguished:
 -- continuity;
 -- establishing identification/authentication; and
 -- establishing authorization and trust.

It is quite possible to have continuity in the absence of authentic
identification.  An example would be a long-running discussion with
some pseudonymous pen-pal.

It is also quite possible to have identification/authentication can
be used to establish continuity, but it's not the same thing.  Both
can exist without trust.  For example, I might know with absolute
certainty that a certain key belongs to a certain recently-paroled
arsonist, but that does not mean I would /trust/ him to serve as
night watchman at the lumber yard.


Notable efforts in the area of key management include:
  -- the CA/browser model
  -- the PGP model, with "web of trust" and "key signing parties"
  -- the SSH model
  -- various credit-card models (card + signature, card + PIN, etc.)
  -- etc.

Note that SSH actually does support the notion of CA, but typically
users just rely on the continuity (pinning) features, and establish
identification and authorization out-of-band.

I suggest that browsers should become more like SSH, relying much
more on pinning and much less on CAs.  This does not require giving
up CAs entirely.  However, if the CA says one thing and the pin
says another, that should set off alarm bells.  There is a distinct
possibility you are under attack.  I'm not sure what is the right
way to proceed in this case, but blindly deferring to the authority
of the CA is definitely not right.

I use PGP, but I have never used the "web of trust" features.  In 
this context, I have no idea what "trust" is supposed to mean.  I 
have no idea how to quantify or even define "trust" in the abstract.
In the context of e-commerce I might /authorize/ the merchant to
charge $14.99 against my account, but that does not mean I bestow
any other form of trust or authorization on the merchant.

Back when everybody lived in the same village, identification implied
a certain amount of trust, because if somebody breached a contract
your enforcers could easily get in touch with him.

  In contrast, being able to 
>> authenticate a connection to a website
  does not establish trust, because the website might far away,
  beyond the reach of ordinary enforcement mechanisms.

The current CA/browser setup seriously screws up the distinction
between identification and trust.

Trust is a tricky thing.  Cryptography cannot create trust out of
nothing.  It can perhaps sometimes facilitate a discussion that
leads to a modicum of trust.  A typical CA certifies the /name/ of
the website but does not pretend to certify trust ... yet customers
are instructed to trust the connection.  It's insane.  Meanwhile,
on the web there are various sources of information about the reputed
trustworthiness of various actors.  At present there is no direct
way of binding this information to the certified names ... but there
could be.  This is a fixable problem.

These are just some of the many many reasons why I say that we in the
security community have lots of options.  There are lots of things
we could do, and lots of recommendations we could give to non-experts,
short of recommending that they drop off the grid.

For starters, let's recognize that continuity (aka pinning) is very,
very important.  We can make it very efficient to re-visit a site.

  In contrast, as J.L. pointed out, relying on a CA on the second visit
  is a step in the wrong direction.  It means that a hundred different
  CAs can get in on the action, and each one becomes a single point
  of failure.  This is insane.

The /first/ visit to a site should have much lower requirements for
efficiency, and much higher requirements for security.  Among other
things, the first visit should require vastly more authentication
of the client ... and of the server!

Let's be clear:  It is important to distinguish the first visit from
the typical visit.

On 10/01/2016 09:35 PM, Peter Gutmann wrote:

> Ever tried to set up TLS on a non-
> public-Internet network (RFC 1918 or whatever)? 

Yes.

> You basically can't, unless you use your own software on both the
> client and server.

My experience says otherwise.  I've been there and done that, using
standard software, e.g. apache and firefox.

> Browsers just don't work there, because needing to ask a CA for
> permission to encrypt is hardwired into them.

So just set up your own CA.  I use a hacked-up version of the CA.pl
script that ships with openssl.  I wrote 12 pages of instructions to
guide me through it, which means it is more complicated than it ought
to be, but it's doable.  One of the steps is teaching the browser
about the new root certificate, which is not particularly hard.
Eradicating extraneous roots is even easier.

This lets me set things up the way I like.  A good maxim is:
   I /trust/ such-and-such certificate because I issued it!
I've used this maxim in the context of TLS, SSH, IPsec, et cetera.