Subject: RE: Global PKI on DNS?

From: Franck Martin <[email-masked]>
Date: Fri, 14 Jun 2002 10:52:47 +1200

on www.example.com being squatted, the problem is the squatter does not
get the private key, so yes it has a certificate with a public key, but
everybody does...

To use the certificate, he will have to regenerate a private key, which
means a new certificate and expiring the old one.

The question is, as all domain names are registered with credit cards,
how much do you trust banks? Do we need more trust?

Indeed there are a few problems with social engineering but, the game is
to propose something, pass it through review of security experts and see
if they can improove.

SSLv1 was hacked during its first official presentation...

Also, in my internet explorer there are a bunch of root certificates
that I don't know about and if you send a e-mail to Microsoft they will
add your root-CA to the windows update site that will push it to all
Internet Explorer.

Ideally, we should rate each CA in our applications and the application
should give us a level of risk...

Most of the time what we want is tracability. I have a problem with a
site, then I look for who paid for the certificate and then get the card
holder and then involve the police. I have someone to get hold of...
What all CA out there are just doing is passing the buck and ensuring
they can do it...

Cheers.

-----Original Message-----
From: Christian Huitema [mailto:[email-masked]]

Part of the problem is that we are mixing to issues, i.e. "am I speaking
to the server that is legitimely designated by the name
www.example.com", and "am I speaking to the service that is supposed to
manage my examples." Attaching certificates to names may solve the
former; solving the latter requires that the user discovers in a trusted
way the DNS name associated to the service. We know that there are many
psychology-based attacks that can fool users to connect to use the wrong
name; PKI certificates attached to the DNS name is not going to solve
that.

There is in addition an even more murky area, which is the validity of
the binding over time. Some artists specialize in grabbing DNS names
that their legitimate users fail to renew in time. Suddenly,
www.example.com is not managing my examples anymore, it has become a
gateway to a porn site. Yet, that porn portal has a perfectly valid and
up-to-date PKI certificate. Amusing, isn't it?

-- Christian Huitema

---

From: Chris Evans <[email-masked]>
Date: Thu, 13 Jun 2002 16:29:17 -0700

If some cretin p8s your domain name away from your IP then when some1 request the 
pubic pki from that domain they will get bogus info. and the transaction will 
abort.   now if the same pki info was on DNS, they still get good and transact 
with the cretin instead of u.  that info need be on your own harddrive under your 
own control.

--chris

---

From: [email-masked]
Date: Thu, 13 Jun 2002 22:36:46 -0400

> should give us a level of risk...

Hey.. it's the PGP Web of Trust. ;)

---

From: Einar Stefferud <[email-masked]>
Date: Thu, 13 Jun 2002 23:30:47 -0700

[email-masked] said:

>>Content-Type: application/pgp-signature
>
>Attachment converted: Macintosh HD:Untitled 1 (????/----) (0009FFDB)

By George -- I think You've Got It;-)...

Trust must be earned, and cannot be delegated;-)...

And cannot be transmitted via any single communication path.

Enjoy;-)...\Stef

---

From: Robert Elz <[email-masked]>
Date: Fri, 14 Jun 2002 17:02:25 +0700

There's a simple reason why the DNS isn't suitable as a PKI,
and it has nothing to do with transitivity of trust, and nothing
to do with DNS packet size limitations, or root server workloads.

It is that DNS admins did not sign on for the job of authenticating
anything (with the possible exception of the DNS itself).  That's
not what they do, and for most DNS admins & operators isn't something
they have any interest in doing.

All it would have is one DNS admin somewhere in the path that counts
to say "get lost" when asked for some appropriate certificate, and the
whole model breaks.

Just let the PKI stuff be done by those interested in certifying who
is what, why, and perhaps where, and when, and leave us DNS types alone.

kre

---

From: Stephen Kent <[email-masked]>
Date: Fri, 14 Jun 2002 08:28:33 -0400

