Subject: Re: Q2: crypto algorithm requirements for DNSSEC

From: Derek Atkins <[email-masked]>
Date: 12 Feb 2003 11:49:34 -0500

"Loomis, Rip" <[email-masked]> writes:

> I know that leaving DSA as a "must implement" algorithm smacks of
> over-engineering to some folks.  Can anyone provide a convincing
> argument of what the DSA-specific code actually "costs" a developer
> (in terms of size of compiled code or other criteria)?  To me it
> seems minor in the big scheme of things, and I think DSA should be
> left in the "must implement" category.  I can live without it, but
> I just haven't seen a convincing argument to remove it.

I don't think anyone has argued that leaving DSA as a "must implement"
is over-engineering.  I _believe_ that the arguments have been that
specifying that operationally you MUST USE both RSA _AND_ DSA in your
zone is over-engineering.

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

--
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: Rob Austein <[email-masked]>
Date: Wed, 12 Feb 2003 13:37:54 -0500

At 12 Feb 2003 11:49:34 -0500, Derek Atkins wrote:
> is over-engineering.

Sorry, but I have.

Rip, I don't have numbers for this specific DSA question, but after a
decade in the embedded software market I can tell you that code space
-always- costs for low end devices, it's just economics.

So I have to turn the question around.  Show me that keeping DSA as
manadatory to implement is important, and I can live with it.  But
keeping with no strong reason to believe that it buys us anything is
bad, because code that brings no comprehensible benefit to the
customer has this nasty tendency to be left out of the final product
whether the spec says it's mandatory or not, at which point we have
interoperability problems.

--Rob

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 13 Feb 2003 10:07:25 +0100

O
> -always- costs for low end devices, it's just economics.

Curiosity: How many embedded devices run a full blown resolver today?
Will embedded devices run their own verification code or will they set
up a trust relation with a verifying resolver. 

--Olaf

--------------------------------------------| Olaf M. Kolkman
                                            | www.ripe.net/disi

---

From: Jaap Akkerhuis <[email-masked]>
Date: Thu, 13 Feb 2003 11:35:39 +0100

Olaf:

I don't know about today, but motorola apparently announced that
they are going to use Linux in theit mobile phones and other personal
electronic devices: http://news.com.com/2100-1001-984424.html?tag=fd_top

	jaap

---

From: Rob Austein <[email-masked]>
Date: Thu, 13 Feb 2003 11:42:37 -0500

> up a trust relation with a verifying resolver. 

I was thinking more along the lines of a recusive-mode-only resolver
with verification capabilities.  Device lets local infrastructure do
the donkey work of iterative resolution, but does its own verifying.

As others have noted, an embedded Linux system may have BIND9,
OpenSSL, OpenSSH, seven elephants, and the kitchen sink, but such
devices tend to have relatively large flash chips (8 or 16 MB).