Subject: RE: Q2: crypto algorithm requirements for DNSSEC

From: "Loomis, Rip" <[email-masked]>
Date: Wed, 12 Feb 2003 09:27:14 -0500

(Replying to several e-mails in the thread within one, so bear with
me please...)

Various smart folks said things along the lines of:

> The only argument I've seen (note: I'm repeating it here to answer
> your question, not because I necessarily agree with it) is that is
> embedded devices (like an IP Phone that does its own DNSSec
> verfication) you don't want to have to implement more than you really
> need.  A "must" algorithm that is never used is just a lot of wasted
> bits in a very restricted space.

Okay, that's at least a reasonable argument.  It doesn't, to me,
imply that it's a significant overall advantage to anyone if we now
de-specify DSA.

> My over-engineering-flag is raised as well; If RSA get's compromised
> the DNS is the least of my worries... If RSA get's compromised I can
> live with an unsecured DNS tree... just as I can live with it today.

If RSA gets compromised, DSA is not affected by the compromise, and DSA
is implemented in compiled/embedded software, then the process of
shifting everyone over to DSA for DNSSEC might be measured in days or
weeks.  If RSA is compromised and there is no alternate algorithm 
implemented in compiled/embedded software, then the process of deploying
a new one would be measured in months or years.

I agree that we only need to be "faster than the bear" on this and
that a lot of other transactions involving cryptography will be more
appealing targets if there's a new attack on RSA...but that doesn't
mean that it's any real big savings to anyone to de-specify DSA at this
point.  (Also, if RSA *is* broken suddenly, It Would Be Nice if
there were at least one cryptographically-related system that *didn't*
need a crisis deployment of new software...)

I believe, as others have provided reasonable arguments for, that
having DSA implemented in software but recommending the use of RSA
as the primary signing algorithm is the best answer.  I would ask that
we *don't* put DSA into a SHOULD NOT USE category, because there are
folks out there who might prefer DSA to RSA for their own reasons.

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.

Either way, I hope we can come to a resolution quickly.  There are
a lot of other DNSSEC items that we need to finish fighting through
which I believe are more important/useful for us to spend our time
on this month...

  --Rip

--
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: Derek Atkins <[email-masked]>
Date: 12 Feb 2003 11:49:34 -0500

> 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

---

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