Subject: I-D ACTION:draft-ietf-dnsext-rollover-requirements-01.txt

From: [email-masked]
Date: Mon, 08 May 2006 15:50:02 -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		: Requirements related to DNSSEC Trust Anchor Rollover
	Author(s)	: S. Crocker, et al.
	Filename	: draft-ietf-dnsext-rollover-requirements-01.txt
	Pages		: 11
	Date		: 2006-5-8
	
Every DNS security-aware resolver must have at least one Trust Anchor
to use as the basis for validating responses from DNS signed zones.
For various reasons, most DNS security-aware resolvers are expected
to have several Trust Anchors.  For some operations, manual
monitoring and updating of Trust Anchors may be feasible but many
operations will require automated methods for updating Trust Anchors
in their security-aware resolvers.  This document identifies the
requirements that must be met by an automated DNS Trust Anchor
rollover solution for security-aware DNS resolvers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rollover-requirements-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-rollover-requirements-01.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-rollover-requirements-01.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: Thierry Moreau <[email-masked]>
Date: Thu, 11 May 2006 10:11:53 -0400

Dear co-chairs and wg members:

I regret to post the present message against progression of DNSEXT WG 
document draft-ietf-dnsext-rollover-requirements-01. I see two 
difficulties with this draft, related to the IETF document development 
process.

The wording used in the section 5.2. (No Intellectual Property 
Encumbrance) is such that the DNSEXT WG commits itself to make factual 
verifications about the presence and/or validity of IPR claims, which is 
a WG activity not compliant with RFC3979.

The other issue with the document is that it goes beyond the DNSEXT 
chartered work. Specifically, the charter mandates DNSEXT to "Define a 
method for automated rollover of trust-anchors configured in validating 
resolvers." Instead, the requirements document address trust anchor key 
management on a broader perspective, as if the charter might be revised 
as a consequence of revisiting the trust anchor key functions in the 
DNSSEC protocol specifications.

In going beyond its specific automated rollover mandate, the DNSEXT 
envisions solutions outside of DNS protocol extensions, again in 
possible conflict with the DNSEXT charter.

There might be a group willingness to proceed along the lines explained 
above. However, the IETF standards development process is a structured 
activity, and wandering of a WG outside the process rules and/or its 
chartered work may be coerced by the groups in charge of IETF activities 
overseeing (if I understand correctly, this would be the IESG if and 
when the draft is approved at the WG level).

What should have been done in the preparation for a requirement document 
for automated trust anchor key rollover is to define the very issues as 
faced in the DNSSEC protocol environment, contemplating the set of 
possible DNS protocol extensions for rollover purposes, with the known 
limitations of the DNS architecture. As a consequence, the requirements 
document might have come to inescapable security considerations expected 
from any trust anchor key rollover solution. If I recall correctly, the 
WG chairs expressed the view that the requirement should also define 
"metrics" against which trust anchor key rollover solutions would be 
evaluated.

These issues were privately raised to the DNSEXT WG co-chairs, without 
feedback. In WG discussion about the previous version of the document 
draft-ietf-dnsext-rollover-requirements-00, I expressed my opinion about 
the section 5.2. (No Intellectual Property Encumbrance), and I otherwise 
abstained from making contributions towards advancement of the draft, 
based on the assumption that the WG discussions on a draft going beyond 
the WG charter would be unproductive.

I leave it to the WG co-chairs to handle the current message in their 
process governance duties.

Regards,

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: [email-masked]

--
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: Wes Hardaker <[email-masked]>
Date: Thu, 11 May 2006 08:47:40 -0700

>>>>> On Thu, 11 May 2006 10:11:53 -0400, Thierry Moreau <[email-masked]> said:

Thierry> The wording used in the section 5.2. (No Intellectual Property
Thierry> Encumbrance) is such that the DNSEXT WG commits itself to make factual
Thierry> verifications about the presence and/or validity of IPR claims, which
Thierry> is a WG activity not compliant with RFC3979.

Suggested text to fix this if the WG deems it necessary to fix.  I
don't think the requirements document is ever going to be a legal
document, and thus I doubt that it needs the level of word-smithing
we're talking about.  It's a technical document to assist technical
people in coming up with a reasonable solution ta a problem.  But...

