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

From: Roy Arends <[email-masked]>
Date: Mon, 02 Jul 2001 07:26:09 -0700

On Fri, 29 Jun 2001, Mats Dufberg wrote:

> On Fri, 29 Jun 2001, Roy Arends wrote:
> 
> > 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 find the opt-in alternative a goot suggestion, which will ease the
> deployment of DNSsec. But it would be a bad idea not to have the full NXT
> (as defined in RFC 2535).
> 
> During the transition period we will have zone with mixed data (both
> signed and unsigned), but eventually there will be fully signed (secured)
> subtrees.
> 
> If you have a fully signed tree there is not much (if any)  gained from
> the opt-in alternative, but you will not have the fully authenticated
> denial of existence, which means that a fake non-secured subdomain can be
> spoofed.

Note that a malicious user has little if not nothing to gain by faking a
delegation (as in creating a domain that until now did not exist). In
general, a malicious user would want to spoof an existing domain. A
secured existing domain can not be spoofed (regardless if the zone was
opt-in or rfc2535 signed). An unsecured existing domain can always be
spoofed (regardless if the zone was opt-in or rfc2535 signed), because
glue will never be signed.

> Opt-in is good only if full NXT is kept.

Backwards compatibility is no problem, as long as the ambiguity in the NXT
record has to be solved (and I think then using a bit in the KEY does not
solve that).

Regards

Roy Arends
Nominum

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Roy Arends <[email-masked]>
Date: Tue, 03 Jul 2001 12:20:04 -0700

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.

> 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

---

From: Roy Arends <[email-masked]>
Date: Tue, 03 Jul 2001 13:03:07 -0700

On Tue, 3 Jul 2001, Mark Kosters wrote:

> On Fri, Jun 29, 2001 at 06:39:23PM +0200, Jakob Schlyter wrote:
> > I think the opt-in flag should be moved to a separate RR, a modified
> > version of Ed Lewis SEC RR would probably we a good choice (although I
> > would perhaps like to call it ZSS for Zone Security Status instead).
>
> I agree with having some sort of way of indicating the type of dnssec
> that is offered by that particular zone. This would also help with the
> NXT/NO problem as well. We used an unused bit in the KEY RR for opt-in
> given there was no other alternative.

One could allocate a type-bit > 127 to be put in NXT (with RR-type bit
zero set to 1) to indicate different format.

There is no NXT/NO problem that has to be solved by SEC. Both RR types can
be in a zone, the server serves it, the resolver interprets it. I don't
see why a SEC record should indicate that there are NO records in a zone
or NXT records in zone. The response clearly has either NXT or NO in its
response.

(The only reason for a SEC record I can think of is to indicate that there
are neither NO nor NXT records. That would obsolete opt-in all together)

Note that this is not a "what to expect" thing. If the parent states that
a child is signed, the resolver expects either NXT or NO. (NO RR is still
draft ofcourse).

It is a chicken or egg thing. If there exists no SEC RR for the child,
it gets either NXT or NO.

> > the opt-in flag is a per zone flag. as there could be multiple zone keys
> > and if KEY would include this flag, all zone keys has to have the same
> > flag (for that bit). also, as the zone key are signed by the parent, the
> > child can not change from/to opt-in without having the parent sign the
> > child's key.
>
> That brings up a question. Is it better or worse for this to be stored in the
> parent so the resolver knows what type of zone it is dealing with before it
> queries the child?

When there is no indication in the NXT record if it is opt-in or rfc-2535
style, one has the KEY (bit 4 in flag field) to indicate it with. IE One
already knows, _before_ quering a child what to expect. Again, no uses for
SEC here.

I would opt :-) for an opt-in indication in NXT by using a type-bit > 127.

Regards,

Roy Arends
Nominum

---

From: Roy Arends <[email-masked]>
Date: Tue, 03 Jul 2001 13:14:48 -0700

On Tue, 3 Jul 2001, Olafur Gudmundsson wrote:

> At 10:08 AM 7/2/2001, Roy Arends wrote:
> >In my opinion, it should be the NXT record itself rather than the KEY
> >record to indicate how it should be interpreted.
> >
> >About the zero bit:
> >
> >rfc2535, section 5.2 mentions the zero bit.
> >
> >         The first bit represents RR type zero (an illegal type which
> >         can not be present) and so will be zero in this format.  This format
> >         is not used if there exists an RR with a type number greater than
> >         127.  If the zero bit of the type bit map is a one, it indicates that
> >         a different format is being used which will always be the case if a
> >         type number greater than 127 is present.
> >
> >As stated, if the type bit zero is a one, it indicates a different format.
> >The different format in this case is the opt-in format.
>
> This bit is off limits to any use but to extend NXT to types with code > 127.
> If you want to use a bit in NXT to define Opt-in there are few type codes
> that I can pull out of the hat to do that from the low number bits (SINK,
> MB, etc.) or we just reserve a new type code for this.

Perfect. We could even use a bit >127 then.

Regards,

Roy Arends
Nominum