Subject: Re: dnssec discussion today at noon

From: Randy Bush <[email-masked]>
Date: Tue, 16 Jul 2002 10:00:23 +0900

> There will be a hastily-organized, informal gathering to talk about 
> where DNSSEC is (now that we see implementations of the DS record) 
> and is going.

by the way, i know this will come as a surprise, but there will also
be an actual wg meeting of dnsext, where this subject will be covered.
:-)

randy

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 16 Jul 2 10:48:45 JST

> be an actual wg meeting of dnsext, where this subject will be covered.

To stimulate (or cool down?) the discussion, here is a theory on
why DNSSEC (or public key cryptography as a whole) is unimportant.

Basically, public key cryptography is unimportant because the trusted
third party (CA) is an intelligent intermediate entity.

That is, CA, the trusted third party, do not have much information on
the first and second parties. Nor can it firmly control transactions.

With public key cryptography, in its simplest form, communication
with CA is not necessary for every transaction. But it is so, only
because the trusted third party knows or controls nothing about the
transaction.

However, for real security, it is essential that there must be
compensation for a failed transaction by a party responsible for
the failure.

Knowing nothing about the contents of transactions, CAs can not
be responsible.

In the real world, secure transaction consists of a chain of
credentials between the trusted first and second parties,
in which case, it is possible to identify on which part of
the chain a transaction failes.

If A send B some amount of money using banks C and D, there
is a chain of three credentials between A and C, between C
and D and between B and D.

If A buy something from B using credit card companies C and D,
there is a chain of three credentials between A and C, between
C and D and between B and D.

To complete a transaction, there must be a communication between
all the pairs of the trusted first and second parties.

Considering that we have the Internet, which connects all the
related first and second parties mostly in real time, it is
not a problem.

And, when there is a credential between the first and second parties,
they can share a secret information (password, PIN etc.) to secure
transaction, which is why public key is not necessary.

As usual with protocols violating the end to end principle,
there is a lot of attempot to make the protocol complex to
let CA, the intelligent intermediate entity, partially control
the transaction.

But, as we know, such attempts are assurred to be incomplete
and unusable.

For example, it is possible to set a upper limit on the amount
of money carried by a transaction. But, it is not effective
against repeated transactions.

This is why, with transactions using credit card in the real
world, authorizations are required on all the transactions
(except for buying, say, fresh food, too much repetition of
which will harm the attacker by increasing his weight) even
if there is a upper limit on each transaction.

Another interesting obserbasion is CRL. There is no expiration
period universally applicable to all the types of transactions,
CA may set a duration to expire a certificate and, in addition,
may issue CRL to invalidate it quicker, which is an incomplete
attempt of control. It is interesting that, with CRL, the trusted
third party must be contacted quite frequently.

Finally, there is a very convincing reasoning against PKI. That
is, "it's OSI".

						Masataka Ohta

PS

As public key cryptography is unimportant, CAs with web browsers
are already overkill and we don't need DNSSEC.

We can live with the weak security, security level of which is,
with proper 3 way handshaking with cookies, equivalent to that
of the telephone network.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 15 Jul 2002 22:21:33 -0400

Just to clarify what the meetings are for -

The noon DNSSEC meeting is to discuss plans for going forward on DS - 
who's planning what, workshops upcoming, places where tutorials might 
be given, etc.  The meeting assumes that the attendees are pushing 
DNSSEC forward.  Also, there's no plan to discuss any issue with the 
implementation/design of the protocol/specification.

The WG meetings are there to discuss the protocol itself, as per the 
agendas distributed.  The DNSSEC meeting isn't intended to conflict 
with the WG discussions.

If you want to argue whether DNSSEC is a good thing or not, I'm not 
sure what is the best venue...

PS - Sorry to cross-post but time until the meetings is growing short.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: [email-masked]
Date: Tue, 16 Jul 2002 13:29:38 +1000

> of the telephone network.

	And what does this have to do with DNSSEC?

	DNSSEC is designed to allow you to verify that the data you
	receive from the DNS is that which was entered.  That your
	transactions havn't been spoofed.

	What you do with that data is outside the scope of DNSSEC
	as is should a particular entity have been delegated a
	particular name.

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 16 Jul 2002 14:04:32 +0859 ()

