Transcript Getting Your Foot in the Door or Selling Sniffer Basic

Progress Of the DNS Security
Extensions
NANOG 22
May 21-22, 2001
Edward Lewis
[email protected]
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
[email protected]
2
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
[email protected]
3
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
[email protected]
4
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
[email protected]
5
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
[email protected]
6
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
[email protected]
7
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
[email protected]
8
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
[email protected]
9
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)
[email protected]
10
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
[email protected]
11
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
[email protected]
12
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
[email protected]
13
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
[email protected]
14
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
[email protected]
15
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
[email protected]
16
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
[email protected]
17
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
[email protected]
18
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)
[email protected]
19
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?
[email protected]
20
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
[email protected] in .de?
21
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
[email protected]
22
Document Status
 A new round of documents is being prepared
 Same standards level
 A reorganization to include the current base plus the
clarification RFCs
[email protected]
23
Current Discussion Forums
 [email protected]
 A mailing list that has been around a while, recently
has become quite active
 [email protected]
 [email protected]
[email protected]
24