2.3.2 DNS Extensions (dnsext)

NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01

Chair(s):

Olafur Gudmundsson <ogud@ogud.com>
Randy Bush <randy@psg.com>

Internet Area Director(s):

Thomas Narten <narten@raleigh.ibm.com>
Erik Nordmark <nordmark@eng.sun.com>

Internet Area Advisor:

Erik Nordmark <nordmark@eng.sun.com>

Mailing Lists:

General Discussion:namedroppers@ops.ietf.org
To Subscribe: namedroppers-request@ops.ietf.org
Archive: ftp://ops.ietf.org/pub/lists/

Description of Working Group:

The DNSEXT Working Group has assumed the RFCs and drafts of both the DNSSEC and DNSIND working groups. DNS is originally specified in RFC's 1034 and 1035, with subsequent updates. Within the scope of this WG are protocol issues, including message formats, message handling, and data formats. New work items and milestones may be added from time-to-time with the approval of the Working Group and the IESG.

Issues surrounding the operation of DNS, recommendations concerning the configuration of DNS servers, and other issues with the use of the protocol are out of this Working Group's charter. These issues are considered in other venues, such as operational issues in the DNS Operations Working Group.

Broad topics under consideration in DNSEXT are dynamic update, notify, zone transfers, security and adjustments to address the requirements of IPv6 addressing. Security topics, mostly inherited from the erstwhile DNS Security Extensions Working Group, will be addressed in cooperation with the DNS Operations Working Group.

The principal task within this Working Group is to advance several documents describing proposed extensions to DNS. The current list of documents under consideration for advancement is:

Title RFC Status

DNS Server MIB Extensions RFC1611 Proposed

DNS Resolver MIB Extensions RFC1612 Proposed

Serial Number Arithmetic RFC1982 Proposed

Incremental Zone transfer RFC1995 Proposed

Notify RFC1996 Proposed

DNS SRV service location RFC2052 Experimental

Dynamic Update RFC2136 Proposed

Security for Dynamic Update RFC2137 Proposed

Clarification to DNS RFC2181 Proposed

Negative Caching RFC2308 Proposed

DNS Security Extensions RFC2535 Proposed

DSA KEYs and SIGs RFC2536 Proposed

RSA KEYs and SIGs RFC2537 Proposed

Storing Certificates RFC2538 Proposed

Diffie-Hellman Keys RFC2539 Proposed

Extensions to DNS0 RFC2671 Proposed

Non-Terminal DNS names RFC2672 Proposed

Binary Labels RFC2673 Proposed

Other specific work items are:

o TSIG - transaction signatures in (dnsind-tsig-xx.txt)

o TKEY - Secret Key establishment for DNS (dnsind-tkey-xx.txt)

o Securing dynamic update (dnsind-simple-secure-update-xx.txt)

o Protocol clarifications and corrections for DNSSEC (draft-ietf-dnsind-sig-zero-xx.txt) (draft-ietf-dnsind-zone-secure-xx.txt)

o Clarifications for IANA in DNS assignments (draft-ietf-dnsind-iana-dns-xx.txt)

o Documentation of the zone transfer protocol (AXFR)

o Retirement of DNS MIB's RFC's

New work items may be added from time-to-time with the approval of the Working Group and the IESG.

Goals and Milestones:

Done

  

Advance RFC2052bis to RFC.

Jan 00

  

Advance RFC1996 for Draft standard.

Done

  

Advance TKEY and IANA considerations for IESG consideration

Feb 00

  

RFC1995bis and AXFR advanced for Proposed

Done

  

SIG(0) advanced for IESG consideration

Mar 00

  

RFC2136bis advanced for Proposed standard

Mar 00

  

IXFR (RFC1995bis) interoperabilty testing complete

Apr 00

  

Serial Number Arithmetic, Notify and DNS Clarify advanced to Draft Standard.

Apr 00

  

RFC1611 and RFC1612 status chaned to historic.

May 00

  

RFC2308bis advanced for IESG consideration.

Done

  

Secure update completed and ready for IESG consideration

Done

  

RFC2137 Obsoleted

Jun 00

  

Request that TSIG be advanced to Draft Standard

Jul 00

  

Revised DNSSEC submitted for advancement to Draft Standard

Internet-Drafts:
Request For Comments:

RFC

Status

Title

RFC2782

PS

