Software Pieces for the DNSSEC-deployment roadmap

1. Software Pieces for the DNSSEC-deployment roadmap SPARTA, Inc. 01/21/05

2. How can we identify software pieces? • Two approaches • One looks at the “big” picture • One breaks the problem into parts

3. Identifying software pieces –The “Forest” approach • Addresses Immediate/Short-term/Long-term software needs • Focuses on timeliness of software availability • Divided into following categories of software • Essential Functionality • Proof-Of-Concept applications • Zone maintenance • Key Management • Tool Suites • Policy • Real-world applications relying on DNSSEC

4. Essential Functionality (EF) • Validation Module (VAL) • Would provide a better understanding of the validation process in terms of the allowable states, error values and configuration knobs • Would form the basis of defining the API between the application and the security aware resolver • Would create heterogeneity in the available code base for validation modules • Would providing a useful test suite to test correctness and interoperability between multiple name serverimplementations • Would provide the basis for a good end user troubleshooting utility.

5. Proof-of-concept Applications (POC) • Mail Transfer Agent (MTA) • Signed SPF records to guard against spoofed values • Terminate connections before spam is sent • Web Browser (WB) • User interface for DNSSEC • Obtain “buy-in” from OS vendors

6. Zone Maintenance (ZM) • Zone operation tools (ZOP) • That assist operators in the day to day operation of their zones, including operations such as zone transfer, zone signing and zone changes (static and dynamic). • Log-based tools (LT) • That consume the log information generated by various tools in order to allow the operator to get a better sense of errors and abnormalities in the DNS configuration. • Zonefile-based tools (ZT) • That allow the operator to check their zonefiles for correctness. This might also include enhancements to existing tools to make them more DNSSEC-aware. • Query-based tools (QT) • That allow the operator to perform additional sanity checks on the DNS data, checking for availability and security of their own domains from different/external views for different for different trusted keys. • Watchdog/Notification tools (WNT) • That can be used for tracking important events (such as expiry of signatures). They would also form the framework for a more comprehensive incident detection and notification module.

7. Key Management (KM) • Zone Owner tools (ZO) • For creating, storing and rolling over keys. Also symmetric key management for zone transfers • Parent-child tools (PC) • For managing the interaction between the parent and child zones while creating and maintaining signed delegations • Trusted-key tools (TK) • For managing trusted keys at the end resolvers, and at trusted key “distribution points” • Last-hop security tools (LH) • Secure-channel construction tools • Registry-Registrar-Registrant (RRR) • Software that implements EPP extensions

8. Tool Suites (TS) • Zone Maintenance (ZM) • A configuration mechanism to define the "operation profile" for DNSSEC. • There will be multiple ways to manage the DNS. • The operator should be given the flexibility of choosing the manner in which each of the various constituent operations are performed. • Visualization (VIS) • These tools would provide visual indicators for the "health" of DNSSEC or even the "security posture" of the enterprise with respect to DNS. • Troubleshooting (TR) • Aggregation of indicators and logs from various tools to give a unified view of DNSSEC events. • Being able to look at problems from multiple looking glasses can assist in troubleshooting operations.  • This task would involve defining a unified logging format for all components ability to correlate notification/output from different components

9. Policy (POL) • Key Management (KM) • This tool would provide a consistent interface for the definition of key-related parameters. • Related tasks would be identifying typical enterprise and registry policies for keys • Single Resolver (SR) • This tool would provide a consistent interface for specifying all the knobs that can be defined for a validator. • These knobs are sometimes explicit (such as trust anchors) or might be implicitly defined (unspecified or underspecified) in the DNSSEC specification. • Enterprise (ENT) • This tool would provide a consolidated interface for specifying enterprise-wide policy for DNSSEC. Predefined "policy profiles" would include those for "typical enterprises" and "typical registries". • The tool would assist the operators in making better choices for various parameters by providing some kind of feedback on the implications of a particular change. • At the other end of the spectrum, a similar tool would be used to check if some configuration complies with "organizational policy".

10. Software needs - Timeline Immediate Short-term Long Term

11. Identifying Software Pieces – The “Trees” approach • Identify all operational pieces that interoperate to make DNSSEC “work” • For each operational piece identify all available and missing pieces not only for software, but also documentation, policy, training and roles • Operational pieces can be enumerated by breaking all the DNS operations into “procedural flows” • “Procedural flows” was described in an earlier version of the roadmap • Slow progress in building the complete list of procedural flows – characteristics of some flows are still being identified by the community

12. Procedural Flows • Nineteen flows had been identified earlier • Lookup • Registration • Enterprise Delegation • Trusted key configuration • Zone Transfer, Zone maintenance • ZSK Roll-over • KSK Roll-over • Root Zone Setup/Signing • Root Zone Signing Key Change • Root Key Signing Key Change • Registrant Change • Registrar Change • Registry Change • TLD delegation cycle (is this different – interaction with root) • TLD zone maintenance (is this different) • TLD key rollover (is this different – interaction with root) • Inverse tree procedures (same as TLD procedures?) • Trust anchor distribution (inline, DLV etc) • The above flows will change as our understanding of the different organization types improves (.arpa procedures, types of registries, types of registrants, etc)

13. Some of the software pieces identified using the “trees” approach • DNSSEC-aware applications • Resolver library implementing the resolver-application API • Last-hop channel security: key management tools, secure channel construction tools • Validation module • Recursive Name server functionality • Authoritative name server functionality • Name server maintenance tools • Key-set/DS-set creation tools • Tools for securely communicating zone information to parent (or parent-like entity) • Tools for verifying the correctness of delegation information • Tools that aid in trusted key roll-over • Tools that aid in trusted key addition and deletion • Zone transfer: functionality, secure channel construction, key management • Zone maintenance: Zone creation/modification, zone update, zone checking tools • Key generation tools: for zones, dynamic update, last hop, online signing • Key roll-over tools • Dynamic update: functionality in name servers, incremental signing of zones, tools that can provide the interface for dynamic updates, secure channel construction and key management for dynamic updates • Troubleshooting tools • Watchdog and notification tools • Incident detection and response tools