Mark;

> 	And what does this have to do with DNSSEC?

The theory explains the reality that public key cryptography
(including DNSSEC) is not used for serious purposes.

The theory can be used to explain some (or most or all) of
operational difficulty of DNSSEC deployment.

> 	transactions havn't been spoofed.

Such security is not useful for serious purposes, when no one is
really responsible if your transactions are spoofed.

So,

> > of the telephone network.

Just as you can rely on people operating name servers, you
can rely on people operating routers.

							Masataka Ohta

---

From: [email-masked]
Date: Tue, 16 Jul 2002 15:50:08 +1000

> (including DNSSEC) is not used for serious purposes.
 
	No.  It explains why it may not be useful for some purposes.
	In no way does it demostrate that it not useful for DNSSEC.

> really responsible if your transactions are spoofed.

	Actually once DNSSEC is available there is a person responible
	if the data spoofed.  The person that entered the data in such
	away that it could be spoofed.

> can rely on people operating routers.

	Getting routers fixed to block spoofed traffic relies on
	*everyone* doing the right thing.  Getting DNSSEC working
	only requires that the operators of the root servers, down
	to the zone servers do the right thing.

	Mark

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 16 Jul 2002 15:10:50 +0859 ()

Derek;

> Public Key Cryptography is absolutely necessary for any
> store-and-forward protocol.  Note that I said PKC, not PKI.  The _I_
> part (infrastructure) is not necessary in many cases, but the
> technology of public key most certainly is.  The problem is that the
> alternative, secret-key cryptography, requires each pair of
> communicating parties to share a key, resulting in N-squared keys in
> the system.  OTOH, with public keys you only need N key-pairs in the
> system (each entity has only one key-pair).

That is a wrong counting.

First, the number of dynamically generated shared key is same,
regardless of whether you use public or shared key cryptography.

If N party directly interact with all the other N-1 parties, you need
N-squared keys regardless of whether you use public or shared key
cryptography.

Preconfigured secret-key, on the other hand, is necessary, only when
there is preconfigured credential.

By having KDC, we need as much secret key as necessary for PKI with CAs,
though KDC as the trusted third party is as bogus as CAs.

However, it is fine to have KDC as the trusted first or second party.

To send money from A to B through banks of C and D, secret keys are
necessary between A and C, C and D, D and B, but not A and D.

It is also pobbible to let banks act as KDCs.

> Note that the use of public-key cryptography is completely orthogonal
> to the issue of transactions or money transfer that you seem to be
> bringing into the picture.  I would purport that without public key
> cryptography you could have ZERO financial transactions on the
> Internet exactly because you could not secure them.  As an example,
> look at HTTPS (SSL/TLS) -- without Public Key, SSL would not work.

Huh? What is necessary for the financial transactions is credential
between credit card owners and credit card companies.

Weak protection by HTTPS does not essentially add anything.

> First, there is a strong goal to protect the DNS infrastructure.  I
> wont go into the numerous types of attacks possible against DNS (feel
> free to contact me personally if you really want to go down that
> rathole).  Suffice it to say that various cache poisoning and spoofing
> attacks can lead users and applications to contact the wrong server
> site.

That's why it is stupid to make DNS even more complex.

Feel free to contact me personally, if you really want to know the
rathole, for example, on how easily cache poisoning can be prevented
and how wrongly various implementations tried to prevent it.

> Second, some people believe that, once you have a secured DNS, you
> could use it to deliver Public Keys.  You may not believe in Public
> Key, but this is not the forum to debate that issue.

That is an uninteresting topic. Let's skip it.

							Masataka Ohta

---

From: Derek Atkins <[email-masked]>
Date: 16 Jul 2002 01:43:47 -0400

Unfortunately you are incorrect.

So, where does DNS and DNSSec fit into this?

Thanks,

-derek

Masataka Ohta <[email-masked]> writes:

> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 16 Jul 2002 15:45:40 +0859 ()

Derek;

> No, it is not sufficient.  The problem is that you cannot have a
> long-term store-and-forward mechanism with secret-key technology.  If
> Alice wants to send a secure message to Bob using secret-key
> encryption there is no way that Bob can prove to Charlie that Alice
> sent the message without revealing their own secret key.

