Subject: [DNSOP] I-D Action:draft-ietf-dnsop-dnssec-trust-anchor-01.txt

From: [email-masked]
Date: Mon, 11 Feb 2008 08:00:01 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations Working Group of the IETF.

	Title           : DNSSEC Trust Anchor Configuration and Maintenance
	Author(s)       : M. Larson, O. Gudmundsson
	Filename        : draft-ietf-dnsop-dnssec-trust-anchor-01.txt
	Pages           : 14
	Date            : 2008-02-11

This document recommends a preferred format for specifying trust
anchors in DNSSEC validating security-aware resolvers and describes
how such a resolver should initialize trust anchors for use.  This
document also describes different mechanisms for keeping trust
anchors up to date over time.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsop-dnssec-trust-anchor-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-dnsop-dnssec-trust-anchor-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-dnsop-dnssec-trust-anchor-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.
_______________________________________________
DNSOP mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/dnsop

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 19 Feb 2008 13:55:56 -0500

>         Filename        : draft-ietf-dnsop-dnssec-trust-anchor-01.txt

The changes since last version include, number of grammatical and English
improvements. Security considerations has been improved.

The editors think this document is ready for WGLC, please send in comments.

         thanks
         Matt & Olafur

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 19 Feb 2008 13:55:56 -0500

thanks
         Matt & Olafur

---

From: Suresh Krishnaswamy <[email-masked]>
Date: Wed, 20 Feb 2008 13:22:30 -0500

Some comments on draft-ietf-dnsop-dnssec-trust-anchor-01:

Section 2, last para

#                           A validating resolver MAY support
#configuration using a truncated DS hash value as a human-factors
#convenience: shorter strings are easier to type and less prone to
#error when entered manually.

There should be some guidance on the amount of truncation allowed.
For instance, can the DS hash be truncated to a single byte?
(I assume not)

-------------

Section 3 :

I don't understand the usage of the word "priming" here. The steps
that are described are *exactly* what would need to happen during
the normal DNSSEC validation process. I can see the need for priming
DNSKEYs when trust anchors are also configured as DNSKEYs (in
which case priming helps the validator determine if the configured
DNSKEYs are the same as the ones published) but I don't see the need
for priming DNSKEYs when the trust anchors are specified as DS
records. Or, are we instead saying here that DNSKEYs fetched through
the priming process will not be subject to TTL expiration (which,
I think, shouldn't be the case either)?

-------------

Also in Section 3, second-last para

# A validating resolver should remove a trust anchor
# that has been revoked as indicated by the REVOKE bit in the
# corresponding DNSKEY record as described in RFC 5011 [6].

We may not want to necessarily combine resolver behavior with
trust anchor management. The two are different tasks and can be
accomplished using different tools. I'd suggest simply deleting this
sentence and modifying the para to read:

"If there are multiple trust anchors configured for a zone, any one of
them is sufficient to validate data in the zone.  For this reason,
old trust anchors SHOULD be removed from a validating resolver's
trust anchor list soon after the corresponding keys are no longer
used by the zone, as described in RFC 5011 [6]."
_______________________________________________
DNSOP mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/dnsop

---

From: Suresh Krishnaswamy <[email-masked]>
Date: Wed, 20 Feb 2008 13:22:30 -0500

Section 2, last para

-------------

Section 3 :

-------------

---

From: Scott Rose <[email-masked]>
Date: Thu, 21 Feb 2008 08:34:40 -0500

> improvements. Security considerations has been improved.

Just an open suggestion, but should there be more text to clarify what 
happens when a zone intends to delete it's outstanding trust anchors and 
link its security through its parent by having a DS RR in the parent zone?

There is text in RFC 5011 on how a zone operator does this, but there 
isn't a lot of detail in this draft.  Worst case scenario is that the 
validator declares the zone responses bogus, which isn't good.

I agree with Suresh's comment about limiting truncation.  I don't have a 
good number in mind though. It is a good document otherwise.

Scott

-- 
----------------------------------------
Scott Rose            Computer Scientist
NIST
ph: +1 301-975-8439
[email-masked]

http://www-x.antd.nist.gov/dnssec
http://www.dnsops.gov/
-----------------------------------------
_______________________________________________
DNSOP mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/dnsop

---

From: Scott Rose <[email-masked]>
Date: Thu, 21 Feb 2008 08:34:40 -0500

Scott