Subject: RE: Interim signing of the root zone.

From: "Loomis, Rip" <[email-masked]>
Date: Thu, 10 Oct 2002 22:30:32 -0400

> > as dnssec is finally approaching deployment, it seems
> > imprudent to rush into a not obviously critical anycast
> > deployment when a little patience would seem harmless.

> DNSSEC, or any CA-based security, is not really secure and is
> undeployable for any practical security.

With all due respect, you've made such claims/statements on
the list before, and never provided sufficient fact to back
up that opinion.  Please feel free to back up that opinion
with fact, or don't waste peoples' time with it.  Better yet,
if you think things are slightly broken then propose a fix.
If you think things are *very* broken then propose a workable
alternative and explain why things are so broken.

Describing DNSSEC as "CA-based security" is starting off
on the complete wrong tack as far as I'm concerned--there are
real and significant diffences between the distributed
zone-based signing scheme of DNSSEC signed zones (on the one
hand) and monolithic PKI based on CAs (on the other).

I look forward to constructive comments. or a more clear
explanation of your claims.  In the meantime, I'm going back
to deploying DNSSEC for practical security.

  --Rip
#----------------------------------------------------------------------
# To unsubscripbe, send a message to <[email-masked]>.

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 15 Oct 2002 13:29:35 +0859 ()

Rip

> the list before,

And the only counter argument was:

	My teacher taught me differently, I think.

> Please feel free to back up that opinion
> with fact, or don't waste peoples' time with it.

If security is compromized, who pays how much?

Have you ever checked the reality of terms and conditions of CAs?

> Better yet,

The current DNS is working well with weak security replying on
ISPs.

Those who need additional security should share a secret end to end
without introducing intellignet intermediate entities of CAs.

So, I don't think I have to propose a workable alternative.

Nonetheless, I proposed anycast root, which improves security against
spoofed route.

On the other hand, DNSSEC is unworkable as evidenced by the failed
deployment attempt for so many years.

Observing the failure, I gave an explanation why it is hopeless.

							Masataka Ohta

---

From: "John M. Brown" <[email-masked]>
Date: Mon, 14 Oct 2002 23:57:00 -0600

anycast root opens the root system up to more capture,
even if its localized capture, its still capture.

Who decides on who can "anycast" the zone and how do
we know its the right zone ?

signing the root, by whatever means is decided upon, helps
assure that the data is in fact "the original stuff".

If the country of Futuro (make believe) decides to run its
own "root" via an anycast system, and they change the
NS RR set for .JP, how are users going to know that?

maybe I'm just naive.....

john brown

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Masataka Ohta
> Sent: Monday, October 14, 2002 10:31 PM
> To: Loomis, Rip
> Cc: [email-masked]'
> Subject: Re: Interim signing of the root zone.
> 
> 
> Rip
> 
> imprudent to 
> > > > rush into a not obviously critical anycast deployment when a 
> > > > little patience would seem harmless.
> > 
> the list 
> > before,
> > if you think things are slightly broken then propose a fix. If you 
> > think things are *very* broken then propose a workable 
> alternative and 
> The current DNS is working well with weak security replying on ISPs.
> 
> Those who need additional security should share a secret end 
> to end without introducing intellignet intermediate entities of CAs.
> 
> Nonetheless, I proposed anycast root, which improves security 
> against spoofed route.
> 
> On the other hand, DNSSEC is unworkable as evidenced by the 
> failed deployment attempt for so many years.
>

---

From: Markus Stumpf <[email-masked]>
Date: Tue, 15 Oct 2002 12:21:28 +0200

> assure that the data is in fact "the original stuff".

With CAs like VeriSign issuing wrong certificates for Microsoft.
    http://www.pkiforum.com/resources/verisigncerts.html
