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

[Mark Andrews <Mark_Andrews@isc.org>]

In message <Pine.LNX.4.64.0809301237230.27246@mint>, Sam Weiler writes:
> I have read this document.  Aside from the nits previously raised and 
> the below, it should go forward.
> 
> >>> 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 ;-)
> >>
> >> From the document I read a zone that signs with RSA/SHA2 can use 
> >> either NSEC or NSEC3, thus and validator can not be sure until it 
> >> gets back an answer from the zone, which kind of negative 
> >> "expression" the zone uses.
> >>
> >> Are the members of the working group comfortable with this ?
> 
> No.  This creates an unneccessary link between two unrelated DNSSEC 
> parameters.  The danger is that if someone finds an attack that takes 
> advantage of NSEC3, zones may have to choose between being vulnerable 
> to that attack while using good hash algorithms and protecting 
> themselves from the NSEC3 attack while using poor hash algorithms. 
> Not a fun choice.

	There is no such risk.

        Zones operators have a choice of whether to generate NSEC
        or NSEC3 chains.  I can generate NSEC chains with algorithm
        5 or 7.  Both are equally secure.  The fact that one could
        generate a NSEC3 chain is irrelevent as one would also have
        to get the signatures on the NSEC3 chain accepted for there
        to be a threat and if you can get that to happen it doesn't
        matter if we are using NSEC or NSEC3 because the whole kit
        and kaboodle is gone.

        If the flaw is found then it is no worse than saying don't
        use 3 as the exponents with RSA.

        If you *only* had the choice of generating NSEC3 chains with
        the new algorithm number then your argument would make sense.
        One however would also have to go through the insecure state
        to transition from NSEC to NSEC3 and we specified the use of
        algorithm 7 to mean both NSEC and NSEC3 chains are possible.

        Currently we have

                TBA1 is NSEC.
                TBA2 is NSEC or NSEC3.

        What's the point of TBA1?

        B.T.W. Section 2.1, Paragraph 2 should start with "For the
        use of NSEC or NSEC3," to make that clearer.

        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.

        Mark


> Is there any compelling reason to link them?
> 
> -- Sam
> 
> --
> 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/>
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org

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