Subject: Last Call: Simple Secure Domain Name System (DNS) Dynamic Update to Proposed Standard

From: The IESG <[email-masked]>
Date: Fri, 02 Jun 2000 08:34:25 -0400

The IESG has received a request from the DNS Extensions Working Group
to consider Simple Secure Domain Name System (DNS) Dynamic Update
<draft-ietf-dnsext-simple-secure-update-01.txt> as a Proposed Standard.
This will replace/obsolete RFC2137, currently a Proposed Standard.

The IESG will also consider Domain Name System Security (DNSSEC)
Signing Authority <draft-ietf-dnsext-signing-auth-01.txt> as a Proposed
Standard, updating RFC2535

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the 
[email-masked] or [email-masked] mailing lists by June 16, 2000.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-simple-secure-update-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-signing-auth-01.txt

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

---

From: Edward Lewis <[email-masked]>
Date: Thu, 1 Jun 2000 10:05:47 -0400

Regarding the "Signing Authority" draft:

>1 - Introduction
>
>...  The intent
>is to establish a standard policy followed by a secure resolver; this
>policy can be augmented by local rules.

I have been pushing for a "canonical" means of validating DNSSEC data, and
this document reflects what I believe to be a manageable first-cut at an
maintainable policy.  However, this policy is rather conservative, which
means that although security is high, brittleness is high too.  (Meaning
that if part of the secured DNS is unavailable, data below it can't be
secure - the policy is susceptible to tears and rips in the tree.)

Restricting the initial policy is necessary in order to make the software
implementable.  By having software released and in use, we have the
opportunity to assess in what ways a policy is needed to be more flexible
and relaxed yet still afford us the required safety.

I suggest this be done to the document.  I would like a note to be added to
the introduction that states that this draft "defines a first-cut policy.
It is anticipated that the policy will be modified given operational
experience,"  or some such words to that effect.  I think this will deflect
some of the discussion that this policy may be too harsh for operations.

P.S. The section of RFC 2535 most affected by this is 6 (6.3.1), even more
so that 2.3.6 (as mentioned in the introduction).

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

"It takes years of training to know when to do nothing" - Dogbert

Opinions expressed are property of my evil twin, not my employer.

---

From: Thomas Narten <[email-masked]>
Date: Fri, 02 Jun 2000 11:49:23 -0400

> Standard, updating RFC2535

Both of these IDs would appear to be significant replacements of their
corresponding RFCs. Also, when a new RFC replaces on old one, its
expected to include a "Changes relative to RFC XXX" section in them to
help implementors understand what has changed. That might not make
sense here, i.e., is this replacement vs. changing.

Question: should either of the two RFCs actually be reclassified as
Historic, as opposed to just being obsoleted? If there is little or no
deployment and the point is to not have anyone implement the old RFCs,
reclassifying them to historic might be the way to go.

Thomas

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Fri, 02 Jun 2000 15:47:05 -0400

While draft-ietf-dnsext-simple-secure-update-01.txt replaces RFC 2137,
draft-ietf-dnsext-signing-auth-01.txt really just tweaks RFC 2535
which it is an order or magnitude shorter than.  

I suppose 2137 could be declared historic but I'm not sure I see the
point.  People are not supposed to implement obsoleted RFCs and there
are some elements of RFC 2137 in
draft-ietf-dnsext-simple-secure-update-01.txt.  I think of Historic as
being for a protocol that has fallen from use or been replaced by a
completely new protocol, not for a stage in the evolution of the same
protocol (although such judgements are no doubt in the eye of the
beholder).  I think someone reading
draft-ietf-dnsext-simple-secure-update-01.txt should have RFC 2137 for
comparison rather than having RFC 2137 already on the trash heap,
although I have no doubt that almsot all will still prefer the new
draft.

Donald

From:  Thomas Narten <[email-masked]>
Message-Id:  <[email-masked]>
To:  [email-masked]
In-Reply-To:  Message from The IESG <[email-masked]> 
	        of "Fri, 02 Jun 2000 08:34:25 EDT." <[email-masked]> 
Date:  Fri, 02 Jun 2000 11:49:23 -0400
Sender:  [email-masked]
Precedence:  bulk

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 06 Jun 2000 13:12:18 -0400

>sense here, i.e., is this replacement vs. changing.

"Domain Name System Security Signing Authority" is a minor update to RFC2535 
it restricts the set of keys that can sign DNS data to zone keys at APEX.
This is a great simplification that is only possible as RFC2137 is obsoleted
by the other draft.  RFC2137 requires that other keys can sign data. 

Both documents contains in section 1 list of obsoleted RFCs and sections 
affected, but that should be broken out into "Changes .... " sections. 

>reclassifying them to historic might be the way to go.

I thought Historic status is reserved for documents that are not replaced by
any other document. But in this case the protocol change is significant 
enough to warrant moving RFC2137 to historic and consider the new one a 
new protocol ? 
But my vote is to obsolete rather than move to historic. 

	Olafur

---

From: Thomas Narten <[email-masked]>
Date: Wed, 07 Jun 2000 17:10:28 -0400

> "Domain Name System Security Signing Authority" is a minor update to
> RFC2535 it restricts the set of keys that can sign DNS data to zone
> keys at APEX.  This is a great simplification that is only possible
> as RFC2137 is obsoleted by the other draft.  RFC2137 requires that
> other keys can sign data.

Having now dug deeper (as I should have done before sending my first
note!), I agree that 2535 is just updated.

> enough to warrant moving RFC2137 to historic and consider the new one a 

Take a look at 2026 for guidelines. The paragraph I find most
compelling here is:

> 6.4  Retiring a Standard
> 
>    As the technology changes and matures, it is possible for a new
>    Standard specification to be so clearly superior technically that one
>    or more existing standards track specifications for the same function
>    should be retired.  In this case, or when it is felt for some other
>    reason that an existing standards track specification should be
>    retired, the IESG shall approve a change of status of the old
>    specification(s) to Historic.  This recommendation shall be issued
>    with the same Last-Call and notification procedures used for any
>    other standards action.  A request to retire an existing standard can
>    originate from a Working Group, an Area Director or some other
>    interested party.

If the message we want to send is "don't implement 2137",
reclassifying it as historic would seem stronger.

"Donald E. Eastlake 3rd" <[email-masked]> writes:

> I think of Historic as being for a protocol that has fallen from use
> or been replaced by a completely new protocol, not for a stage in
> the evolution of the same protocol (although such judgements are no
> doubt in the eye of the beholder).

Reclassifying a document historic is also done to send a
message. I.e., RIP version 1 was reclassified to historic despite
widespread use precisely because RIP version 2 was what we wanted
folks to implement.

> I think someone reading
> draft-ietf-dnsext-simple-secure-update-01.txt should have RFC 2137
> for comparison rather than having RFC 2137 already on the trash
> heap, although I have no doubt that almsot all will still prefer the
> new draft.

What I'm hearing from these messages is that we don't want to give
implementors a choice as to which to implement. We want them to
implement the new ID. Reclassifying the document historic doesn't
prevent people from reading it.

Thomas