RE: Q2: crypto algorithm requirements for DNSSEC

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

> There has been previous talk on this list regarding dropping DSA as a
> mandatory to implement algorithm.  

My summary of those previous discussions, testing of which I'm
aware, and my own thoughts:
  - RSA was patented at the time of the original DNSSEC work, so
    a patent-free alternative was desired.  RSA can now be implemented
    without patent encumbrances--that doesn't mean that DSA isn't
    useful as an alternative.
  - DSA has significantly lower performance in all current implementations
    of which I'm aware.  Some of that is related to characteristics of
    DSA, in that the "sign once, verify many" model works better with
    an algorithm like RSA (verification time is << signing time) than it
    does with a balanced algorithm like DSA (verification time is similar
    to signing time).  That means DSA is currently less useful than RSA
    for most real-world applications, but doesn't mean it's useless.
  - If at some point there's a significant cryptographic problem found
    with RSA, It Would Be Nice if there were an alternative already
    deployed.  Then again, if there's a major new cryptographic attack
    found to which RSA is vulnerable, DSA might be vulnerable as well.
  - If we require one less algorithm to be implemented in the software,
    then it might make it easier on implementers.  That argument seems
    to me not to carry much weight--there are already RSA and DSA crypto
    implementations out there and I doubt any DNS software author will
    be writing their own.  

> Q:  Is the change of DSA to OPTIONAL  acceptable?  That will 
> leave only RSA/SHA1 as the only mandatory to implement algorithm.

I never saw a convincing argument, given the above items, as to why this
was a *useful* change.  Whose time are we really saving by making this
change?  DSA might not be incredibly useful today, but I guess I don't
see why it's useful to "unspecify" it when it's already documented and
specified.  Yes, I just tried to look through my archives and notes to
see if I missed the convincing argument.

If I've missed some past convincing argument, or if I've screwed up
anything in my summary above, I'm sure someone will re-calibrate me.
If the question is "Could I *live* with this change?" then the answer
would be Yes.  I'm just not sure why the change is desired.

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