To:
dnssec@cafax.se
Cc:
lewis@tislabs.com
From:
Edward Lewis <lewis@tislabs.com>
Date:
Tue, 4 Dec 2001 13:44:30 -0500
Sender:
owner-dnssec@cafax.se
Subject:
Where are we (metaphorically speaking)?
I want to start a collection of the threads being pursued in the area, so we can judge importance, not just progress. IMHO, securing the tree is the first thing we need, although support for application keys is a big driver. The following is a list of issues and catagories. The ordering of the categories is how I see the importance of each. The relative placement of the issues withing the category is only somewhat sorted by importance, e.g., in "other" the issues are listed as they came to mind. Are any issues missing or mis-sorted? 1) Securing the tree Issue #1 Indicating parent validation of child. This is RFC2535's sig@child vs. DS RR, and at one time sig@parent. DS RR drafts are being produced, and prototype code is being debugged. Issue #2 Parent-Child key interface. A couple of folks have been talking about this. One of the debates is whether keys (or references thereto) travel in-DNS-band or out-of-DNS-band. Issue #3 Adoption approaches. This refers to unsigned records and "opt-in." Haven't heard a lot on this in recent months. 2) Support for applications Issue #4 Application/Non-DNS public key distribution. We know that KEY is insufficient for at least SSH. APPKEY is an improvement, but is it sufficient? IPsec is emerging as a protocol that can benefit from DNS security enhancements. An effort has begun to identify key distribution needs of other protocols to determine if and how DNS can help (basically by answering whether APPKEY is sufficient). Issue #5 Interpretation of DNS results. Basically a need to state what DNS validation means, and what the fallbacks are when answer fail to validate. Not all applications will want hard failures, some will. What helps here is an annotated validator (kind of like dig for DNSSEC). Some first-ste implementations of this exist. 3) Operational considerations Issue #6 Distribution of trusted keys to resolvers. How are the configured trusted keys changed in resolvers throughout a realm? Olaf's draft. Issue #7 Root zone key management issues. (Root server engineers.) 4) Other Issue #8 Updating crypto-specifications. I.e., change from HMAC-MD5 to HMAC-SHA-1, updates to DSA and Diffie Hellman. Issue #9 Maturation of TKEY and SIG(0). One draft has appeared in this area. Issue #10 DNSSEC interactions with Dynamic Update. Resigning zone data that hasn't been refreshed versus dropping data with expired signatures. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Opinions expressed are property of my evil twin, not my employer.