Subject: Protocol Action: 'DNS Name Server Identifier Option (NSID)' to Proposed Standard

From: The IESG <[email-masked]>
Date: Fri, 15 Jun 2007 10:15:53 -0400

The IESG has approved the following document:

- 'DNS Name Server Identifier Option (NSID) '
   <draft-ietf-dnsext-nsid-02.txt> as a Proposed Standard

This document is the product of the DNS Extensions Working Group. 

The IESG contact persons are Mark Townsley and Jari Arkko.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsid-02.txt

Technical Summary
 
   In order to be able to identify certain nameservers in a DNS
   anycast cloud clients querying nameservers in that cloud can add an
   EDNS OPT pseudo RR that signals the answering nameservers to
   include identifying information in an OPT RR that is attached to
   the answer.

   This technique improves the existing ad-hoc methods to identify
   nameservers.
 
Working Group Summary
 
   Working group consensus is solid. During the working group
   discussions the question came up to also allow for client to server
   identification. This was argued to be out of scope.
 
Protocol Quality
  
   This document was reviewed by Peter Koch, David Conrad, Sam Weiler, 
   Paul Vixie, Mark Andrews, Francis Dupont, Olaf Kolkman, Thomas Narten
   and Mark Townsley.

   This feature will be implemented in at least two independent
   open-source products used on anycasted root-servers. And will be
   available in at least one resolver implementation and become
   available in two libraries.

Note to RFC Editor

Please add the following new text. The first chunk is in the discussion
of NSID payload, the second is in the Security Considerations section. The
diff is taken from the xml source.

@@ -310,6 +310,25 @@
               constellation identify themselves as "My Name Server" would

               not be particularly useful.
             </t>
+            <t>
+              A signed blob is not particularly useful as NSID payload
+              unless the signed data is dynamic and includes some kind
+              of replay protection such as a timestamp or some kind of
+              data identifying the requestor.  Signed blobs that meet
+              these criteria could conceivably be useful in some
+              situations but would require detailed security analysis
+              beyond the scope of this document.
+            </t>
+            <t>
+              A static encrypted blob would not be particularly
+              useful, as it would be subject to replay attacks and
+              would, in effect, just be a random number to any party
+              that does not posess the decryption key.  Dynamic
+              encrypted blobs could conceivably be useful in some
+              situations but, as with signed blobs, dynamic encrypted
+              blobs would require detailed security analysis beyond
+              the scope of this document.
+            </t>
           </list>
         </t>
         <t>
@@ -467,6 +486,18 @@
         the NSID option content up to the implementation and the name
         server operator.
       </t>
+      <t>
+        Two of the possible kinds of payload data discussed in <xref
+        target="nsid-payload"/> involve digital signature and
+        encryption, respectively.  While this specification discusses
+        some of the pitfalls that might lurk for careless users of
+        these kinds of payload data, full analysis of the issues that
+        would be involved in these kinds of payload data would require
+        knowledge of the content to be signed or encrypted, algorithms
+        to be used, and so forth, which is beyond the scope of this
+        document.  Implementors should seek competent advice before
+        attempting to use these kinds of NSID payloads.
+      </t>
     </section>

--
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/>