Re: implied NSEC3 support in rsasha256 (was: [dnsext] Re: Working Group Last Call for draft-ietf-dnsext-dnssec-rsasha256-05)

[Matt Larson <mlarson@verisign.com>]

On Tue, 09 Dec 2008, Andrew Sullivan wrote:
> On Tue, Dec 09, 2008 at 02:24:10PM +1100, Mark Andrews wrote:
> 
> >         The only reason for having two numbers is if you believe
> >         there there is a reason to support validators which can do
> >         RSA/SHA-256 and not NSEC3.  I don't see a need to support
> >         that combination.
> 
> I determined during working group last call, however, that others
> _did_ see a need to support that combination.

I do not believe the record supports that conclusion.

> Moreover, I buy the argument that we shouldn't link these two issues
> together.  If there is a validator that can't do NSEC3 and they find
> they suddently want to do SHA-2, why do we want to put an extra
> barrier in their way?

Roy already explained that a validator can support SHA-2 and not
NSEC3; their is no barrier.

I want to amplify Mark's comment about the impending need for
validators to support NSEC3.  The NSEC3 ship has sailed and is now
part of DNSSEC.  Let us not ignore operational reality while we
consider this particular piece of protocol engineering.  PIR has said
that .org will be signed with NSEC3.  While I cannot speak for Nominet
nor DENIC, all indications I've seen are that .co.uk and .de will be
signed with NSEC3 (as their representatives worked actively on the
protocol).  And, finally, I can most certainly assure you that when
.com and .net are signed, they will use NSEC3.  Those five zones
represent well over 50% of the total number of registered domain names
in the worldwide TLD market.  A DNSSEC validator without NSEC3 support
will shortly be either a useless antique or a laboratory curiosity.

As others have pointed out, the multiple algorithm hack was only
needed to protect past validators, not future validators.  There is
simply no reason to propagate this technique and it unnecessarily
reduces and complicates the algorithm space.

I regret that I did not notice paragraph 7 of Andrew's October 22 WGLC
message until this thread came back to life.  However, now that the
inaccuracies in that paragraph have been brought to light, and I have
gone back through the mailing list to examine the record, I strongly
oppose its conclusion.  The language regarding NSEC3 support from the
-05 version should be restored and we should not continue the
unnecessary practice of algorithm aliases.

Matt

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