Re: From whence we came...

[Greg Hudson <ghudson@MIT.EDU>]

On Fri, 2002-01-04 at 01:59, James Seng/Personal wrote:
> I may trust DNS to give me the right network resource information. But I
> may not want to trust DNS to give me the identity of my banker. I may
> want to trust my trust authority for that purpose. PKIX allows me to do
> so (regardless of its other problems).

I will be the first to agree that a DNS identifier is not the best way
to identify a bank, or your roofing contractor, or anyone who has an
identity which is not tied to the DNS.  Unfortunately, we don't have a
lot of prior usage background for identifying institutions separately
from the DNS (for instance, right now, if you want to do business with
IBM, you simply trust that the owner of ibm.com is actually IBM and not
someone else), so I prefer to limit my consideration to applications
which do tie identities to the DNS.

But don't get me wrong.  I'm not saying there should be no other kind of
trust.

> PKI may some problems still needs to be resolves, many resolves in
> revokation, deployment, practices but to say PKI = Verisign is gross.
> You have ignored all the other PKI applications in non-Internet areas.

I'm essentially ignorant of these applications, and so do not know how
many of their lessons might apply to the Internet.  I can say that right
now, PKI as it applies to the Internet is very flat (even more so than
the DNS), very much a matter of certifying who owns what DNS domains,
very much tied to Verisign, and seems practical only for securing
operations which involve a high-budget entity (typically a company doing
e-commerce) on one or both sides.

> This is where the user choose which authority to trust. Depending on the
> user selection, the results is different.
[...]
> Nope, not everyone trust a single PKI root. Some group of people trust
> their one root. Other group trust their own root. There should be
> multiples PKI root, each one for different purpose with different
> policy.
[...]
> Pre-configured root CA for all purpose bother me a lot. It implies users
> to trust a default root CA without knowing they are trusting it in the
> first place!

I see statements like this from some subset of security people all the
time, and I can't help but find them hopelessly naive (or at the least,
not interested in solving the same problem I am).  This kind of attitude
leads to security systems like PGP: very useful for those of us who want
to actually devote time to worrying about trust, but with essentially
zero chance of developing widespread use.

The position is attractive to a certain mindset.  It goes something like
this: security is about trust, so we (developers of software and
protocols) must go to some effort to find out who the user trusts before
we should trust anybody.  Since trust is a personal thing, everybody
should have their own preferences.  No single entity should have a
distinguished position which they could abuse.

Well, I don't agree.  At the peril of sounding like a Counterpane toady,
I think security is about reducing risk.  Most users have no idea who
they trust and have no interest in researching the reputations of
companies like Verisign to determine who is trustworthy; also, the chaos
of having different trust preferences for every user would make it
difficult or impossible to establish a secure association between two
users or between a user and a well-known entity.

The solution, then, is not to ask each user, "who do you trust?" but to
create one or more high-profile organizations with accountability, who
we expect pretty much everyone to trust.  No one should force you to
believe them, of course, just like no one forces you to go believe in
ICANN's DNS information; but, as with DNS, you probably wouldn't find
the Internet very useful if you don't.

That's where we are with PKI on the Internet today.  My interest in
using keys-in-DNS instead of simply making every application use certs
stems from the following weaknesses in PKI as it applies today:

  * You can't get a certificate from a well-recognized authority without
spending too much money and (as I understand it) putting yourself at
significant risk.

  * As I understand it, the combination of standards and policies
currently in place do not allow an organization to get a single
certificate (say, for mit.edu) from a well-recognized authority which in
turn can be used to sign certificates for users (e.g. an email
certificate for ghudson@mit.edu) and subdomains (e.g. an SSH host
certificate for error-messages.mit.edu).  So MIT would have to transact
with the certificate authority for each user and each host.  Put simply:
DNS is more hierarchical right now than PKI is.

  * To the extent that identity is associated with DNS, it doesn't make
very much sense to have separate organizations deciding who is who.  If
peta.org changes ownership from People Eating Tasty Animals to People
for the Ethical Treatment of Animals, will the CA notice and stop
renewing peta.org certificates for the former?

  * Pursuant to the last point, certificates take too long to expire,
because certificates are essentially an off-line system and we assume
that certificate renewal is cumbersome.  Revocation would help, but the
revocation features I know about in X.509 don't seem very scalable and
aren't generally used.  Since DNS is an on-line system, signatures can
expire more quickly and domain turnovers can be more quickly reflected
in the security system.

> Extending a limited trust (trust of DNS) to generic trust is what
> bothers me.

I'm afraid that right now, what we have is generic trust of the DNS
without actual security of the DNS.