A DNS RR for specifying the location of services (DNS SRV)

RFC2845

S

Secret Key Transaction Authentication for DNS (TSIG)

RFC2929

  

Domain Name System (DNS) IANA Considerations

RFC2930

PS

Secret Key Establishment for DNS (TKEY RR)

RFC2931

PS

DNS Request and Transaction Signatures ( SIG(0)s )

RFC3007

PS

Secure Domain Name System (DNS) Dynamic Update

RFC3008

PS

Domain Name System Security (DNSSEC) Signing Authority

RFC3090

PS

DNS Security Extension Clarification on Zone Status

RFC3110

PS

RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)

RFC3123

E

A DNS RR Type for Lists of Address Prefixes (APL RR)

Current Meeting Report

DNSEXT IETF-51 meeting 2001/August/9 9:00-11:30 GMT. Final minutes
Chairs: Randy Bush
Olafur Gudmundsson

WG STATUS: Olafur Gudmundsson
- 1 new RFC: APL
- 2 documents at RFC editor, message size + DNSSEC OK bit
- 2 docs at IESG: DNSSEC roadmap + RFC161{1,2} retire
- AXFR has passed working group call
- MUST figure out DNSSEC status
- Please adopt RFC to advance

Summary of joint DNSEXT/NGTRANS meeting Olafur Gudmundsson
- DNSEXT will take lead on standardizing IPv6 address related RFCs.
- A6, bitlabels =) experimental
- DNAME standardization is by DNSEXT it stays for now at proposed.
- AAAA to go to drafter standard, need volunteer to adopt for interop testing and reporting.

The main focus of this meeting was to asses the current DNSSEC status and how it should evolve from now on. First there is a presentation on the status and history of DNSSEC, followed by presentations about new proposals and concluding by an open discussion on how to go forward.

Goal: determine how close to operationally deployable DNSSEC
Subgoal: collect list of threats to DNS that only DNSSEC can address
Output: proposed plan of action posted to mailing list

- ---
Current DNSSEC status and options on how to progress
Edward Lewis + Olafur Gudmundsson

context
DNSSEC had a spurt of definition from 1994 to 1998
partial implementation in bind822 1999
workshop followed
bind9 full 2535 DNSSEC with tweaks
Jnamed has almost full DNSSEC compliance
recently, as a result of experiments
an explosion in issues, discussion, activity

set forth a few options regarding to the future of DNSSEC

judge the severity and volume of current issues to see what outcome is recommended no intention to discuss the issues or solutions here

DNSSEC seems to be healthy in terms of interest but with its potential importance and this healthy interest, why aren't we done yet?

what could be done:
- allow just some tweaking
- pursue significant changes
- scrap the current approach and start over
- freeze the current design and advance it

allow just some tweaking:
means leaving most of the definition intact
can we solve the rest of the problems with tweaks and adjustments?
or are we running in circles before it all come crashing down?

major surgery:
a few IETFs ago (oslo or dc) an edict was set forth that DNSSEC must settle down too many theorists, not enough operators

the hope was to give the current definition a real litmus test

how much longer to we wait for the test to begin? or should the edict be rescinded? has the test begun already or not?

scrap the current approach and start over
well, at least we've learned a lot
perhaps the initial conditions set forth are doomed to lead us to a dead end
is dns1.0 (rfc1035) inherently unsecurable?
perhaps we need to restart, perhaps with dns2.0
threat model, requirement document are needed

freeze the current design and advance it

issues
(somewhat arbitrary division of the issues)
CERT records
TSIG operations
management, TKEY
SIG/KEY operations
exposure of data, delegation management, dynamic update
applications and stub resolution
authority at delegations

CERT records
nothing to mention really
not much activity, but this isn't a fault of dns
one issue area down...
just a doc, noone is using it.

TSIG
- Workshops demonstrated that TSIG is maturing well.
- Work has lagged in secret management.
- Two pending drafts, GSS-API and TKEY renewal.
- Open issue is use of TSIG in general purpose queries.

SIG/KEY
a much more problematic area
basic operations are defined, but not always scalable
some issues are even recognized as issues
- exposure of data - via authenticated denial
other issues
- delegation management
- dynamic update refresh

SIG/KEY exposure
NXT record
different approach: NO
modified approach - allowing exclusion of sets from NXT
this issue relates to delegation management
excluding records from NXT eases burden
provides cheaper means to signify unsecured delegations

