Progress Of the DNS Security Extensions

1. Progress Of the DNS Security Extensions NANOG 22 May 21-22, 2001 Edward Lewis lewis@tislabs.com

2. Purpose of this talk • DNS Security is a set of extensions to DNS to make attacking it harder and using it to attack other applications harder • Over the course of the past two years, hands-on workshops have been held to help accelerate standards development • This presentation will cover lessons learned, open issues, and the progress being made

3. Background • DNS Security presentation at NANOG 19 • http://www.nanog.org/mtg-0006/lewis.html • Workshops are fairly unique in the IETF process • Only one available source of s/w, so no bake-off's • Multi-day events in which a mini-DNS world is built • Objective of Workshops • Education • Testing Specification & Software • Examination of inter-administration issues

4. Recent Workshops • APRICOT 2001 - Kuala Lumpur, February • 49th IETF - San Diego, December • NANOG 20 - Washington, DC, October • RIPE 37 - Amsterdam, September • 2nd DNSSEC workshop - Vasby (SE), September • RSSAC workshop - Pittsburgh, July

5. Highlights • Realization that DNS Security isn't one piece • Components advancing at different rates • Some parts are ready to pay off now • Progress is being made on the inter-zone interface • Defining this is a prime goal of the workshops • Active discussions happening, consensus is forming • Good news is the frequency and dispersion of dialog

6. Workshop Configuration • Workshop consists of about a half-dozen "experts" and about 2 dozen students • set up includes an "augmented" DNS root, a workshop top-level domain, other services (ftp, http) • Students set up zones as delegated from a TLD created for the workshop • Students also set up secondary relationships • Initial round of keys and signatures, then a key change

7. Highlights of Vasby Workshop • The second workshop held in Sweden • Invitation-only 2-day workshop, very organized, knowledgeable DNS students • Keys were set up, validation done via a simplistic HTML set-up • The workshop keys were changed causing problems • "Lateral" signing requirement formalized

8. Highlights of NANOG 20 Wkshp • One day workshop, with "homework assignments" • Different HTML interface used to exchange keys • Not as successful • The interface should not be under estimated • Lateral signing still not implemented

9. Highlights of 49th IETF Workshop • Mixture of IPv6 and DNS Security • Trying to teach/understand both concepts in one event is difficult • Impact of DNS Security on A6 chains • multiplied by length of chain • Until name server resolvers can handle A6 chains and/or AAAA, IPv6-only infrastructure is not possible • Desire to run a longer-term experiment

10. Highlight of APRICOT 2001 Wkshp • Rapid maturation of TSIG mechanism • Re-organization of material into "easy" and "hard" • TSIG easy • KEY/SIG hard • Use of TSIG configuration language extended to other services • e.g., BIND's remote name server daemon control (rndc)

11. Result: Shared secret Clearer • TSIG has become mature • Zone transfers can be protected • Lays the ground work for authorized dynamic update • Same language reused to secure non-TSIG services, e.g., rndc • Perhaps time to revisit TKEY and SIG (0) now that TSIG has come of age

12. Result: Operational Experience • Well, "initial operational experience" • More and more operators are now participating • Recent discussions have involved a wide spread of people and organizations • still mostly in Europe • Many past decisions are being revisited now that more experts are available

13. Result: Value of Key Distribution • The feature of publishing keys in DNS has grown in importance • Putting application keys in DNS • Could be a big driver behind DNS Security

14. Result: Better Implementation • With each workshop, software bugs have lessened • DNS Security code is still bleeding edge • Specifications aren't always clear and are being reviewed

15. Issue: Parent holding of signature • When a parent zone's key changes, all child zone key( set)s need to be validated again • Parent needs child key sets to do this • Parent has to make new signature known • Original thought was to have this happen with the child being responsible for publishing data • But this means child has to be aware of key change - or suffer the consequences • Proposal now to have parent publish data

16. Issue: Application keys • With parent signing and holding keys, what is the impact on application keys? • Some zones use the apex as a host (A record, etc.) • IPSEC, SSH, et.al. host keys would be co-located with the zone keys • Should parent zone be signing host key data for child? • Other issues: subtyping, message size

17. Issue: Persistent Testing vs. Fake Roots • The parent-child interface in DNS Security is evident in time-related SIG RR's • One-time set up of KEY's and SIG's is easy, it is the "roll over" that is the headache • The only way to test this is to allow time to pass • DNS Security testing has depended on a workshop root • What's the difference between a persistent test root server and an "alternate" root server

18. Issue: Another Angle on Persistence • One other need for a persistent test infrastructure • Strict "on-tree" zone signing depends on an entirely available DNS • There are proposals to make DNS Security more robust in the face of downed servers • Collaborative signing experiments need time to develop

19. Issue: lwresd vs stub-resolver • lwresd is a BIND creation, a name server running locally, replacing the old stub resolver • Perhaps lwresd runs as a caching forwarder • How does this impact the use of TSIG to secure queries and responses, as opposed to configuring public keys? • Original issue was the protection of the TSIG secret on a multi-user machine for general lookups • /etc/resolv.conf is a natural place for secret, but "world" readable (using UNIX as an example)

20. Issue: Multiple Implementations • For the DNS Security documents to progress in the IETF, multiple interoperable implementations are needed • Besides BIND, there are some other implementations in the works • Will they implement all of DNS Security? • Will they be made available for testing?

21. Issue: Legal Attention • For better or worse, lawyers have taken notice • Impact of contract law on key distribution service • Work is bring pioneered in Sweden, with contact with the Netherlands and Germany • Interesting twist • Laws are national things, the Internet is defined across boundaries • IETF avoids technology that is law-specific • What is the legal view of a server in .se and a resolver in .de?

22. Unstudied • How "joint" administrations of a zone will work • Issues that are cryptographic in nature • Impacts of key lengths on security • Life span of a key • Issue was raised during the RSSAC workshop

23. Document Status • A new round of documents is being prepared • Same standards level • A reorganization to include the current base plus the clarification RFCs

24. Current Discussion Forums • dnssec@cafax.se • A mailing list that has been around a while, recently has become quite active • namedroppers@ops.ietf.org • ietf-dnsop@cafax.se