Subject: [DNSOP] (fwd) I-D ACTION:draft-larson-dnsop-trust-anchor-00.txt

From: Matt Larson <[email-masked]>
Date: Mon, 15 Jan 2007 20:02:46 -0500

Dear colleagues,

I would like to please call your attention to a new Internet-Draft,
which Olafur and I volunteered to write.  The motivation for the work
came out of the DNSSEC Deployment Initiative (please see
http://www.dnssec-deployment.org/), which some of you may be familiar
with.

We would be grateful for your review and feedback.

Thanks,

Matt (and Olafur)

----- Forwarded message from [email-masked] -----

From: [email-masked]
Subject: I-D ACTION:draft-larson-dnsop-trust-anchor-00.txt 
To: [email-masked]
Cc: 
Date: Fri, 12 Jan 2007 18:50:01 -0500

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: DNSSEC Trust Anchor Configuration and Maintenance
	Author(s)	: M. Larson, O. Gudmundsson
	Filename	: draft-larson-dnsop-trust-anchor-00.txt
	Pages		: 14
	Date		: 2007-1-12
	
   This document recommends a single preferred format for specifying
   trust anchors in DNSSEC validating resolvers and describes how the
   validating resolver should initalize the trust anchor for use upon
   start-up.  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-larson-dnsop-trust-anchor-00.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-larson-dnsop-trust-anchor-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-larson-dnsop-trust-anchor-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.

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

----- End forwarded message -----

_______________________________________________
DNSOP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dnsop

---

From: Edward Lewis <[email-masked]>
Date: Tue, 16 Jan 2007 09:40:14 -0500

>http://www.ietf.org/internet-drafts/draft-larson-dnsop-trust-anchor-00.txt

What is a trust anchor?  Is it a domain name or is it a specific key 
at a domain name?  The question comes up when you mention that it 
should be a DR RR.  Or should that be an RR set?

This line is out of context: "DS RRs using SHA-1 (DS digest type 1) 
are NOT RECOMMENDED."  When talking about the format, don't dive into 
contents as such "don't use" recommendations will change (grow) over 
time.

I don't know if priming, as described in section 3, is best done at 
start up, but rather "on demand."  As sparse as the DNSSEC portion of 
DNS will be, I bet a DNSSEC-intense resolver will have a trust anchor 
list a kilometer long.

The TBD at the end of section 3: I don't know that any document ought 
to prescribe any actions (such as log errors) when inconsistencies 
are found.  That is a matter left to the implementations.  The 
document should explain the inconsistencies, but not dictate a 
reaction.  Local policy is still the trump card.

The discussion on trusted update mechanism should be pulled. 
Mentioning trademark names and products is probably not worth the 
trouble.  Also, what is being said is that "there are a number of 
non-interoperable ways to do this that are in use, they can be used." 
As we are all about interoperability, what's the point?  This is akin 
to there being only a definition for AXFR when we know there are many 
implementation specific zone transfer mechanisms out there - we don't 
have a document that lists them.

As far as the in-band mechanism:

"This protocol is capable of keeping trust anchors up to date 
indefinitely if the trust anchor zone's operator follows the proper 
procedures" and the minor protocol change is made.  The text isn't 
clear on whether the minor change is "in effect" or something that 
has to yet happen.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Dessert - aka Service Pack 1 for lunch.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 16 Jan 2007 09:40:14 -0500

---

From: Geoff Huston <[email-masked]>
Date: Thu, 18 Jan 2007 17:20:22 +1100

>should be a DR RR.  Or should that be an RR set?

The wording in section 2 is very confusing. Is a trust anchor as DS 
RR or a DNSKEY RR? Or, as Ed points out, is it the RR set? The 
document appears to say "both", but then proceeds as if it had said "DS RR".

The comment about truncation appears to be a martian, in that 
truncation is neither defined nor referenced here and the reader is 
left somewhat confused as to what is meant here.

>are NOT RECOMMENDED."  When talking about the format, don't dive 
>into contents as such "don't use" recommendations will change (grow) over time.

agreed

>start up, but rather "on demand."  As sparse as the DNSSEC portion 
>of DNS will be, I bet a DNSSEC-intense resolver will have a trust 
>anchor list a kilometer long.

On demand  (or upon use) would be more logical in this context. Also 
I note that somehow the document has changed gear and now we are 
talking about DS RRs as trust anchors. What happened to DNSKEY RRs?

>The TBD at the end of section 3: I don't know that any document 
>ought to prescribe any actions (such as log errors) when 
>inconsistencies are found.  That is a matter left to the 
>implementations.  The document should explain the inconsistencies, 
>but not dictate a reaction.  Local policy is still the trump card.

I also would've thought that where inconsistencies are found between 
the DS and DNSKEY values are found then they should not longer be 
considered as viable trust anchors.

>non-interoperable ways to do this that are in use, they can be 
>used." As we are all about interoperability, what's the point?  This 
>is akin to there being only a definition for AXFR when we know there 
>are many implementation specific zone transfer mechanisms out there 
>- we don't have a document that lists them.

I had a similar reaction to all but DNSSEC in-band Update.

>clear on whether the minor change is "in effect" or something that 

Surely all this could be better phrased as an applicability note for 
the DNSSEC In-Band Update specification?

Or is the point of this document the algorithm described in section 2?

regards,

   Geoff

---

From: Geoff Huston <[email-masked]>
Date: Thu, 18 Jan 2007 17:20:22 +1100

agreed

regards,

   Geoff

---

From: Scott Rose <[email-masked]>
Date: Thu, 18 Jan 2007 07:45:21 -0500

>> should be a DR RR.  Or should that be an RR set?

I think it should be RRset, but for the vast majority of cases, there 
will only be one RR per RRset (thinking realistically).

>> contents as such "don't use" recommendations will change (grow) over 
Agree also - I can't think of the harm in using SHA-1.  It isn't really 
needed for security of the key material, and the hash size is smaller 
and easier to manually enter (if necessary).

>> DNS will be, I bet a DNSSEC-intense resolver will have a trust anchor 

On start up of system, or of the validator?

As for the text on rollover mechanisms: I don't think there will be a 
choice for the majority of end systems.
Once the validator is written, it will most likely depend on the 
implementors of the validator, and be very difficult for an end user to 
change.  Manual operation may be the only other alternative to whatever 
in-band or out of band the validator implementation is built around. 
And most will not care - once one way is chosen, it will probably be 
used unless something forces a change.

Scott

---

From: Scott Rose <[email-masked]>
Date: Thu, 18 Jan 2007 07:45:21 -0500

Scott

---

From: Edward Lewis <[email-masked]>
Date: Thu, 18 Jan 2007 08:44:47 -0500

>On start up of system, or of the validator?

Does it need to be specified, I think it is an implementation detail 
and unimportant to interoperability.

>As for the text on rollover mechanisms: I don't think there will be a choice
>for the majority of end systems.
>Once the validator is written, it will most likely depend on the implementors
>of the validator, and be very difficult for an end user to change.  Manual
>operation may be the only other alternative to whatever in-band or out of band
>the validator implementation is built around. And most will not care - once
>one way is chosen, it will probably be used unless something forces a change.

There's two ways to read this.  One is that the service-side "user" 
that has a choice to make when introducing a new KSK/SEP.  The 
client-side "user" has a choice when adopting the new KSK/SEP.

The service-side needs to know how to indicate the new KSK/SEP is the 
one to use, possibly in more than one way but ideally there is one 
set of ways.  The validator has to implement a (or the) way to learn, 
and the client-side user will either have to live with that or use a 
validator that offers choices.

Probably in operations there won't be an option.  The sole option 
will be set down in the validation code.  I think it is a good idea 
to nail down the algorithm that all validators will implement. 
Ideally we will also nail down as many parameters too, as experience 
I have had has shown that choice in security knobs is a bad thing to 
anyone not a security geek.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 18 Jan 2007 08:44:47 -0500