Did this company get punished hard? Are their certificates less trusted
in the community? Do you still believe ceritifcates issued by VeriSign?
Do you believe data signed with a VeriSign cert is the "original stuff"?
Why? There is evidence they issue wrong certs. One issue has become
famous. How many are there we dont know about?

> NS RR set for .JP, how are users going to know that?

And if the country of Futuro also installs a firewall to filter and spy
IP connections does it make any difference to their residents?
And is changing the NS RR set for .JP an evidence that they are
doing something evil? Maybe they are running secondaries of the JP zone
and changed it to optimize their DNS infrastructure?

What Masataka Ohta IMHO tries to say is that it is at best nice to
have a signed root zone, but you will not gain /any/ increase in security.
And one reason is that if the security is compromised the network
police will not read you your rights and drag you away. It will work
fine, as long as it works. If it fails it fails. Nothing else.

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"
#----------------------------------------------------------------------
# To unsubscripbe, send a message to <[email-masked]>.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 15 Oct 2002 10:07:18 -0400

At 12:21 +0200 10/15/02, Markus Stumpf wrote:
>..................Do you still believe ceritifcates issued by VeriSign?
>Why?

Empirically, each and every time I have ordered something, it has 
arrived at my location, intact, and with the correct amount charged 
to my account.

>There is evidence they issue wrong certs. One issue has become

Sigh, *is* there evidence that Verisign issues (present tense) wrong 
certs or do you mean that there is evidence that Verisign once issued 
(past tense) a wrong cert?   Making a mistake once is inevitable. 
Learning not to do it again and avoiding a second incident builds 
character.

Note too that with CRL's, the incident above was easily rectified - 
in applications that fully implemented X.509 processing.

>have a signed root zone, but you will not gain /any/ increase in security.

The goal of security is to limit the damage of an (unauthorized) 
action. (With "damage" being inherently "bad stuff.")  Significant 
subgoals of security are to lower the chance (probability) that an 
unauthorized action will have any impact, limiting the impact to a 
small set of assets, and limiting the duration of the impact.

Signing the root zone means that not only will the attacker need to 
convince resolvers that it is the true source of the root, but the 
attacker will also need to be able to forge the signatures.  Forging 
can be done, but that it is yet another steps to be mastered, there 
is an even lower likelyhood of success.
(The more times the attacker fails, the more chance the attacker has 
at getting caught before perfecting the attack.)

(Signing the root zone does not limit damage to a small set of assets 
on its own.)

As far as the third subgoal, the next comment you make comes into play.

>fine, as long as it works. If it fails it fails. Nothing else.

There are no network police, but there are existing legal 
jurisdictions.  When someone breaches network security, the impact is 
on real property.  So, when performing a post mortem on an attack, it 
is important to be able to provide data/information to the 
appropriate legal jurisdictions describing the incident.  If the 
attacker has been able to "have the key" then that is one more step 
towards pinning the blame for an attack on someone.  (So long as 
proper rules regarding evidence are followed.)  My point here is - if 
the attacker is thrown in jail, the attack will stop by then.  (I 
could go into jail as a deterrent too.)

So, I see that signing the root benefits "security" in that it 
requires forgery to be added to the attackers arsenal and requires 
the attacker to hold on to something that may be used against them in 
a court of law.

PS - the roots can limit damage through a key change and proper 
dissemination of this.  This is a rougher thing to accomplish and the 
attacker might get away with things for a while, but it is a help.

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

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 16 Oct 2002 00:04:48 +0859 ()

Edward Lewis;

> in applications that fully implemented X.509 processing.

Unfortunately for you, CRL is another example on why CA-based security
is useless.

Namely, there is no proper period to check CRL.

CAs, the intelligent intermediate systems having no knowledge on the
requirement of applications, set the period, which is inappropriate
for most applications.

> small set of assets, and limiting the duration of the impact.

That's why shared key cryptography, which limits the impact of
compromized security to the small set, members of which are directly
involved in the action, is the way to go.

