Subject: NSEC3 Issue 17: opt-out for delegation only is not enforcable.

From: Roy Arends <[email-masked]>
Date: Wed, 31 May 2006 13:11:14 +0200

Issue:

The use of Optout is restricted to unsigned delegations. This restriction 
is inherited from the experimental Opt-In draft. Even-though the 
restriction is in place, it can't be enforced on the server side, i.e. 
there is a way to allow unsigned records other than delegations to exist 
in an optout span, without it ever to appear as such on the wire, by means 
of delegating them to unsigned subzones with the same name.

Discussion:

Assume the administrator of the secured zone 'example.com' wants the world 
to see 'www.example.com' as unsigned. He could delegate www.example.com 
away as an optout unsigned delegation to another server.

This process can be automated without breaking any signatures. Delegation 
point NS records are unsigned, and there is no evidence the NS record 
exist if the NSEC3 duo that proves the closest provable encloser is marked 
as optout. This would violate the NSEC3 draft where a signer MUST NOT 
allow any other record than delegation point NS records to exist in an 
optout span.

possible approaches:

1) remove the delegation only restriction

Removing the delegation only restriction would send us back to the drawing 
table wrt NSEC3. We are currently beyond the design requirements for 
NSEC3.

2) Add a note to the draft.

Since it poses no threat to the security model of NSEC3, a simple 
implementation note would do.

3) Do Nothing

The lack of enforceability doesn't change the security considerations, nor 
the protocol on the wire. It is similar to an approach that constructs 
zones from material in a database, or using zone-file directives or 
meta-data to dynamically construct records. The server serves an unsigned 
delegation, the validator can check that. 

resolution:

The authors think that approach 2 is best. Actual execution of this hack 
would require a significant amount of engineering, solely at the 
descretion of the zone owner, while it is not a threat to the security 
model.

Regards,

Roy

--
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: Wed, 31 May 2006 15:53:28 +0200

> possible approaches:

(...)
> implementation note would do.
(...)
> descretion of the zone owner, while it is not a threat to the security

Is "Actual execution ... threat to security" the actual note you  
consider to add? If not, what is the text of the note you intend to  
add? To be honest it seems like your argumentation is actually  
targeted at approach 1.

To be more than honest, we had a long discussion about this during  
the opt-in debate and we reached a consensus at that time. I would   
therefore, from a process point of view, prefer to go for option 3.  
At this moment I'd like some clarification on the text of the actual  
note.

--Olaf, having the chair hat in his hand. :-)

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

---

From: Roy Arends <[email-masked]>
Date: Wed, 31 May 2006 15:58:47 +0200

> add? To be honest it seems like your argumentation is actually 

Apologies if I was unclear. All mistakes are mine. Without editors hat, I 
definitly do not want approach 1. I prefer approach 3. 
 
> At this moment I'd like some clarification on the text of the actual 

Lets make approach 3 the default resolution. 

Roy