Re: I-D ACTION:draft-ietf-dnsext-dnssec-opt-in-00.txt

[Mark Kosters <markk@netsol.com>]

On Fri, Jun 29, 2001 at 07:30:48AM +0200, Roy Arends wrote:
> 1) wrt opt-in, a NXT record indicates that a delegation is not secured by
> specifying the signed owner name before and after the unsecured owner
> name. Thus it indicates "authenticated denial of security" instead of
> "authenticated denial of existence". Should the type bit map interpreted
> as "type does not exist" or "type is not signed" ?

The type bits in the NXT are as stated in rfc2535 showing that there is
existence of RR's in the opt-in view (just like rfc2535). I'm not really 
sure if this should be changed.  Can you think of a reason that we should 
change the semantics of the type bits for opt-in?
 
> 2) To indicate opt-in, a bit is set in the flag-field of the zone KEY.
> When I decide to sign the zone with an "opt-in" zone KEY and I sign the
> zone with a vanilla zone KEY (I can sign the zone with more than 1 KEY),
> there is no way of indicating how to create NXT RR. Would there be two NXT
> RR, one for opt-in view, one for rfc2535-style ? This is in my opinion
> very difficult to realise and probably breaks the scheme. Temporarily
> signing with both keys might be necessary when I'm moving from a
> rfc2535-style to opt-in-style or vice versa.

We didn't envision having an intermediate state between rfc2535 and opt-in.
One can follow the usual approach to change from type to type by cranking down 
the ttls to make this change on the affected RR's and resign the zones 
including all the unsigned RR's rfc2535-style.

The opt-in view by itself looks like a perfectly valid rfc2535 zone, only
it does not contain any unsecured delegations.  It is only when the 
authoritative opt-in resolver combines the opt-in view with the non-dnssec 
view in its response does the meaning of the NXT record change. The type 
bits do not have to be changed.

> 3) Should we extend "authenticated denial of security" for unsecure
> delegations (as specified in the draft) to any RRset ?

I'm sure one can do this if they wish.

> 4) If opt-in is generally conceived as a good idea, should backwards
> compatibility be enforced by also permitting rfc2535-style zones ? We are
> already searching for an alternative to sig@child, which is not backward
> compatible (though of a different level) with rfc2535, next to that,
> rfc2535 style zone's are not widely deployed. To my knowledge there are
> some testbeds (cairn, tislabs, sigz, nl.nl, etc) though I've not seen a
> full deployment of DNSSEC. 

I think that having to maintain backward capability defeats the purpose of 
opt-in. Your right in that we have not had full deployment yet so I guess
I see backwards compatility as a very small issue. Yes Nominum will have to 
build in opt-in resolution but I hear that this is not too difficult.

Mark

-- 

Mark Kosters             markk@netsol.com       Verisign Applied Research