Subject: Re: General comments on DNSSEC

From: "Andy W. Barclay" <[email-masked]>
Date: Sun, 16 Jun 2002 08:03:43 -0700

But DNS is not just another application. I can't think of any case
where the application is just DNS. Its always another application
that uses the data in DNS (like mozilla, xntp, ssh, sendmail, etc.)
Many people are talking about modifying the application to deal with
the AD bit. I'm becoming even more convinced now, that if I'm modifying
the application, I might as well modify it to simply use certificates.

[email-masked] wrote:
>>After reading draft-ietf-dnsext-dns-threats-01.txt, it has occurred to 
>>me that DNSSEC may be a waste of time.
>>
>>It seems that applications are capable of the same security that we can 
>>provide with DNSSEC. (I realize that if we could get a global 
>>deployment, we could increase security on legacy protocols).
>>
>>For example, the draft referenced above says:
>>"The resulting list of desired security services was
>>      1) data integrity, and
>>      2) data origin authentication."
>>
>>Any application that uses certificates has those capabilities. Legacy 
>>applications that require security are being upgraded to support 
>>certificates/keys (ntp).
>>
>>Can someone convince me that DNSSEC still makes sense?
>>(One argument that I won't buy into is that my phone/PIM or whatever 
>>doesn't have the horsepower to do certificates. By the time we get 
>>dnssec deployed, they will have that horsepower.)
>>
>>-- 
>>Regards,
>>Andy W. Barclay.        [email-masked]
>>fax  (781) 823-8276
>>Always a UNIX Evangelist (and sometimes a system and network architect)
>>
>>"Money, not morality, is the principle commerce of
>>civilized nations"
>>    -- Thomas Jefferson
> 
> 
> 	DNS is just another application trying to secure its own
> 	transactions using cryptography.  You have no problem with
> 	NTP using cryptography to secure its transactions.  What's
> 	your problem with DNS using cryptography to secure its
> 	transactions.
> 
> 	Mark
> --
> Mark Andrews, Internet Software Consortium
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

-- 
Regards,
Andy W. Barclay.        [email-masked]
fax  (781) 823-8276
Always a UNIX Evangelist (and sometimes a system and network architect)

It takes a long time to understand nothing.
    --EDWARD DAHLBERG

--
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: "Eric A. Hall" <[email-masked]>
Date: Sun, 16 Jun 2002 10:52:53 -0500

> that uses the data in DNS (like mozilla, xntp, ssh, sendmail, etc.)

This should not be taken as an endorsement of Andy's argument, but it is
worth pointing out that if the application isn't part of the security
chain then attacks can be moved to some other naming service that the
application or resolver implicitly trusts. Hacking into /etc/hosts on a
few thousand boxes is impractical but using a virus to infect a few
thousand PCs isn't. Changing an NIS or LDAP naming service would also be
productive for redirecting traffic at least within a local administrative
domain. The only way that the e2e argument holds up is if the application
which is issuing the lookups does the validation; the application is the
participating end-point, not the resolver.

Of course, the local security policies of any given opsys are probably
well beyond the scope of this WG. It might be worth mentioning some of
these issues in a security considerations section of an update though,
especially the requirement for applications to participate.

Also of course, if there's some switch that needs to be defined in order
for an application to actively and effeciently participate then that is in
scope, and the switch should be defined somewhere.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: [email-masked]
Date: Mon, 17 Jun 2002 10:34:41 +1000

> the application, I might as well modify it to simply use certificates.

	While certificates will *detect* that you have the *wrong*
	address they won't help you *get* the *right* address.
	DNSSEC will do that by allowing the nameserver to reject
	the bogus data and wait for the good data to arrive.  DNSSEC
	reduces the attack at the DNS level to a DoS attack not a
	insertion attack.

	The DoS attacks come in (at least) two forms.
	1. computation attack
	2. blocking the valid answers being received which requires
	   that the attacker is controlling equipment on the path
	   between the nameservers involved.
 
	Mark