I do assume all the related parties are online.

> Negative.  You want a key between A and D in order to maintain
> confidentiality of the transaction.

As you said;

> I admit that I did not count ephemeral keys in the count,

it's OK to have dynamically generated keys between A and D.

> No, it is not sufficient.  The problem is that you cannot have a
> long-term store-and-forward mechanism with secret-key technology.

I'm saying we shouldn't use long-term store-and-forward mechanism,
because it is not really secure.

> Moreover,
> in electronic transactions the customer may want to have a GOOD IDEA
> that they are talking to the "right" merchant (or at least the _same_
> merchant that they were talking to yesterday).  The only way to do
> this in a scalable way is Certificates.

That is a delusion.

> As much as I would love to seee Kerberos take over the world, it is
> not going to do so.  Moreover, with data like DNS, you cannot use
> Kerberos because of the caching problem (see my previous statement
> about store-and-forward data not working with secret key).

Kerberos with KDCs as the trusted third parties is as bad as PKI.

> It adds confidentiality of your payment token, and it provides
> a binding between the payment token and the paid-for object.

If you make a transaction confidential to the banks, banks can
not assist you to make it secure.

						Masataka Ohta

---

From: Derek Atkins <[email-masked]>
Date: 16 Jul 2002 02:42:20 -0400

> regardless of whether you use public or shared key cryptography.

I admit that I did not count ephemeral keys in the count, but that's
because they ARE ephemeral.  There is no _storage_ of those keys in
the system.  They are created (and destroyed) in near-real-time.  My
key-count is for long-term key storage, in which case my numbers are
accurate.

> N-squared keys regardless of whether you use public or shared key