OLD:
   5.2.  No Intellectual Property Encumbrance

   Because trust anchor rollover is considered "mandatory-to-implement",
   section 8 of [RFC3979] requires that the technology solution chosen
   must be unencumbered or must be available under royalty-free terms.

   For this purpose, "royalty-free" is defined as follows: world wide,
   perpetual right to use, without fee, in commerce or otherwise, where

NEW:
   5.2.  No Intellectual Property Encumbrance

   Because trust anchor rollover is considered "mandatory-to-implement",
   section 8 of [RFC3979] requires that the technology solution chosen
   must not be known to be encumbered or must be available under
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   royalty-free terms.

   For this purpose, "royalty-free" is defined as follows: world wide,
   perpetual right to use, without fee, in commerce or otherwise, where

-- 
Wes Hardaker
Sparta, Inc.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 25 May 2006 16:02:49 +0200

On May 11, 2006, at 4:11 PM, Thierry Moreau wrote:

> I regret to post the present message against progression of DNSEXT  
> WG document draft-ietf-dnsext-rollover-requirements-01. I see two  
> difficulties with this draft, related to the IETF document  
> development process.

Although we have not issued a last call yet I will take this note as  
input for a "nay" during last call.

> Encumbrance) is such that the DNSEXT WG commits itself to make  
> factual verifications about the presence and/or validity of IPR  
> claims, which is a WG activity not compliant with RFC3979.

I think that Wes Hardaker's suggested modification to the text fixes  
this; the working group then only has to check on "known encumbrance"  
which is essentially "verifying against the IPR database".

> chartered work. Specifically, the charter mandates DNSEXT to  
> "Define a method for automated rollover of trust-anchors configured  
> in validating resolvers." Instead, the requirements document  
> address trust anchor key management on a broader perspective, as if  
> the charter might be revised as a consequence of revisiting the  
> trust anchor key functions in the DNSSEC protocol specifications.
>

You have lifted a specific line from the charter: "a method for  
automated rollover of trust-anchors configured in validating  
resolvers." I would like to quote the full context:

The WG works on solutions for DNSSEC deployment issues that may
require protocol modifications. Two of these issues are identified
and are worked on under the umbrella of this WG. 1] (a) method(s) to
prevent the possibility of trivial zone enumeration and 2] a method
for automated rollover of trust-anchors configured in validating
resolvers.

In my opinion the working group is not overarching since we are  
trying to sort out solutions for DNSSEC deployment issues that may  
require protocol modifications.

> There might be a group willingness to proceed along the lines  
> explained above. However, the IETF standards development process is  
> a structured activity, and wandering of a WG outside the process  
> rules and/or its chartered work may be coerced by the groups in  
> charge of IETF activities overseeing (if I understand correctly,  
> this would be the IESG if and when the draft is approved at the WG  
> level).
>
> What should have been done in the preparation for a requirement  
> document for automated trust anchor key rollover is to define the  
> very issues as faced in the DNSSEC protocol environment,  
> contemplating the set of possible DNS protocol extensions for  
> rollover purposes, with the known limitations of the DNS  
> architecture. As a consequence, the requirements document might  
> have come to inescapable security considerations expected from any  
> trust anchor key rollover solution. If I recall correctly, the WG  
> chairs expressed the view that the requirement should also define  
> "metrics" against which trust anchor key rollover solutions would  
> be evaluated.

We did. I would like to ask the working group if they think that that  
will be a useful exercise. Personally I think it be a difficult task.  
I propose that we "fix" the rollover requirements document and that  
we start looking at the separate proposals and see which ones meet  
which requirements. From that we can probably isolate 1 or 2 on which  
we then will further debate.

>
> These issues were privately raised to the DNSEXT WG co-chairs,  
> without feedback. In WG discussion about the previous version of  
> the document draft-ietf-dnsext-rollover-requirements-00, I  
> expressed my opinion about the section 5.2. (No Intellectual  
> Property Encumbrance), and I otherwise abstained from making  
> contributions towards advancement of the draft, based on the  
> assumption that the WG discussions on a draft going beyond the WG  
> charter would be unproductive.

I have invited you to contribute to the working groups requirement  
document. I understand that you consciously abstained, so noted.

thanks,

--Olaf Kolkman

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