exposure drafts
opt-in-00, rrsets-00, not-existing-rr-00

delegation management

difficult set of issues
RFC1035 has the same delegation records in parent and child, with the child one more credible, and no record type that only exist in parent

DNSSEC requires more complex communication between parent and child
registrar, registry, registrant complicates

KEY signing opens up
liability issues for parents
QoS issues for child

SIG/KEY at delegations
APEX KEY set can be large, change frequently contain non DNS zone KEY records
proposals to solve problems
reduce communication between parent and child
allow partial security in secure zones
allow zones to express security policies in use

parent-store-zone-keys-01, delegation-signer-01, dnssec-opt-in-00, dnsext-rrsets-00, sec-rr-00

SIG/KEY dynamic update
this topic suffers from a lack of activity
early experiments noted problems in early implementations
may have been fixed
but no one is exercising this area (publicly)

in order to sign zone, you have to have private key present on the server

application and stubs
how are answers to be interpreted? what are the meaning of the bits in the header?
should application keys be stored differently than DNSSEC keys?
dnssec-okbit02, key-genprot-00, ad-is-secure-03

design tradeoffs
delegation maintenance is hard, thus some new proposals suggest changes that increase resolver work and add latency in protocol is it acceptable to secure only fraction of a zone?
when there is choice what part of operation should be favored, operation or resolution?

anyone address some of the problems?

ohta: public key crypto violates e2e principle.

- ---
DNSSEC editing status Dan Massey, Scott Rose
(http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-intro-00.txt)
(http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2536bis-dsa-00.txt)
(http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2539bis-dhk-00.txt)

- ---
Opt IN plan Mark Kosters
(http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-opt-in-00.txt)

opt-in for large zones
DNSSEC is painful for large zones
huge up front cost
null keys, nxt rrs for unsecured child zones
little initial buy-in
high performance penalty on lookup (hash vs tree)
high generation cost
ordering, signing, distribution
desire to have autonomous DNSSEC processing

changes since last version of draft.
dropped additional rcode "retry-no-sec" in response to DNSSEC queries
for delegations that are not secure
now answers from "unsecure" side folded in with secure response for a query on a unsecured or non-existent domain so no need for query
semantics of NXT changed from "non-existence" to "secure but not in range" indicated by setting bit 3 in KEY RR

pros
- incremental cost to DNSSEC adoption
- independent processing for DNSSEC
- no changes for 1035 processing
- DNSSEC not widely deployed yet so now is the time for change

cons
- resolvers need to be updated to deal with opt-in (easy according to nominum)

pilot
implemented an opt-in pilot for com/net/org
demonstrate ease of use, implementation for conformance testing
use parent sig over child (for now)
code is *not* based on bind
3 example zones with web-based zone editor to show how easy it could be to secure/unsecure a zone with opt-in key mgmt web interface for other domains under com/net/org

http://www.research.netsol.com/

Q: updating recursive resolvers is hard.
more elegant solution needed than verisign needs to do.

Rob Austein: signing time issue is not quite it looks like, because it can be done in parallel, except when changing keys frequently, which you're not planning on doing.)

look at it at first

NO SIG Mark Kosters for Roy Arens
diff between NOsigRR and opt-in
- NXT changed from non-existence to not-secure
- OPT-IN defines this in KEY RR
- NOSIG defines this with pseudo-RR hel in NXT type bitmap
- Pros: accomplishes opt-in goals, adds in-zone RRs that could be unsecured, allows thin layer of security from zone to zone

Ed Lewis: Create a type different from NXT rather than trying to change its existing definition.

SIG@Parent Miek Gieben
(http://www.ietf.org/internet-drafts/draft-ietf-dnsext-parent-stores-zone-keys-01.txt)

good points:
works very well operationally
reduces administrator involvement
makes key rollover possible

but:
resolver must be adapted
local (ssh) keys are also signed

solution:
new record at the parent -) DS?

