Draft IETF-51 DNSEXT WG minutes

[Ólafur Guðmundsson <[e-mail]>]

Here are my draft minutes, please send in corrections/changes/additions
before August 28'th.

	Olafur

DNSEXT IETF-51 meeting 2001/August/9 9:00-11:30 GMT.
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 DNSEXT/NGTRANS        Olafur Gudmundsson
Summary of DNSSEXT & NGTRANS MEETING
- 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.

Agenda was the main focus of the meeting to asses the current DNSSEC
status and how it should evolve from now on. Then new proposals
are on the agenda followed 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?


- ---
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 Bush: 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.

...: [something about dynamic update]

Olafur: Dynamic update needs more attention than it has been given,
which is not nearly enough.

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 large 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>




to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.