On the other hand, the impact of compromized CAs or compromized
employees of CAs is unlimited.

> at getting caught before perfecting the attack.)

It's much easier and secure to prevent forged route to the current
UNICAST root servers and to catch the attacker.

> jurisdictions.

Existing legal jurisdictions is powerful enough to discourage
forged route to the current UNICAST root servers.

> My point here is - if 
> the attacker is thrown in jail, the attack will stop by then.

Exactly.

> attacker might get away with things for a while, but it is a help.

Certainly.

If the attack occurs 1,000 times a second and the roots act within an
hour, the damage can be limited below that of 3,600,000 transactions,
each of which may worth zillions of dollars.

That's why real world credit card companies requires realtime
verification of credit status.

							Masataka Ohta

---

From: Edward Lewis <[email-masked]>
Date: Tue, 15 Oct 2002 11:46:01 -0400

Perhaps the issue here is the expectation of "security."

>UNICAST root servers and to catch the attacker.

Designing a defense to prevent an attack is not wise.  Designing a 
defense to handle the occurrence of an attack is much better.

>verification of credit status.

This isn't exactly true.  The verification by a vendor of the card 
holder's status is for the benefit of the vendor (too).  When a card 
holder receives a bill, the holder has the opportunity to dispute a 
charge.  If the holder is justified, the vendor does not get paid, it 
is the vendor who suffers the loss.  Now, the vendor may be insured 
against this kind of loss, if so, is required to file a police report 
- so now we've involved law enforcement and the insurance industry 
too.

This isn't DNSOP-worthy material on the surface.  But it's an example 
of how multi-dimensional security is.  At the time of the transaction 
some steps are taken.  But as problems escalate, more and more 
back-end activity happens with the power to "restore order."  (We 
bump serious protocol errors up the stack.)

Signing the root zone won't stop someone from attacking DNS, much as 
there are still murders in society in which murder is illegal.  If 
society can't prevent murder, engineers can't prevent attacks on DNS 
- but at least accountants can recover financial losses.  I'm urging 
a more realistic view of what is being accomplished in signing the 
root zone.  We're not stopping anything, we are simply making it 
harder and less damaging (esp. in the long term) when an attack 
happens.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Markus Stumpf <[email-masked]>
Date: Tue, 15 Oct 2002 18:17:21 +0200

> Learning not to do it again and avoiding a second incident builds 

Do you know if they don't do it every month with "small unimportant"
incidents that no reporter finds worth writing an article? That we
don't know about it doesn't mean that there is none. Maybe nobody
is trying it hard enough/at all, currently.

> in applications that fully implemented X.509 processing.

Applications doing that correctly I still have to see.

> at getting caught before perfecting the attack.)

