Subject: RE: UPDATE and NSEC3 parameter transitions.

From: "Rose, Scott" <[email-masked]>
Date: Mon, 28 Aug 2006 08:19:30 -0400

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Wouter 
> 
> Hi Mark,
> 
> I'm not an expert in UPDATE but I didn't really get it.
> 
> Mark Andrews wrote:
> >         Some more NSEC3 questions.
> > 
> >         How do we, w/o updating config files, tell the 
> primary master to
> >         start generating a new nsec3 chain with different 
> parameters.
> 
> Why does someone want to change the NSEC3 parameters via 
> dynamic update?
> If a hash collision happens, the server can decide to perform salt++.

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.

Scott

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

---

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

> 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

---

From: Mark Andrews <[email-masked]>
Date: Tue, 29 Aug 2006 08:20:21 +1000

> In that case, do we want FORMERR, YXRRSET, NXRRSET, something else?

	Something else.  FORMERR, YXRRSET, NXRRSET all have specific
	meanings that this error doesn't map into.
 
--
ISC Training!  October 16-20, 2006, in the San Francisco Bay Area,
covering topics from DNS to DHCP.  Email [email-masked].
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]