>And cannot be transmitted via any single communication path.

PGP is the epitome of transitive trust!

Multiple cert paths do not necessarily make for more trust, but they 
do add enough complexity to make the system unscaleable, not to 
mention the revocation issues ...

---

From: Michael Richardson <[email-masked]>
Date: Fri, 14 Jun 2002 13:06:55 -0400

>>>>> "Robert" == Robert Elz <[email-masked]> writes:
    Robert> There's a simple reason why the DNS isn't suitable as a PKI,
    Robert> and it has nothing to do with transitivity of trust, and nothing
    Robert> to do with DNS packet size limitations, or root server workloads.

    Robert> It is that DNS admins did not sign on for the job of authenticating
    Robert> anything (with the possible exception of the DNS itself).  That's
    Robert> not what they do, and for most DNS admins & operators isn't something
    Robert> they have any interest in doing.

  Okay, so they won't do that, and they won't secure their zones, or provide
keys in their zones.

  Don't tell *me* what I can and can't do.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [

---

From: Keith Moore <[email-masked]>
Date: Mon, 17 Jun 2002 10:43:11 -0400

> If explicit trust is required I agree, but in the DNS case we already
> have a singly-rooted tree that everyone relies upon. if you want to
> use the word "trust" then we all trust the root for DNS, but I think
> the term is not applicable here.

I think the word "trust" accurately reflects the situation.

People do trust the current DNS to some degree.  The danger of a DNS-based 
PKI is that people will invest far more trust in the DNS PKI than is 
warranted, and/or that the root and/or TLD servers will abuse that trust.

Recent history demonstrates that such abuse is likely.

Keith

---

From: Stephen Kent <[email-masked]>
Date: Mon, 17 Jun 2002 10:55:13 -0400

>Recent history demonstrates that such abuse is likely.

Keith,

I think you raise a valid concern, but it's one we always face when 
transitioning from an insecure system to a more secure system. People 
may misuse any security technology by imbuing it with more 
capabilities than the developers of the technology intended. However, 
if we always let that concern deter us, we will rarely make progress. 
Also, this is not a suggestion to deploy a DNS-based PKI in lieu of 
other PKIs; I am a believer in multiple. independent PKIs. So I see a 
DNS-based PKI as fulfilling just one role, i.e. vouching for the 
binding between a DNS name and a key. There is plenty of room for 
other PKIs to exist, vouching for other bindings.

Steve

---

From: Keith Moore <[email-masked]>
Date: Mon, 17 Jun 2002 11:49:59 -0400

> other PKIs; I am a believer in multiple. independent PKIs. 

so am I, but I also believe that a DNS-based PKI will displace other PKIs -
if we really want multiple independent PKIs we shouldn't try to make one
that is based on the DNS hierarchy.  using DNS to return certs might be okay,
(assuming you can work out the protocol warts), using DNS delegation as 
the framework for a distinguished PKI isn't.

Keith

---

From: Stephen Kent <[email-masked]>
Date: Mon, 17 Jun 2002 12:17:51 -0400

Keith,

Yes, one could use the DNS merely as a repository for certs from any 
PKI. But, the DNS provides a unique opportunity to take advantage of 
an existing name system that is very widely used and which is 
precisely the way we usually communicate the name of the machine to 
which we wish to connect (or the name of the person to whom we wish 
to send a message). Any time we try to create a new naming system we 
run into lots of problems. Any time we try to map from a PKI name 
space to a different name space used by an application, we get into 
trouble. Ultimately I do not think there is any substitute for a 
DNS-based PKI to support most of our Internet communication, because 
that communication is naturally expressed in terms of DNS names.

Now, having said that, I acknowledge that one can have such a PKI but 
not choose to have a single root for it. One could have each TLDs act 
as its own root and cross certify (using name constraints) to link 
the TLDs  together. There are a small enough number of TLDs to make 
this feasible. The number of second tier domains is way to big to 
make this work well. It would be much simpler to have a single root, 
but ...

Steve

Steve

---

From: Keith Moore <[email-masked]>
Date: Mon, 17 Jun 2002 12:27:41 -0400

> to send a message). 

