Progress Of the DNS Security Extensions

NANOG 22May 21-22, 2001

Edward Lewislewis@tislabs.com

2lewis@tislabs.com

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

3lewis@tislabs.com

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

4lewis@tislabs.com

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

5lewis@tislabs.com

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

6lewis@tislabs.com

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

7lewis@tislabs.com

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

8lewis@tislabs.com

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

9lewis@tislabs.com

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

10lewis@tislabs.com

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)

11lewis@tislabs.com

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

12lewis@tislabs.com

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

13lewis@tislabs.com

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

14lewis@tislabs.com

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

15lewis@tislabs.com

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

16lewis@tislabs.com

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

17lewis@tislabs.com

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

18lewis@tislabs.com

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

19lewis@tislabs.com

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)

20lewis@tislabs.com

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?

21lewis@tislabs.com

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?

22lewis@tislabs.com

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

23lewis@tislabs.com

Document Status A new round of documents is being prepared

Same standards level A reorganization to include the current base plus the

clarification RFCs

24lewis@tislabs.com

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