You do not need to _store_ N-squared keys, you only need to store N
keys (one key per entity.  Yes, you need to store state during the
transaction processing (which may include an ephemeral session key)
but then you throw that key away when the transaction is complete.

No, it is not sufficient.  The problem is that you cannot have a
long-term store-and-forward mechanism with secret-key technology.  If
Alice wants to send a secure message to Bob using secret-key
encryption there is no way that Bob can prove to Charlie that Alice
sent the message without revealing their own secret key.  In other
words, you cannot have non-repudiation with secret-key protocols, but
this feature is ABSOLUTELY necessary for financial transactions.  If
Alice can repudiate their message to Bob, then how is Bob supposed to
collect his money?

Negative.  You want a key between A and D in order to maintain
confidentiality of the transaction.  Moreover, you may need to tie the
transaction to some other data (for example, I want to buy a widget
for this e-money), which implies you need a secure channel to bind the
widget to the payment.  Again, you need a key shared between A and D.

> It is also pobbible to let banks act as KDCs.

This does not work, as I previously stated.  The way the transaction
works is that A sends a token to B; B presents the token to D; D
presents the token back to C.  You cannot do that with secret-key
tokens.  If A, B, C, and D are all online together, there are
alternate protocols you can use, but it violates this particular
transaction model (which is how the current banking system is
implemented).

> between credit card owners and credit card companies.

You seem to be under the mistaken impression that credit cards are the
only financial model in use.  They are not.  Cash uses a very
different "protocol", some of which may be pseudo-offline.  Moreover,
in electronic transactions the customer may want to have a GOOD IDEA
that they are talking to the "right" merchant (or at least the _same_
merchant that they were talking to yesterday).  The only way to do
this in a scalable way is Certificates.

> and how wrongly various implementations tried to prevent it.

Sure.  Find me after DNSEXT.  I can show you that no matter what you
do, without cryptographic protection there is nothing you can do to
prevent me from poisioning your cache if I can get between you and the
DNS server you are querying.

> That is an uninteresting topic. Let's skip it.

It may be uninteresting to you, but not to many people sitting in this
room.  Skipping a topic just because you find it uninteresting is
the wrong answer.  Feel free to leave the room if you are bored.
Being here _is_ optional.

-derek

---

From: Brad Knowles <[email-masked]>
Date: Tue, 16 Jul 2002 17:10:56 +0200

At 3:50 PM +1000 2002/07/16, [email-masked] wrote:

>                                       Getting DNSSEC working

	Which is hard enough.  Witness all the incredibly screwed up TLD 
servers.  Witness the differences in the modes of operations of the 
root nameservers themselves -- do you block all zone transfers or not?

	If we want DNSSEC to be taken seriously, then we have to work to 
get all the root & TLD servers fixed and operating properly, and have 
proper punitive measures that we can take if they aren't.  Otherwise, 
we don't have a snowball's chance.

-- 
Brad Knowles, <[email-masked]>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

---

From: Brad Knowles <[email-masked]>
Date: Tue, 16 Jul 2002 17:07:47 +0200

>  (including DNSSEC) is not used for serious purposes.

	Not used for serious purposes?!?  Okay, let's have you run a B2B 
website where billions of dollars can be moved with the click of a 
single mouse button.  Now, we have to ensure that you really are 
interacting with the real B2B website and not some clever fake, or 
worse, some site that performs a man-in-the-middle attack on you 
while you are conducting a real transaction, so that they can later 
go in and conduct multiple fake transactions.

	How about home banking?  Sure, hundreds, thousands, tens of 
thousands, etc... of dollars may not be a whole lot of money to you, 
but they may be the entire life savings of a family.  Multiply that 
by 250 million people in the US alone, and you're talking about some 
real money.

	I'm sorry.  I don't buy your argument at all.  Not in the least.

	I'm not saying that DNSSEC is necessarily the only solution to 
the problem, or even the best solution to the problem, or necessarily 
even one solution to the problem, but it is at least a step closer to 
one solution to the problem, and by working with DNSSEC and seeing 
where it works and where it fails, we can get closer to a real 
solution.

>  really responsible if your transactions are spoofed.

	Okay, so we can all sue you for billions and trillions of dollars 
worth of damages when someone spoofs a DNS response packet which then 
leads us to be vulnerable to man-in-the-middle attacks.

>  can rely on people operating routers.

	No, in both cases.  There are a multitude of heinously screwed up 
servers in this world, and a multitude of heinously screwed up 
routers, too.

	If you don't believe me, then believe KC Claffy from CAIDA (see 
<http://www.caida.org/outreach/presentations/dns0701/mgp00003.html>).

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 17 Jul 2002 10:30:58 +0859 ()

Brad;

> 	Not used for serious purposes?!?

No, not at all.

> Okay, let's have you run a B2B 

Are you saying that the B2B website gladly accept a billion dollar
order from some unkown company just because a CA says the company's
domain name is not faked?

Purely techinically, if secret is shared between the website and the
company, shared key cryptography protect you from a clever fake and a
MITM attack.

But, it is not enough credential to perform serious commercial
transaction. The website should check credit status of its
members.

> by 250 million people in the US alone, and you're talking about some 

Protection for home banking is by shared secret.

> leads us to be vulnerable to man-in-the-middle attacks.

Huh?

You can't ask root server operators for compasation for billions
and trillions of dollars worth of damages when someone spoofs a DNS
response.

Serious users protect them with shared secret. They don't blank-mindedly
rely on CAs not really offerring any serious compasation.

> servers in this world, and a multitude of heinously screwed up 

And, there will be multiple screwed up CAs. Or, are there already?

So, have weakly secure Internet and DNS as a infrastructure and don't
rely on intermediate entities of servers, routers or CAs.

							Masataka Ohta

---

From: Brad Knowles <[email-masked]>
Date: Wed, 17 Jul 2002 12:22:59 +0200

>  domain name is not faked?

	Man-in-the-middle attack.  All data that flows from point A to 
point B (or vice-versa) is legitimate.  It just happens to be 
secretly routed through point C, whereby all traffic is sniffed, all 
passwords are captured, etc... so that this information can be used 
in the future to forge a real transaction.

>  company, shared key cryptography protect you from a clever fake and a

	This assumes perfect implementation of the cryptography and the 
manner in which cryptography is used (and the whole rest of the 
system).  Schneier teaches us that this is a highly unlikely 
situation to occur anywhere.

>  transaction. The website should check credit status of its

	As far as the site is concerned, the account is valid, the 
password is valid, what more do you want?  Heck, they can even 
confirm that at least one valid transaction in the past came from the 
same source (which the client can confirm), because there had to be 
at least one full transaction that passed through the MITM.

>  Protection for home banking is by shared secret.

	Yes, you use shared secrets when you log in with your account & 
password, but the client still needs to be certain that when he asks 
to go to www.insertyourbankhere.com (or uses the custom home banking 
software), that this really does take them to the appropriate site in 
question and that cache poisoning attacks cannot cause this access to 
be directed to a different site that might then do a MITM attack.

>  and trillions of dollars worth of damages when someone spoofs a DNS

	No, but I can hold up your name as the person who stood in the 
way of implementing DNSSEC and DS, and therefore you would be at 
least partially to blame for security breaches that occur anywhere in 
the world that might have been preventable with DNSSEC and/or DS.

>  rely on CAs not really offerring any serious compasation.

	No.  If you want serious protection, you use a one-time pad, and 
you make damn sure it never gets used again.  Moreover, you make damn 
sure that no one ever figures out who is "randomly" typing your 
one-time pad so that they can calculate the probability of what 
characters will be typed, and use that to help them break the message.

	Since compromise of a shared secret leads to compromise of both 
ends (or could have been the responsibility of either end), PKC is 
much preferable for everyone involved.  Or, use both shared secrets 
and PKC, to help you solve different parts of the problem.

	Note that PKC doesn't necessarily depend on any CA structure or 
any other PKI structure.  That's just the implementation detail you 
are imposing as a straw man, which you can then knock down and claim 
to prove the PKC is inherently unsuitable.

	We've seen this method of argument before, and we know how to deal with it.

>  And, there will be multiple screwed up CAs. Or, are there already?

	So there are multiple screwed-up CAs.  DNSSEC and DS will be an 
improvement over what we've got now, and we will have a smaller set 
of problems to deal with once they are in wide use.

>  rely on intermediate entities of servers, routers or CAs.

	Which is what we have now.  Shall I now go pollute the cache of 
dns0.spin.ad.jp, and direct all traffic for titech.ac.jp over to some 
bukake site?

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 18 Jul 2002 00:15:15 +0859 ()

Brad;

> in the future to forge a real transaction.

Shared key cryptography can be a protection from the MITM attack.

If you think plain text passwords can be on the wire, you haven't
seriously considered requirements for commercial transactions.

> situation to occur anywhere.

I'm teching you Schneier (whoever he is) is wrong, then.

> at least one full transaction that passed through the MITM.

I'm saying that the site and its customer must establish
credential relationship.

If a bank reliably says that a company has large amount of
cash, the company is reliable.

> be directed to a different site that might then do a MITM attack.

Then, you are blindly belive CAs are secure.

Even if they were, the reality is that most clients never checks
whether the transaction use https or http.

So, it is stupid to send plain text password with https.

>root nameservers themselves -- do you block all zone transfers or not?

you can't identify the person to be blamed for.

Even if you can, have you ever checked standard contract of CAs? How
much is the upper limit of compensation for failed transaction?

> you make damn sure it never gets used again.

Have you ever heard about things called CHAP?

You don't have to send your password in plain text over the wire.

> of problems to deal with once they are in wide use.

The more complex protocol, the larger set of problems.

> 	Which is what we have now.

Exactly. The real world is not using CAs.

							Masataka Ohta

---

From: Brad Knowles <[email-masked]>
Date: Wed, 17 Jul 2002 19:53:39 +0200

>  Shared key cryptography can be a protection from the MITM attack.

	They are subject to replay attacks.

>  I'm teching you Schneier (whoever he is) is wrong, then.

	If you're talking about cryptography or computer security and you 
don't know who Schneier is, then you don't know anything useful about 
cryptography or computer security.

	Go buy _Applied Cryptography: Protocols, Algorithms, and Source 
Code in C_, _Secrets and Lies: Digital Security in a Networked 
World_, _The Electronic Privacy Papers: Documents on the Battle for 
Privacy in the Age of Surveillance_, and _The Twofish Encryption 
Algorithm: A 128-Bit Block Cipher_, and then come back when you're 
done reading them.

>  Then, you are blindly belive CAs are secure.

	No.  They are one part of the overall security scheme.

>  whether the transaction use https or http.

	This has nothing to do with https or http.  What this does have 
to do with is ensuring that the IP address you send your https or 
http stream to is actually the server you want, and not some other 
site that has managed to poison the cache of your nameservers and 
trick you into routing your packets to them, which they then forward 
to the real site, and vice-versa.

>  you can't identify the person to be blamed for.

	If the servers hand out incorrect data because their cache has 
been poisoned, you are right that it is difficult to point the finger 
at any one person or organization, or group of people or 
organizations.

	If the servers hand out incorrect data because their cache has 
been poisoned, and the reason their cache is *capable* of being 
poisoned is because one moron stood up and convinced everyone that 
implementing a technology to help prevent this problem was a bad 
idea, then the finger can most definitely be pointed at that one 
moron.

>  much is the upper limit of compensation for failed transaction?

	Who needs civil law?  Go after them as they did with Eugene 
Kashpureff, and put the sucker in jail!

>  Have you ever heard about things called CHAP?

	There is nothing in the field of cryptography that can begin to 
compare with a properly implemented one-time pad.  This is a known 
fact.

	If you want to talk about algorithms that might be "good enough", 
that's a whole different matter.

>  You don't have to send your password in plain text over the wire.

	Of course not!  You can encrypt it!

	But how can you really be sure that you're sending the encrypted 
password to the right server?  A shared secret doesn't work, because 
that is subject to replay attacks.  You really want something more 
robust than that, such as provided by PKC.

>  The more complex protocol, the larger set of problems.

	No, because we will have exchanged the larger problem of 
unauthenticated IP addresses for the smaller one of making sure that 
the CAs are properly operating.  Moreover, we probably won't be using 
the same CAs as are used today with https, and even if we are, they 
have a much simpler problem to solve.

>  Exactly. The real world is not using CAs.

	Riiiiiiiiiiiiiiiiight.  What rock have you been sleeping under?

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 21 Jul 2002 05:05:41 +0859 ()

Brad;

> 	They are subject to replay attacks.

PAP is, CHAP is not.

> cryptography or computer security.

See above.

:-)