Naaaa ... come on, it's not the late 80's. I am sure we all know and we
all fear the power of distributed attacks and that there is no real
method currently to make them stop (other than pull the plug of course,
which is /not/ a considerable solution in this case. There's so many open
servers that - if the attackers like - they can carry on an attack for
days/weeks throughout the whole Internet.
What we have seen so far are kids playing around. What do you think will
happen, if someone/a group with a plan, enough theoretical/practical
background and enough money /really/ wants to cause harm? And: I mean
harm just for the purpose of causing harm.

> There are no network police, but there are existing legal 

Where? Think global. There are many countries around the world and they all
have different laws. Some even don't have laws for computer fraud at all.
And: if someone writes such a worm and injects it via public internet
access points (e.g. internet cafes) how do you think you will ever be
able to trace her/him back? Make a holiday trip to Bangkok, there's
public internet at every corner. The PC are usually well equipped, CD
drives and all. Spend some bucks and have fun.

> the attacker is thrown in jail, the attack will stop by then.

Wrong again. Think CodeRed, think Nimda.
Do you think the attacks will stop, just because the originator of the
virus is thrown to jail (if at all possible with local jurisdiction)?

	\Maex

---

From: Brad Knowles <[email-masked]>
Date: Tue, 15 Oct 2002 23:34:02 +0200

>  involved in the action, is the way to go.

	Regardless of the encryption method, you still need a key 
infrastructure.  Shared-key is proven to be "secure" as an inverse 
power of the number of people who have the key.  This simply is not 
practical on a large-scale public network.  Like it or not, 
public-key is the only choice we have.

>  employees of CAs is unlimited.

	Yup.

	The US Gov't has this problem, too.  They have devices called 
"STUs", which stands for Secure Telephone Unit (last I saw, they were 
up to STU-III).  The STUs can be manufactured in many facilities 
around the world (including Norway), but once an encryption key has 
been applied to them, they become export restricted and cannot be 
returned for repairs to most of the facilities where they were 
manufactured.

	These keys are coordinated through a Key Distribution Center. 
The Russians (and others) have shown extreme interest in compromising 
the KDC, and they have been known to be successful on at least one 
occasion in the past.  One good compromise of the KDC (or any other 
kind of CA), and you can have access to hundreds, thousands, 
millions, or possibly even billions of keys.  With these kinds of 
stakes, people are literally willing to risk their lives, because the 
consequence of getting caught is to be prosecuted for High Treason.

	A sufficiently motivated attacker can break any security anywhere.

	CRLs and PKI are hard.  I would like to see you wave a magic wand 
and come up with a real solution for the problem.  I don't see "web 
of trust" doing us much good here.

-- 
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.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w---
O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
#----------------------------------------------------------------------
# To unsubscripbe, send a message to <[email-masked]>.

---

From: David Conrad <[email-masked]>
Date: Tue, 15 Oct 2002 17:54:30 -0700

John,

From an external perspective, how is a properly implemented anycast root any
different than a unicast root advertised via a large network with multiple
peers?  In fact, the case documented in Dan's NANOG 25 slides was (I
believe) "capture" of a unicast root.

Anycast is completely orthogonal to the decision of whether or not to sign
the root.  Signing the root should be done.  Johan's draft proposes a way to
do that.  Can we try to keep the discussion on issues (if any) in his draft?

Rgds,
-drc
--------

---

From: Edward Lewis <[email-masked]>
Date: Thu, 17 Oct 2002 18:23:49 -0400

>is trying it hard enough/at all, currently.

There's no point in debating this.  In the context of an engineering 
discussion, we can only make progress against evident, tangible 
problems.  Getting caught up in what "might" be happening, or what we 
"believe" might be happening, will just lead us into rat holes.

>Naaaa ... come on, it's not the late 80's. I am sure we all know and we

My above generalization doesn't just apply to the Internet.  The 
above principle is behind the reason nearly all serial murders are 
solved and bank robbing bands never get really rich.  This even 
applies to sports - offenses may change tactics, but eventually 
defenses adjust.

Security always starts from a position of weakness.  Security is 
initially reactionary until the pattern of attack is determined. 
Only then can security go on the offensive.  This is why a good 
security plan will not set out to prevent attacks, but rather manage 
the damage they initially cause.

Because attackers follow tendencies, security responses become more 
effective, and eventually the attacker is overwhelmed.  In many 
cases, first time attackers follow an already known pattern, so 
security responds correctly the first time.  Often times, getting 
caught once is enough to make a attacker less bold.

If that isn't convincing enough, there's the experience factor.  In 
any competitive situation, having more experience often outweighs 
luck and skill.  Attackers are rarely successful, hence don't gain 
much "good" experience.  Defenders often get to repel attack after 
attack - and do gain "good experience."  Not only that, the defenders 
see more angles of attack, which helps them anticipate new approaches.

>harm just for the purpose of causing harm.

