Subject: UPDATE and NSEC3 parameter transitions.

From: Mark Andrews <[email-masked]>
Date: Mon, 28 Aug 2006 10:53:16 +1000

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.

        How does the server signal that the chain is complete?

        How do we, w/o updating config files, tell the primary master to
        stop generation a nsec3 chain and potentially to start generating
        a NSEC chain?

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

--
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: Wouter Wijngaards <[email-masked]>
Date: Mon, 28 Aug 2006 10:20:01 +0200

Hi Mark,

I'm not an expert in UPDATE but I didn't really get it.

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

>         How does the server signal that the chain is complete?

The NSEC3 record with the SOA-bit on appears in the zone?

>         stop generation a nsec3 chain and potentially to start generating

Since NSEC3 is perfect, users do not need to transition back. If they
really want, users can stop the primary master and resign the zone.

Best regards,
   Wouter

---

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

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

---

From: "Rose, Scott" <[email-masked]>
Date: Mon, 28 Aug 2006 09:04:38 -0400

Personally?  I don't know if we need it or not.  It was one of the
issues that was close to agreement at the informal NSEC3 meeting during
Montreal IETF. If secondaries needed some way to know the NSEC3
salt/iter parameters from the zone information, a new RR at the apex
might be the solution.  

The idea being that once that RR is present at the apex, the NSEC3 chain
with those params is complete.  By extension, if those params needed to
be updated dynamically, then a change to the param RR could be a
trigger.  Although there is the question of do NSEC3 parameters need to
be updated dynamically.  Is there a good reason?

Scott

> [mailto:[email-masked]] On Behalf Of Olaf M. Kolkman
> Sent: Monday, August 28, 2006 8:41 AM
> To: IETF DNSEXT WG
> Cc: Rose, Scott
> Subject: Re: UPDATE and NSEC3 parameter transitions.
> 
> 
> On Aug 28, 2006, at 2:19 PM, Rose, Scott wrote:
> 
> >
> > 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: David Blacka <[email-masked]>
Date: Mon, 28 Aug 2006 09:49:36 -0400

> salt/iter parameters from the zone information, a new RR at the apex

This is NSEC3 Issue 18 <http://www.nsec3.org/cgi-bin/trac.cgi/ticket/38>.

Based on the feedback received so far, the editors are moving forward
with defining the NSEC3-PARAM RR (solution #2) in the forthcoming
version of the draft.

Obviously, any further discussion on Issue 18 (or any of the other
issues) is welcome.

> be updated dynamically.  Is there a good reason?

I think this feature is certainly possible, however, I do not think it
should be a requirement.

-- 
David Blacka                      <[email-masked]>
Sr. Engineer    VeriSign Infrastructure Product Engineering

---

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

> On Mon, Aug 28, 2006 at 02:40:35PM +0200, Olaf M. Kolkman wrote:
> > 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.
> 
> 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?

	Something else.  FORMERR, YXRRSET, NXRRSET all have specific
	meanings that this error doesn't map into.
 
> A
> 
> 
> 
> ----
> Andrew Sullivan                         204-4141 Yonge Street
> Afilias Canada                        Toronto, Ontario Canada
> <[email-masked]>                              M2P 2A8
>                                         +1 416 646 3304 x4110
> 
> 
> --