Subject: I-D ACTION:draft-ietf-dnsext-dnssec-trans-02.txt

From: [email-masked]
Date: Wed, 23 Feb 2005 15:33:45 -0500

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		: Evaluating DNSSEC Transition Mechanisms
	Author(s)	: R. Arends, et al.
	Filename	: draft-ietf-dnsext-dnssec-trans-02.txt
	Pages		: 15
	Date		: 2005-2-23
	
This document collects and summarizes different proposals for
    alternative and additional strategies for authenticated denial in DNS
    responses, evaluates these proposals and gives a recommendation for a
    way forward.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-trans-02.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-dnssec-trans-02.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-trans-02.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: Peter Koch <[email-masked]>
Date: Thu, 24 Feb 2005 22:37:52 +0100

> 	Filename	: draft-ietf-dnsext-dnssec-trans-02.txt

Changes include some editorial comments, some references and a new "method".
Some comments have been read but not yet incorporated, including those from

Sam: you said in November that you hadn't done an in depth review. Nevertheless
  you suggested another "dead end" to be added (DS hash based; I'd be happy
  to learn the details, but pls see below)

Mark: details for the SIG(0) approach and its drawbacks need to be added

Miek: The "new" method is basically what went into the "BERT" draft.

This document needs one other round before it hopefully can go to WG LC. My
plan is to do this editing round in and shortly after MPLS. Since it is
mostly intended to document the collection of ideas on the table when the WG
decided to proceed with -bis as is, it's not necessary to find more 
alternatives, but instead to go back in time a bit and improve the description
and assessment of those already in the draft.

-Peter

--
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: Samuel Weiler <[email-masked]>
Date: Mon, 28 Feb 2005 15:21:15 -0500 (EST)

The sections I commented on in -01 seem largely unchanged in -02, so
the same comments apply.  See:
http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg02097.html

I also noticed that 2.2.3.2 suggests splitting the algorithm space
with each version of DNSSEC.  As David Blacka's experiments draft
suggests, there might be more efficient ways to do this, and blindly
allocating half of the algorithm numbers at each versioning sounds
very limiting.

>   to learn the details, but pls see below)

Essentially: rather than change DNSKEY algorithms, change DS message
digest algorithms (or: use message digest algorithms as a signaling
mechanism).  Any resolver that doesn't understand the new message
digest number wouldn't be able to use that DS anyway.

http://darkwing.uoregon.edu/~llynch/dnsop/msg03203.html

-- Sam