right, but the name is just a shorthand, it doesn't actually specify
the service to which we wish to connect.  it's entirely possible that
the name-to-service binding has changed without our knowing it,
which is why it's *essential* that we don't depend on such names 
as our primary identity for authenticaiton.

> the TLDs  together. 

What's the point of encouraging people to trust an untrustworthy structure?  

Keith

---

From: Stephen Kent <[email-masked]>
Date: Mon, 17 Jun 2002 12:41:28 -0400

>as our primary identity for authenticaiton.

The name is precisely what we specify to get to the machine (or 
cluster of machines) in question. So long as we use a DNS name for 
that purpose, it makes sense to use a certified DNS name to verify 
that we are connected to the place we said we wanted to contact. 
Which services are offered at that machine is a different matter. If 
I want to use certs with IPsec, then a cert with a DNS name is most 
appropriate. If I want a cert for use with S/MIME, then a cert with 
an RFC822 address is most appropriate, and having it be issued from a 
CA that is authoritative for the DNS name on the right side of the @ 
is appropriate.

>What's the point of encouraging people to trust an untrustworthy structure?

Do you say the structure is untrustworthy because the TLD registrars 
sometimes make mistakes? That is an inevitable side effect of any 
large database system.  The TLD databases ARE the reference for the 
next tier name/address mapping, right or not. Anyone else acting as a 
CA at this level would have to rely on those databases, or we begin 
to get into the T-word big time.

What else would provide a good PKI basis for the sorts of certs I 
allude to above?

Steve

---

From: Keith Moore <[email-masked]>
Date: Mon, 17 Jun 2002 13:54:10 -0400

> that we are connected to the place we said we wanted to contact.

no it doesn't.  because even if the name is what we type in, it's
not what determines whether we actually talked to the service we
wanted to talk to.  it's not what determines whether we trust the results.

> Which services are offered at that machine is a different matter. 

actually the user is rarely concerned about machines these days, he/she 
is almost always concerned with which service he/she is talking to.
the mapping between machines and services is almost arbitrary.

> sometimes make mistakes? 

Yes, among other reasons.  
Especially if you mean 'mistakes were made' in the Nixon sense.

But there's also the fairly fundamental problem that if you trust
the DNS PKI you're placing your trust in one or more parties with 
which you have no relationship, and no basis for trusting them.

This trust is abused enough already, but at present the gTLDs 
actually have only the barest of mechanisms for manipulating us.  
Give them more influence and they'll abuse it even more.  

> What else would provide a good PKI basis for the sorts of certs I

IMHO the very notion of a global PKI is fatally flawed.
OTOH limited-scope PKIs can be quite useful.

Keith

---

From: Stephen Kent <[email-masked]>
Date: Mon, 17 Jun 2002 14:19:05 -0400

Keith,

Well, we agree on the utility of having multiple PKIs. We disagree on 
the need for a PKI that happens to cover a specific name space that 
underlies the vast majority of IP-based communications, or at least 
you disagree on the desirability of that specific PKI given the 
reality of who runs which TLDs. But, you don't offer any suggestions 
on how to address the need that a DNS-based PKI satisfies.

I guess we should just leave our disagreement at that.

Steve

---

From: Keith Moore <[email-masked]>
Date: Mon, 17 Jun 2002 14:39:38 -0400

> on how to address the need that a DNS-based PKI satisfies.

I don't see it as a 'need' in that sense.  If you want to increase
the level of trust over the current situation, you pretty much have
to either exchange keying material directly with that party,
or pick a third party that *you* trust to serve as an intermediary.
It's really hard to have multiple intermediaries because you need 
to trust them all.  And just because someone runs a TLD doesn't mean 
that you want to trust them - it often means you should be wary of them.