You should really read text books.

In addition, you should know that cache poisoning of DNS is
prevented simply by having separate cache for each referral
point, which has nothing to do with cryptography but can be
understood with basic knowledge on computer security.

> Kashpureff, and put the sucker in jail!

It is clearly stated in their contract that operators of CAs won't
compensate much.

It is obvious that people here who operate root and tld servers
won't compensate much.

We can not be responsible for the stupidity of someone who use
DNSSEC to secure billion dollar transactions.

Civil laws will treat those who think they secured billion
dollar transactions, simply because they pay $100 treat
accordingly.

							Masataka Ohta

---

From: Brad Knowles <[email-masked]>
Date: Sat, 20 Jul 2002 22:42:12 +0200

>>  	They are subject to replay attacks.

	Authentication != encryption.  Moreover, as I said before, this 
is just one piece of the security puzzle, and using CHAP does not 
preclude using other technologies as well.

>  understood with basic knowledge on computer security.

	I believe that we could make nameservers much more resistant to 
cache-poisoning attacks simply be separating authoritative service 
from caching service, either by putting them on separate machines, or 
running them in separate instances of the nameserver software.  I 
believe that we should work towards this goal.

	Yes, you could use PKC to help solve the cache poisoning problem, 
but there are other methods you can also pursue, and I do not believe 
that pursuing one method necessarily precludes also using other 
methods.

	However, using PKC allows us to do a lot more things than we 
could think of doing before, because we would now have externally 
provable non-repudiation, among other things.  For example, we could 
use PKC at the DNS level to help us reliably implement a PKI on top 
of the DNS, which might be useable for things other than the DNS 
itself.

>  DNSSEC to secure billion dollar transactions.

	They would not be using DNSSEC as their sole method of securing 
the transactions.  However, without DNSSEC there is a critical piece 
of the puzzle that they are unable to secure by themselves, thus 
leaving themselves more vulnerable.  People in this situation need 
help in securing this part of the picture, and so far the only method 
that looks even potentially suitable is DNSSEC.

	This is the cornerstone of all future business on the Internet. 
It is a critical component to the security of the entire Internet, 
one that might let us get one more step away from the reality painted 
by KC Claffy at 
<http://www.caida.org/outreach/presentations/dns0701/mgp00003.html>.

	Why are you so violently opposed to progress?