Subject: dnssec discussion today at noon

From: Edward Lewis <[email-masked]>
Date: Mon, 15 Jul 2002 20:32:59 -0400

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.

The gathering is in room 415, from noon until 1 today (Tuesday of the IETF).
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

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

---

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

> where DNSSEC is (now that we see implementations of the DS record) 

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

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

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

So,

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

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

							Masataka Ohta

---

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

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

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?

> necessary between A and C, C and D, D and B, but not A and D.

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.

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

> Weak protection by HTTPS does not essentially add anything.

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

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

> 							Masataka Ohta

-derek

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

> sent the message without revealing their own secret key.

I do assume all the related parties are online.

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

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

That is a delusion.

> about store-and-forward data not working with secret key).

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

> 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: Brad Knowles <[email-masked]>
Date: Tue, 16 Jul 2002 17:10:56 +0200

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

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

>                                       Getting DNSSEC working
>  	only requires that the operators of the root servers, down
>  	to the zone servers do the right thing.

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

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.

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

Protection for home banking is by shared secret.

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

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.

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

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: Masataka Ohta <[email-masked]>
Date: Thu, 18 Jul 2002 00:15:15 +0859 ()

Brad;

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

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.

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

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

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

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.

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

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.

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

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

> 	No.  If you want serious protection, you use a one-time pad, and 
> 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.

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

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

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

See above.

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

:-)

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.

> 	Who needs civil law?  Go after them as they did with Eugene 
> 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: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 22 Jul 2002 10:14:46 -0700

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

I am not too sure that Bruce made quite the point originally stated,
and if he did make it one should take a look at some other statements
Bruce has been known to state before necessarily taking his word as
gospel.

In fact I would suspect that a more accurate representation of
Bruce's position would be 'think about the protocol, don't depend
on dogma, including dogma that you might find attributed to me.'

		Phill

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 22 Jul 2002 10:32:39 -0700

> store-and-forward protocol.

I disagree with your characterization. I don't think that we
need to state that public key cryptography is essential in 
this particular instance (authenticating the actual DNS records),
however it is certainly going to be helpful as a part of the 
solution.

First off, let us consider the nature of actual DNS deployments,
OK so you can have services chained of services off services
etc. But is this a typical deployment, a necessary deployment?

More importantly, examine those deployments and ask yourself 
where the trust boundaries are situated. If I relay a request
through DNS server X then I probably do so because I trust
that service in some sense. If I don't trust the service I 
am going to bypass it and chain directly to authoritative 
services that I do trust.

While transitive authentication is a nice feature of digital
signatures I do not see that feature as being essential in this
particular case.

I think that a situation in which a client has a secure 
connection to a DNS server which has a secure connection to
certain often used DNS servers is a significant step forward
in security from where we are.

I certainly think that we are going to need public key 
cryptography to establish the framework of trust between the
endpoints. But that does not mean that the current DNS 
architecture with a signature for every record is the only 
solution. We could use Kerberos with PK_INIT or some other
key agreement protocol to establish the trust relationships 
from public keys.

		Phill

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 22 Jul 2002 13:22:06 -0700

> You have clearly never been to an hotel where their Internet services
> intercept all DNS queries regardless of where you send the message...
> You cannot trust the infrastructure not to misbehave.  

Answer, I tend not to pay $10 per night just to surf the Internet
from a hotel room and when I have I have been using a VPN which 
encrypts all the trafic.

Question, what do you want the infrastructure to do in this 
situation? I believe that what a secure DNS infrastructure should
do is inform you that you are subject to a DNS MiM attack.

If you are going to use secure DNS then you probably want to 
use IPSEC to protect you trafic from hotel rooms and the like.
If the institution blocks IPSEC then you should probably apply
Moscow rules and not use the Internet at all.

		Phill