RE: Q2: crypto algorithm requirements for DNSSEC

["Loomis, Rip" <GILBERT.R.LOOMIS@saic.com>]

(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 namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>