What will happen?  Bad things, of course, given the conditions you 
describe.  But putting all those pieces together is awfully hard.  In 
that situation, prolonging your life is most effectively done by 
surrendering.  ('Course, "prolonging" may not be your choice of goal, 
especially if the captured are made slaves and have to build large 
pyramids.)  But remember that historically, no one has succeeded in 
"ruling the world."  It's just too hard, logistics will get you every 
time.  And, generally those with sanity and enough resources will not 
see the need to risk losing it all in an attack.

>drives and all. Spend some bucks and have fun.

I've been to Bangkok.  They have laws.  They do have jails.  Police 
officers are present all over the city.  The Department of 
Corrections building along the river has it's name spelled out in 
English - I assume to at least make sure visitors know it exists.

I am thinking global.  There are pockets in the world that are 
(perceived to be) light on law enforcement.  They are pressured 
politically to comply, if the lawlessness is rampant enough.  They 
are also economically sanctioned and sometimes even invaded.

>virus is thrown to jail (if at all possible with local jurisdiction)?

"Just because" - no, of course not.  But each time the originator is 
caught and punished, the appeal of attacking lessens.

I'm not sure if my answer is at all helpful.  The reason I am 
bothering is that sense a misunderstanding of what "security" is all 
about, and how signing the root zone helps us.  Signing the root 
won't stop someone from doing bad things, but it will make it that 
much harder to accomplish an attack and get away with it.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 23 Oct 2002 23:28:10 +0859 ()

Brad Knowles;

> infrastructure.

That is the fundamental misunderstanding on PKI or KI.

The real world does not need PKI.

People pay with credit card, not because of PKI, but because
credit card campanies give credentials to their customers.

> Shared-key is proven to be "secure" as an inverse 
> power of the number of people who have the key.

Huh?

Shared key cryptography with long and random enough keys is simply
secure regardless of the number of the users.

That's all.

> This simply is not 

Your argument should be that, public key cryptography is insecure
because it relies on the security of transactions of shared key
cryptography which is '"secure" as an inverse power of the numer of'
transactions which have the shared keys exchanged through PKI for 
so may transactions,

> of trust" doing us much good here.

Fortunately, in the real world, no one needs PKI.

Over the real world Internet, people are already paying on line with
credit cards, because credit card companies are giving credential to
their users through the direct relationships between the credit card
companies and the users.

The basic requirement is that the credit card companies reduce the amount
of remaining credential on the users on every transaction.

You can't use your credit card for your shopping, if the shop you are
paying for can not communicate with a credit card company to
authorize your credential information, for which PKI is useless.

That is, that PKI reduces the need for realtime communication is
just a fallacy.

Moreover, best effort communication over the Internet is basically
free that no one really want to reduce the need for the realtime
communication.

On the other hand, credit card companies or any other entities are
giving credential to their users through direct relationships between
the entities and the users. They can exchange and are already
exchanging shared keys through the direct relatiohships.

Nothing is different on (in)secure DNS that there is no point on
signing the root zone.

The real world does not need PKI nor secure DNS.

						Masataka Ohta

---

From: Brad Knowles <[email-masked]>
Date: Thu, 24 Oct 2002 02:28:31 +0200

>  credit card campanies give credentials to their customers.

	The credit card companies lose billions of dollars a year due to 
fraud.  They want more secure transactions than most anyone else in 
the world, and they are paying *BIG* bucks to make it happen.  And a 
KI or PKI is a critical part of that task.

	Are you willing to have your startup risk billions of dollars a 
year because you didn't secure the transactions, but you guarantee 
them anyway?

>  secure regardless of the number of the users.

	Shared keys that long and random can't be remembered by users, 
and there has to be some sort of KI to support them.

>  transactions which have the shared keys exchanged through PKI for

	Shared key transactions are a critical part of public key 
transactions.  The public key part is just enough to allow you to 
securely exchange shared session keys which then automatically go 
away.

	The problem is with persistent shared key cryptography.

>  Fortunately, in the real world, no one needs PKI.

	Maybe they think they don't.

