comments on dnssec-experiments
Edward Lewis <Ed.Lewis@neustar.biz> Mon, 27 March 2006 18:42 UTC
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNwg3-0004UU-7O for dnsext-archive@lists.ietf.org; Mon, 27 Mar 2006 13:42:55 -0500
Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNwg2-0003JC-Rg for dnsext-archive@lists.ietf.org; Mon, 27 Mar 2006 13:42:55 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1FNwcV-000JVd-EZ for namedroppers-data@psg.com; Mon, 27 Mar 2006 18:39:15 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level:
X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1
Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from <Ed.Lewis@neustar.biz>) id 1FNwcU-000JVP-EI for namedroppers@ops.ietf.org; Mon, 27 Mar 2006 18:39:14 +0000
Received: from [10.31.32.110] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k2RIcxJQ070545; Mon, 27 Mar 2006 13:38:59 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz)
Mime-Version: 1.0
Message-Id: <a06200700c04de0d28bf9@[10.31.32.110]>
Date: Mon, 27 Mar 2006 13:39:12 -0500
To: namedroppers@ops.ietf.org
From: Edward Lewis <Ed.Lewis@neustar.biz>
Subject: comments on dnssec-experiments
Cc: ed.lewis@neustar.biz
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Pendantic comments left in just to show that I did review the doc. (Count me in, doc.) Quoting from: http://ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-experiments-02.txt # DNSEXT D. Blacka # Internet-Draft Verisign, Inc. # Expires: August 27, 2006 February 23, 2006 # # DNSSEC Experiments # draft-ietf-dnsext-dnssec-experiments-02 # Abstract # In the long history of the development of the DNS security extensions # [1] (DNSSEC), a number of alternate methodologies and modifications # have been proposed and rejected for practical, rather than strictly # technical, reasons. There is a desire to be able to experiment with # these alternate methods in the public DNS. This document describes a # methodology for deploying alternate, non-backwards-compatible, DNSSEC # methodologies in an experimental fashion without disrupting the # deployment of standard DNSSEC. I think abstracts can be free of references (the "[1]" thing). # 1. Definitions and Terminology # The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", # "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this # document are to be interpreted as described in RFC 2119 [5]. Reference 5 ought to be normative then, right? # 4. Method # While this behavior isn't strictly mandatory (as marked by MUST), it # is unlikely that a validator would not implement the behavior, or, # more to the point, it will not violate this behavior in an unsafe way # (see below (Section 6).) Please restate this with fewer negatives. ;) "It is likely that a validator would implement" for example. Makes reasoning easier. (Yes - an extremely pedantic comment...) # 5. Defining an Experiment # In general, however, resolvers involved in the experiment are # expected to understand both standard DNSSEC and the defined # experimental DNSSEC protocol, although this isn't required. A resolver can also understand *multiple* experiments as well as stock DNSSEC. (Right?) # 6. Considerations # 2. It will not be possible for DNSSEC-aware resolvers not aware of # the experiment to build a chain of trust through an experimental # zone. "not be possible" & "not aware." # 8. Security Considerations # # Zones using this methodology will be considered insecure by all # resolvers except those aware of the experiment. It is not generally # possible to create a secure delegation from an experimental zone that # will be followed by resolvers unaware of the experiment. Hmmm. While I think that establishing an experiment in this way looks promising, the teardown might be problematic. (Maybe we need an exit strategy. ;)) (Section 7, elided, is on transitions. Haven't thought what to say about that.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/>
- comments on dnssec-experiments Edward Lewis