progress of the dns security extensions nanog 22 may 21-22, 2001 edward lewis [email protected]
TRANSCRIPT
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
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)
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?
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?
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
Document Status A new round of documents is being prepared
Same standards level A reorganization to include the current base plus the
clarification RFCs
Current Discussion Forums [email protected]
A mailing list that has been around a while, recently has become quite active