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

[Peter Koch <pk@DENIC.DE>]

On Tue, Dec 09, 2008 at 10:06:37PM -0500, Matt Larson wrote:

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

I have my doubts here as well, but I feel a bit guilty at the same time.
In my post-WGLC review <20080915132426.GE12022@x27.adm.denic.de>, archived
at <http://www.ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01828.html>
(missed the 4 weeks LC by another 4 days, but that's for the 'workflow' thread)
I wrote:

>> 5.2.  Support for NSEC3 denial of existence
>> 
>>    Implementations that have support for RSA/SHA-2 MUST also have
>>    support for NSEC3 denial of existence, as specified in RFC 5155
>>    [RFC5155].
>
> I agree with the spirit, but since there is no immediately obvious
> connection between NSEC3 and these two new algorithms, implementors
> might deserve some explanation, otherwise this could come as a late
> surprise.  If we're saving precious DNS security algorithm numbers,
> we can say that ;-)

This message was later quoted by Olafur in
<http://www.ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01852.html>
when he asked about the NSEC/NSEC3 unpredictability.

First, I'd like to restate that I agree with the spirit of declaring NSEC3
support "mandatory", or state of the art or "NSEC3 [is] an integral part
of DNSSEC".  As Matt correctly assumed, if/when DE is going to be signed,
NSEC3 is a MUST.  However, as ...

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

... we saw just here, the language in -05 was probably too strong and an
explanation for implementers is really needed, at least the term "support"
must be clarified.

So, implementations of RSA/SHA-2 MUST be able to recognize and validate NSEC3
records, but they will treat those zones/responses as unsigned unless they
fully implement NSEC3.  Recognition and validation are necessary to avoid
downgrade attacks where the attacker substitutes NSEC RRs by random (NSEC3)
garbage.

> in the worldwide TLD market.  A DNSSEC validator without NSEC3 support
> will shortly be either a useless antique or a laboratory curiosity.

Agreed, at least for general purpose validators.  But saying this en passant
in the RSA/SHA-2 spec isn't an optimum service to implementors.  And
assuming that the linear ordering of RFC numbers gives them a hint, isn't either.

> 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

Same here.

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

I agree that we should refrain from the continued algorithm aliasing, but
would like to propose a slightly different solution.  The draft should go back to
two instead of four algorith numbers.  The text regarding NSEC3 should
be clarified around 'support' and 'recognition'. RFC 5155 pretty well
documents the need for aliases, but it didn't make the step forward
explaining why this won't set precedent for future extensions.
Therefore, we should document, maybe in DNSSECbis-Updates, the decision and
the reasoning, so it's available for similar situations in the future.
Note that we might also want to strongly recommend NSEC3 as part of DNSSECbis
there, but these are separate issues.

-Peter

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