>  their users through the direct relationships between the credit card

	How many users are willing to buy things over the net that aren't 
secured with SSL?  Well, any use of SSL is using public key 
cryptography, and needs a PKI.

	If you're willing to use credit cards without securing the 
transaction, then feel free to share your credit card numbers on this 
mailing list.

>  authorize your credential information, for which PKI is useless.

	How the hell do you think they authorize the card?!?

	Just what does the word "authorize" mean in your dictionary, anyway?!?

>  free that no one really want to reduce the need for the realtime

	Feel free to turn off all use of SSL, TLS, ssh, etc... on all 
your computers.

>  exchanging shared keys through the direct relatiohships.

	And how do you think those direct relationships are handled in 
the first place?!?

>  The real world does not need PKI nor secure DNS.

	Feel free to give us your social security number, your credit 
cards, and all your other personal data.

	If you're not willing to do that, then please share with us how 
you are going to secure any transaction that uses this kind of 
information.  Moreover, please explain how you are going to do that 
but *not* using SSL, TLS, ssh, or any other form of encryption.

---

From: "John M. Brown" <[email-masked]>
Date: Wed, 23 Oct 2002 19:13:41 -0600

I thought this thread is about an "Interm" method of signing
the root-zone.  

Not solving the credit card fraud issues, or world hunger.

If we can bring this back on topic and work towards the goal
of having a better system, even if it means taking baby steps
towards those goals, then this debate will have much more
meaning in the "recent" sense.

thank you

john brown
Le Geek

> Behalf Of Brad Knowles
> Sent: Wednesday, October 23, 2002 6:29 PM
> To: Masataka Ohta
> Cc: Brad Knowles; Edward Lewis; Markus Stumpf; [email-masked]
> >  People pay with credit card, not because of PKI, but 
> because  credit 
> > card campanies give credentials to their customers.
> 
> > transactions which have the shared keys exchanged through 
> PKI for  so 
> > may transactions,
> 
> "They that can give up essential liberty to obtain a little 
> temporary safety deserve neither liberty nor safety."
> tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* 
> tv+z(+++)

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 24 Oct 2002 11:06:25 +0859 ()

Brad Knowles;

> the world, and they are paying *BIG* bucks to make it happen.

Correct, so far.

> And a KI or PKI is a critical part of that task.

Credit card users and credit card companies, the first and the second
parties, already share 4 digit numbers to secure some transaction.

That is the KI.

Trusted third parties does not imporove the situation at all.

> year because you didn't secure the transactions, but you guarantee 

Credit card companies take the risk.

Trusted third parties do not.

Root server operators do not.

> and there has to be some sort of KI to support them.

Secure enough shared key is much shorter than public keys with
untrustworthy strength.

> 	The problem is with persistent shared key cryptography.

Shared keys are just enough to allow you to securely exchange shared
session keys which then automatically go away.

There is no problem from the beginning.

> secured with SSL?

All.

It is merely that credit companies, not users, wrongly believe that
the Internet is less secure than phone network.

The reality is that local ISPs and local exchange carriers are equally
(un)trustworthy.

> Well, any use of SSL is using public key 

And, it does not secure the identity of credit card users.

> transaction, then feel free to share your credit card numbers on this 

Instead, give me packet dump of your credit card transaction
secured by a shared key exchanged with public keys.

Then, after the transaction finishes, tell me the shared key.

> 	How the hell do you think they authorize the card?!?

Over phone, fax or the Internet.

> 	And how do you think those direct relationships are handled in 

By creating a bank account, for example.

> cards, and all your other personal data.

Hugh?

I don't have any social security number.

However, I give my credit card number and other personal data to my
local ISP.

It does not mean that a public mailing list protect my privacy
information as well as ISPs.

> but *not* using SSL, TLS, ssh, or any other form of encryption.

Instead, please recognize how we are securing such transactions over
phone or fax.

Are you using SSL with fax?

						Masataka Ohta