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

[Roy Arends <Roy.Arends@nominum.com>]

On Tue, 3 Jul 2001, Mark Kosters wrote:

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

If the semantics for type bit map are not changed, when using the opt-in
view the type bit map could state there is an existing RR record, which is
not signed, so it does NOT exist in the opt-in view.

The semantics is with regards to the NXT type, in rfc-2535 it is defined
for non-existance of names and types. Your draft mentions the change for
labels, but not for types. In rfc 2535 there is only one semantic wrt NXT
and I see the Labels and Types as attributes. I assumed, when the draft
stated "Since the opt-in model changes the semantics of the NXT RR", this
was for the 2535-semantics, not specifically for labels only.

I think the draft should be more specific on NXT in full, not only about
labels.

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

When talking about opt-in views/non-dnssec view, it seems that there are
actually two zone's, one containing secured RRsets (opt-in), the other all
(non-dnssec).

It is more conceivable to state that there is only one zone. A nameserver
serves the DNSSEC RRsets (KEY/SIG/NXT/DS) only when DO is set in the
query. Nothing has to be written about combining views. When the zone is
partially signed, call it opt-in, when it is fully signed, call it
rfc2535-style.

This is not just semantics. With two views I've to xfer zones twice, one
with and one without the DO option. I rather do one xfer with DO set, and
get one zone.

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

Perfect, but then we should change the type-bit-map semantics as well.

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

I see it as follows:
rfc2535-style: zone is fully signed.
opt-in-style : zone is partly signed.

wrt to NXT:
rfc-2535-style: NXT indicates non-existence.
opt-in-style  : NXT indicates not-signed.

I would go for:
One zone, DO bit to indicate a resolver can handle DNSSEC (aka DNSSEC
view).

Regards,

Roy