Wrote a tool to verify signature chains
(http://www.nlnetlabs.nl/downloads/dig-9.2.0b2-nlnetlabs-0.1.tar.gz)

- ---
Delegation Signer Olafur Gudmundsson
(http://www.ietf.org/internet-drafts/draft-ietf-dnsext-delegation-signer-01.txt)

APEX records issue.

motivations
key record repeats the mistake of NS record in delegations, same record in two zones
key at child is cumbersome
key@parent has
liability issues for parent
QoS child is totally at parent mercy on changes
parent may only allow dns keys in key set
is there another way?

DS advantages
- minimizes communication
only when child changes key set signed key
- less data in parent
DS much smaller than key
DS only at secure delegations
child in full control of security status
no conflicting key sets

DS disadvantages
- More work for resolves, worst case doubling number of sig verifications
- Has to calculate checksums for keys

DS record
checksum - SHA1(canonical fqdn + key rdata)
data format: 25 bytes, fixed size
key id (2), key size (2), algorithm, sha-1 digest
possible to make the record smaller.

Donald Eastlake commented that the statement in presentation about childs independence was to strong.

Ian Jackson liked the flexibility this gives child for key policies.

Dan Massey: wondered about the right actions to take if child key gets compromised, he will post discussion points on mailing list.

================================================================
SEC RR, Ed Lewis
Currently a place holder for discussion. IF and only if some of the new ideas discussed such as opt-in, DS etc are adopted, it might be nice to tell resolvers what to expect in each zone. SEC RR is indented to express the policies and security records used.

================================================================
40 min Next steps in DNSSEC Randy Bush

This will be open mike session to air opinions on which of the following options to go with. The chairs will take the suggestions and results of straw polls to formulate a plan of action to propose to the working group on the the mailing list.

The options are:
- Finished tweaking DNSSEC (no more changes)
- Few more tweaks (which ones)
- Major Surgery (any collection new proposals such as opt-in, delegation signer, no, no-sig, )
- Start over, because the current approach is not going to work
- Do we really need it?)

Tom Monday: List of issues is representative of what we know of today but there are probably more we have not yet discovered.

Unfortunately the IETF is not good at establishing when things have been explored enough.

Q: dynamic update part/stuff really works or not?

OG: Dynamic update needs more attention.

Randy: We need to have a serious, week long workshop with very few people, but throwing in dynamic update with add at least another week, maybe two.

Lars Liman: Cost of security is highly relevant, needs to be balanced against the risk of losing money if you don't have it. Need to ask people how much they could lose without it, much they are willing to invest in the hard work to protect the money they stand to lose?

Randy: How many people here seriously working on DNSSEC are funded by commercial interests? [2.] How many by military interests? [A few more.]

Rob Austein: Biggest single thing that keeps whacking us in the face seems like we have a handle on it, but it would take a lot of time to implement and test. If we decided to undertake this, we need to go back and re-examine the threat model and see just what problems we're trying to address. Think we could do dynamic update work in parallel. My major hope is the last major thing we really need to change with DNSSEC is the delegation signing issue, so shouldn't run into needs to major change the protocol further when work on dynamic update is done.

Ian: A lot of problems are related to not having clear layering model, that DNSSEC simultaneously looks like part of the normal, accepted DNS layer, and part of it looks like a layer on top but with lots of layering violations.

Donald: Wrote some of original documents but have not been all that active recently. The problem with multilevel hierarchal delegation is intrinsically difficult with no working models anywhere. Could move the security communication completely out of the DNS -- but not clear that would make a bit of difference. If we have DNS security, we need to know what services it is offering and focus on offering them strongly. Biggest mistake would be offering many services and providing them with weak security.

Derek Atkins: One thing about security is that it is very pervasive, it is going to violate layers when you add it to something that was not designed with it, either that or you have to wholly replace the system. With regard to secure dynamic update, I did an implementation in 1995 with the biggest issue being online vs offline signing. You could do it with delegating a signing key to the updater, like the DHCP server. In terms of the real problems that DNSSEC is trying to solve, the biggest one is that DNSSEC solves the problem of name referrals, getting from one name (a host abbreviation alias) to a full name and hence its associated data.

Rip Loomis: Military spending a huge amount of money on trying to make this work, consider it crucial.

Ed: SIG and KEY are where all the problems are, others seem to be ready to go.

Michael Patton: Was agnostic about DNSSEC originally when chaired the DNSng BOF, but now think it is very important to get something out there ASAP. We really need the experience of having a V1.0 in order to learn enough to have a V2.0 which does it right. In favor of doing both very little tweaking to move forward, and also scrapping the current approach to design from scratch a better oe.

Ian: We will always need to have a way to send secured data end-to-end over unsecured path, with full service resolvers doing verification.

Olafur: Early adopters always face a risk.

Randy: I'm not a security weenie, but security experts I trust tell me that complexity is inversely proportional to strength of security, and having a complex process that is not terminating makes me really uncomfortable about the ultimate security of this system. Concerned about the choice of pushing forward with the intent to fix things later. The DNS was bleedingly complex before we even tried to graft DNSSEC into it. Trying to figure out how to get comfortable with any of the choices.

Russ Monday: From NAI, working with ISI on DNSSEC. Important thing NAI/ISI can do is provide a testbed for all this, willing to make available to researchers from other organizations. Sometimes one person's tweak is another's significant change. Should focus on the delegation problem. Should test various proposals and come back with results from that for next IETF meeting.

Bill Manning: Part of the problem is that DNSSEC is a lot like porn in that we claim to know it when we see it (implying there is not an objective way to measure it). ...missed... At some point we really do need to start over with the design of it. Also, I don't believe there can be a single threat model, we can and should have multiple good ones.

Derek Atkins: Regarding simplicity versus complexity, Einstein said, "You should design your system to be as simple as possible and no simpler," and I really think DNSSEC really is as simple as we can make it.

Rob: Propose parallel approach: work on threat model, and rigorously test delegation proposals.

Sense of room seems to agree, no one spoke against.

Donald: Move TSIG to the side.

Ian: Can we have a definition on what's a tweak and what's a major change?

Randy: NO.

Matt Larson: Let's not forget the large zone problem! Not as significant as the large delegation zone problem, but still really significant.

Mark Kosters: Since we have to change the recursive nameserver anyway, we might as well address the large zone issue at the same time. Have not liked NXT since the beginning, but I have become resigned to authenticated denial.

Rob Austein: Confidentiality of data was explicitly NOT one of stated goals of DNSSEC, so people who don't like NXT, tough noogies. Also, because of the interdependence of MX and A records, you can misroute mail. Without authenticated denial there are other attacks possible.

Sense of the room is to pursue parallel work on:
- delegation management
Russ will pursue with NAI/ISI testbed
- protocol discussion on partially signed (ie, large) zones
Mark's work converging
- get serious about dynamic update
... need someone to adopt, contact chairs
- threat models / requirements
Rob Austein and Derek Atkins

- ---
Old Working Group documents
05 min Multicast DNS Dave Thaler
(http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-03.txt)

- Use of "solicited name" multicast addresses for IPv6, using same mechanism as used elsewhere (icmp)
- Clarification of multihoming behavior
- dynamic update for conflict detection
- added .ARPA domain considerations section

Open Issues
- Configuration of mdns
- still assumes domain search option for configuration, but there are other proposals.
- Draft useful as stands?
- Original goal was to allow retirement of NetBIOS and AppleTalk in unconfigured networks.
- Has this goal been met?

- ---
Relevant Documents in Other working groups
05 min DHC MulticastDNS enable option Erik Guttman
(http://www.ietf.org/internet-drafts/draft-guttman-dhc-mdns-enable-01.txt)

mdns enable dhc option
complete replacement to local.arpa zone

wants to replace appletalk with IP services.

================================================================

REPLACE APPLETALK & NETBIOS, Stuart Cheshire
draft-cheshire-dnsext-multicastdns-00

An alternative multicast DNS proposal.

Goals/features:
- Free choice of names for machines only on local link
- Name _services_ at first class entities, not just hosts
- Browse for services, like the printers on the network
- Failsafe reliability
- Simple to implement

================================================================

At this point working group was out of time, chair wanted to resolve one issue, Olafur Gudmundsson asked Bill Manning a question:

If the working group wants to adopt your discover draft will you change the copyright to boilerplate #1?

Bill Manning: YES

End of meeting: Number of agenda items did not get a hearing this time including following documents.

- ---
New documents requesting to become working group documents
05 min TKEY rekey mode Yuji Kamite
(http://www.ietf.org/internet-drafts/draft-kamite-dnsext-tkey-secret-renewal-00.txt)

- ---
05 min Generic KEY RR Protocol value Edward Lewis
(http://www.ietf.org/internet-drafts/draft-lewis-dnsext-key-genprot-00.txt)

- ---
05 min ECC KEY rr Donald Eastlake
(http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ecc-key-00.txt)

Slides

Delegation Signer
State of DNSSEC within DNSEXT
mDNS Enable DHC Option