It really doesn't have much to do with DNS - the problem is that 
real trust doesn't scale to that level no matter what the naming 
scheme or the protocol.

Keith

---

From: Keith Moore <[email-masked]>
Date: Sun, 16 Jun 2002 18:17:29 -0400

> mention the revocation issues ...

uuh.  A single root CA definitely doesn't scale, because there is no CA
that everyone can trust.  There might be scalability issues with multiple
paths, but they're not as fundamental as that.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 17 Jun 2002 10:12:00 -0400

Keith,

if we created a DNS-based PKI, we would be relying on the correct
operation of each of the DNS domains for secure identification, in
lieu of relying on them for insecure identification.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 19 Jun 2002 21:55:06 -0400

>that you want to trust them - it often means you should be wary of them.

direct exchange obviously does not scale well, and picking a third 
party gets into the trust problem all over again, as well as 
requiring that BOTH you and the other correspondent trust.

>real trust doesn't scale to that level no matter what the naming

Your later message clarified this, i.e., you believe that in general 
one cannot identify a third party who enough people trust to act as a 
CA for a large set of people. I argue that we are have learned to 
accept organizational entities as authoritative issuers of 
credentials all the time and that this is no different. This is not a 
suggestion to have only ONE PKI for everything. It is a suggestion to 
have exactly one for the purpose of securely binding DNS names to 
keys. If you are afraid that people would come to rely on this one 
too much, and that it would deter other PKIs from being formed, maybe 
that's an indication that it would be more valuable that you care to 
admit :-)

Steve

---

From: Keith Moore <[email-masked]>
Date: Thu, 20 Jun 2002 03:22:10 -0400

? >  > Well, we agree on the utility of having multiple PKIs. We disagree on
? >>  the need for a PKI that happens to cover a specific name space that
? >>  underlies the vast majority of IP-based communications, or at least
? >>  you disagree on the desirability of that specific PKI given the
? >>  reality of who runs which TLDs. But, you don't offer any suggestions
? >>  on how to address the need that a DNS-based PKI satisfies.
? >
? >I don't see it as a 'need' in that sense.  If you want to increase
? >the level of trust over the current situation, you pretty much have
? >to either exchange keying material directly with that party,
? >or pick a third party that *you* trust to serve as an intermediary.
? >It's really hard to have multiple intermediaries because you need
? >to trust them all.  And just because someone runs a TLD doesn't mean
? >that you want to trust them - it often means you should be wary of them.
? 
? direct exchange obviously does not scale well, and picking a third
? party gets into the trust problem all over again, as well as
? requiring that BOTH you and the other correspondent trust.

there are lots of third parties that pairs or small groups of us
trust for limited purposes.

there are no third parties that we all trust for all purposes.

? >It really doesn't have much to do with DNS - the problem is that
? >real trust doesn't scale to that level no matter what the naming
? >scheme or the protocol.
? 
? Your later message clarified this, i.e., you believe that in general
? one cannot identify a third party who enough people trust to act as a
? CA for a large set of people. I argue that we are have learned to
? accept organizational entities as authoritative issuers of
? credentials all the time and that this is no different. 

yes we do this *frequently*, but not "all the time" as in "we all
trust the same third party in every instance"

> This is not a
? suggestion to have only ONE PKI for everything. It is a suggestion to
? have exactly one for the purpose of securely binding DNS names to
? keys. 

part of the problem is that they're not just names - we bind other 
things to those names.  another part of the problem is that 
the meanings assigned to those names are subject to change without
our knowing about that.   another part of the problem is that 
TLDs have demonstrated that they're not trustworthy even given
their current responsibilities and power - so you're proposing
investing even more trust in them.

? If you are afraid that people would come to rely on this one
? too much, and that it would deter other PKIs from being formed, maybe
? that's an indication that it would be more valuable that you care to
? admit :-)

lots of people believe in superstitions too, but that doesn't mean that
they're useful to those people.

Keith