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

From: [email-masked]
Date: Wed, 27 Jun 2001 07:01:51 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS Extensions Working Group of the IETF.

	Title		: DNSSEC Opt-in for Large Zones
	Author(s)	: M. Kosters
	Filename	: draft-ietf-dnsext-dnssec-opt-in-00.txt
	Pages		: 9
	Date		: 26-Jun-01
	
In order for DNSSEC to be deployed operationally with large zones
and little operational impact, there needs to be included a
mechanism that allows for the separation of secure versus unsecure
views of zones. This needs to be done in a transparent fashion that
allows DNSSEC to be deployed in an incremental manner.  This
document proposes a method using views to allow for incremental
growth of delegations that are registered as secure. This is
accomplished by extending the use of the NXT record to deal with
non-secure delegations as well as for non-existence.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-opt-in-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dnsext-dnssec-opt-in-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-dnsext-dnssec-opt-in-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Roy Arends <[email-masked]>
Date: Fri, 29 Jun 2001 07:30:48 +0200 (CEST)

> 	Filename	: draft-ietf-dnsext-dnssec-opt-in-00.txt

Mark, I'm convinced this is a good idea, though a few first thoughts after
reading the draft:

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

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.

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

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. 

My .02 Euro,

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: Jakob Schlyter <[email-masked]>
Date: Fri, 29 Jun 2001 18:39:23 +0200 (MEST)

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

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.

	jakob

--
Jakob Schlyter <[email-masked]>                Network Analyst
Phone:  +46 31 701 42 13, +46 70 595 07 94   Carlstedt Research & Technology

---

From: Mats Dufberg <[email-masked]>
Date: Fri, 29 Jun 2001 19:52:29 +0200 (CEST)

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

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

Mats

-----------------------------------------------------------------
Mats Dufberg                                     +46-8-545 857 06
[email-masked]                           fax: +46-8-545 857 29

---

From: Jakob Schlyter <[email-masked]>
Date: Fri, 29 Jun 2001 22:02:46 +0200 (MEST)

I have more comments after some more out-of-band discussions with roy, dan
& mats.

at first, a opt-in zone is perhaps a somewhat bad name. what we really
mean is "a zone that may contain unsigned data". to achive this we have at
least two options.

we either have a flag somewhere (in KEY, SEC or what have we) that toggles
the semantics of the NXT records for a zone to change from "authenticated
denial of existance" into "authenticated denial of security".

an alternative solution would be to add another RR for authenticated
denial. the rfc 2535 semantics for NXT remain. the new RR would include a
flag that specifies if it denies existance of everything or denies
existance of security. this could be a RR similar to NXT or NO but with a
flag field added.

	jakob