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: Rob Austein <[email-masked]>
Date: Tue, 16 Jul 2002 10:44:03 +0900

With apologies for the extreme last minute nature of this (we miss
you, Olafur :), here's the agenda and doc list for this afternoon's
DNSEXT WG meeting.

* $Date: 2002/07/16 01:32:18 $

. * Agenda
.  + Hello
.  + Procure scribe
.  + Bash agenda
.  + Status of WG documents
.  + Interoperability reports
.  + WG document discussion (see doc list)
.  + Other documents
.  + Any other business
.  + Bye

. * Interoperability reports
.  + RFC 1886 interop test
.  + DS interop test
.  + Plea from chairs for more interop test reports

. * Document list
.  + Published as RFC or in RFC Editor queue
.   - draft-ietf-dnsext-ipv6-addresses-02.txt
.   - draft-ietf-dnsext-dnsmib-historical-00.txt
.   - draft-ietf-dnsext-ipv6-dns-tradeoffs-02.txt
.   - draft-ietf-dnsext-gss-tsig-05.txt
.   - draft-ietf-dnsext-message-size-04.txt
.  + In IETF last call
.   - draft-ietf-dnsext-restrict-key-for-dnssec-03.txt
.   - draft-ietf-dnsext-delegation-signer-08.txt
.  + Back in WG's lap
.   - draft-ietf-dnsext-ad-is-secure-06.txt
.   - draft-ietf-dnsext-dnssec-roadmap-05.txt
.  + Ready for WG last call?
.   - draft-ietf-dnsext-dnssec-records-01.txt
.   - draft-ietf-dnsext-unknown-rrs-03.txt
.   - draft-ietf-dnsext-dnssec-intro-01.txt
.   - draft-ietf-dnsext-rfc2536bis-dsa-01.txt
.   - draft-ietf-dnsext-rfc2539bis-dhk-01.txt
.   - draft-ietf-dnsext-mdns-10.txt
.  + WG not finished yet
.   - draft-ietf-dnsext-axfr-clarify-04.txt
.   - draft-ietf-dnsext-dnssec-opt-in-02.txt
.   - draft-ietf-dnsext-obsolete-iquery-03.txt
.   - draft-ietf-dnsext-dns-threats-01.txt
.   - draft-ietf-dnsext-tkey-renewal-mode-01.txt
.  + Blocked waiting for other documents
.   - draft-ietf-dnsext-ecc-key-01.txt
.   - draft-ietf-dnsext-dhcid-rr-05.txt
.  + Other documents
.   - draft-kitamura-ipv6-name-auto-reg-01.txt
.   - draft-dnsext-opcode-discover-00.txt

---

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.

---

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

---

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

Derek;

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

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

> attacks can lead users and applications to contact the wrong server

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.

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

-derek

---

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:07:47 +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! ]

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

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

---

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