Subject: Re: UPDATE and NSEC3 parameter transitions.

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 28 Aug 2006 14:40:35 +0200

On Aug 28, 2006, at 2:19 PM, Rose, Scott wrote:

>
> Someone might want to increase the number of iterations or salt.  Not
> just because of a collision, but to add to the cost of dictionary
> attacks when new hardware is available to attackers.
>
> I don't have a solution to Mark's question (off the top of my head).
> However, if the WG decides that the NSEC3-parameters RR is needed,  
> then
> I could see any changes to that via dynamic update or in a static zone
> file might trigger regeneration of the NSEC3 chain.
>

Hmmm....

Are we sure we _need_ this.

I think that we are in a stage of protocol development where we  
should decide what is _need_ and what is _nice_.

IMHO there is no need to being able to change policy dynamically  
(change salt or iterations can be seen as policy change) it would be  
nice but I think that it is not an absolute requirement. I would even  
think that in order to get this thing done we explicitly call  
dynamically changing policy such as salt and hash parameters a non- 
requirement.

--Olaf

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 28 Aug 2006 10:03:15 -0400

> dynamically changing policy such as salt and hash parameters a non- 

Then what happens, in the case of a collision on dynamic update, when
the following is violated:

   If a hash collision is detected, then a new salt MUST be chosen and
   the signing process restarted.

Is some text needed in section 6.5 saying that an attempted dynamic
update may fail in the event it entails a policy change, such as salt? 
In that case, do we want FORMERR, YXRRSET, NXRRSET, something else?

A

----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
                                        +1 416 646 3304 x4110

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>