[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



In message <alpine.BSF.1.10.0812101110480.77459@fledge.watson.org>, Samuel Weile
r writes:
> [ Moderators note: Post was moderated, either because it was posted by
>    a non-subscriber, or because it was over 20K.  
>    With the massive amount of spam, it is easy to miss and therefore 
>    delete relevant posts by non-subscribers. 
>    Please fix your subscription addresses. ]
> 
> >> 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.
> 
> Mark successfully corrected me.  (Thank you, Mark.)
> 
> Given that, I have no objection to removing the aliases (with 
> appropriate explanation, Andrew's option 1).  However, for the 
> purposes of expediency, I suggest we take Andrew's option 3 and leave 
> this document as it is.  It only uses two extra identifiers at the 
> moment, which seems an acceptable loss.

	Which unfortunately sets a precident.  People won't go back
	and look at this discussion.  We need to send the right message,
	in rfc's, for people adding new algorithms.
 
> -- 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/>