NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 07-Nov-97
Chair(s):
James Galvin <galvin@commerce.net>
Security Area Director(s):
Jeffrey Schiller <jis@mit.edu>
Security Area Advisor:
Jeffrey Schiller <jis@mit.edu>
Mailing Lists:
General Discussion: dns-security@tis.com
To Subscribe: dns-security-request@tis.com
Archive: ftp://ftp.tis.com/pub/lists/dns-security
Description of Working Group:
The Domain Name System Security Working Group (DNSSEC) will ensure enhancements to the secure DNS protocol to protect the dynamic update operation of the DNS. Specifically, it must be possible to detect the replay of update transactions and it must be possible to order update transactions. Clock synchronization should be addressed as well as all of the dynamic update specification.
Some of the issues to be explored and resolved include
o scope of creation, deletion, and updates for both names and zones
o protection of names subject to dynamic update during zone transfer
o scope of KEY resource record for more specific names in wildcard scope
o use of or relationship with proposed expiration resource record
One essential assumption has been identified: data in the DNS is considered public information. This assumption means that discussions and proposals involving data confidentiality and access control are explicitly outside the scope of this working group.
Goals and Milestones:
Done |
|
Submit proposal for adding Security enhancements to DNS as an Internet-Draft. |
Done |
|
Update Internet-Draft on adding security enhancements to DNS. |
Apr 96 |
|
Submit Internet-Draft on Secure Dynamic Update |
Aug 96 |
|
Update Internet-Draft on Secure Dynamic Update. |
Dec 96 |
|
Submit Internet-Draft on ensuring security of dynamic update of DNS to IESG for consideration as a Proposed Standard. |
Internet-Drafts:
· Mapping Autonomous Systems Number into the Domain Name System
· Detached Domain Name System Information
· Zone KEY RRSet Signing Procedure
· The DNS Inverse Key Domain
· Storage of Diffie-Hellman Keys in the Domain Name System
· Domain Name System Security Extensions
· DSA KEYs and SIGs in the Domain Name System
· Storing Certificates in the Domain Name System
· Indirect KEY RRs in the Domain Name System
· DNSsec Authentication Referral Record (AR)
Request For Comments:
RFC |
Status |
Title |
RFC2065 |
PS |
Domain Name System Security Extensions |
RFC2137 |
PS |
Secure Domain Name System Dynamic Update |
Minutes of the Domain Name System Security (DNSSEC) Working Group
The DNSSEC Security Working Group met on December 9, 1997, with the following agenda:
I. Introduction
II. Implementation Status
III. Document
IV. What's Next
After a brief introduction, Olafur Gudmundsson gave a brief status report on the Trusted Information Systems reference implementation of the DNS security extensions.
TIS has to a large extent completed a prototype implementation of DNSSEC functionality. Some of these prototypes will be made available soon. TIS is working with ISC on integrating the changes into a not to distant version of BIND.
It is important to realize that SECURE DNS requires at least four tools:
1. Security aware nameserver (BIND)
2. Key generation tool
3. DNS zone signing tool
4. Security aware resolver
Currently there are research prototypes of all of these tools developed, with the exception of some of the secure resolution in the nameserver. We will be working with ISC on how best to integrate the lessons from the secure resolver work into the nameserver without breaking a number of things.
TIS has started an implementation of the SECUPD draft.
Paul Vixie reported briefly on the status of DNS security extensions in Bind indicating that ISC will incorporate the TIS prototype into BIND as soon as feasible. John Gilmore has worked out a deployment strategy, which will allow a minimally security aware server to be released soon with a fully security aware server to follow later.
The remaining bulk of the meeting was devoted to the 12 documents currently being reviewed. Seven of these documents are currently in Working Group Last Call, which closes on December 19. The following six of them will be eligible to be submitted to the IESG for consideration as Proposed Standards if no significant technical issues are raised prior to the end of the Last Call:
draft-ietf-dnssec-secext2-02.txt
draft-ietf-dnssec-dhk-01.txt
draft-ietf-dnssec-dss-01.txt
draft-ietf-dnssec-ddi-02.txt
draft-ietf-dnssec-certs-01.txt
draft-ietf-dnssec-indirect-key-01.txt
Most of these documents will have one additional version issued that includes a few minor editorial changes. In addition, the IETF policy requires that unencumbered technologies must be the default, or mandatory to implement, whenever they exist and meet the necessary requirements. As a result, the revision to RFC2065, draft-ietf-dnssec-secext2-02.txt, will be changed to mandate the use of DSS as specified by draft-ietf-dnssec-dss-01.txt. It was left to the discretion of the author as to whether to merge the two documents or instead to separate the RSA specification from draft-ietf-dnssec-secext2-02.txt into a separate document.
The remaining last call document, draft-ietf-dnssec-as-map-05.txt, has been removed from consideration for publication because two questions were raised. First, who will "own" and "manage" the "map-as.arpa" namespace? Second, are certain the routing area has a need for this specification and will use it? The agreed upon action was to remand this document to the routing area.
Of the five remaining documents, it was agreed to remove draft-ietf-dnssec-in-key-00.txt from review. The following 4 documents are still under review by the working group:
draft-ietf-dnssec-key-handling-00.txt
draft-lewis-dnssig-authorization-00.txt
draft-lewis-dnsnxt-semantics-01.txt
draft-ietf-dnssec-ar-00.txt
Time did not permit significant discussion of these documents. The first three of them affect the operational behavior of the secure DNS and are priority work items; everyone is encouraged to review them. The last represents a potential new work item; its author is looking for individuals with whom to experiment.
None Received