Subject: Re: dnssec discussion today at noon

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.

At 10:48 AM +0900 7/16/02, Masataka Ohta wrote:
>>  > 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.
>>  :-)
>
>To stimulate (or cool down?) the discussion, here is a theory on
>why DNSSEC (or public key cryptography as a whole) is unimportant.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: [email-masked]
Date: Tue, 16 Jul 2002 13:29:38 +1000

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

	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: Derek Atkins <[email-masked]>
Date: 16 Jul 2002 01:43:47 -0400

Unfortunately you are incorrect.

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

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.

So, where does DNS and DNSSec fit into this?

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.

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.

Thanks,

-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