DNSEXT IETF-55 WG mintues

[Ólafur Gudmundsson/DNSEXT co-chair <[e-mail]>]

	IETF-55 Atlanta DNSEXT WG Minutes
	Chair: Olafur Gudmundsson [e-mail]
	       Randy Bush (absent)
	Note takers: Jun-ichiro itojun Hagino
		     Scott Rose
         Date: 2002/November/19 13:00-14:00 EST (18:00-19:00 UTC)

Agenda Bash

WG document status
	RFC editor: Restrict KEY, Roadmap, Obsolete IQuery
	IESG: AD is secure, AXFR clarify, Unknown Types, DS
	WG last call complete pending changes: Opcode Discover
	WG last call: RFC1886bis, DNSSEC Opt-In, TKEY Renewal


GSSAPI and TSIG conflict:
     DNSEXT wg generated TSIG RFC
     DNSEXT wg processed gssapi TSIG
	just before rfc editor started 48hour period we got a report
         that there was a conflict between two the documents.
	TSIG specifies that TSIG can only be used if original query
           contains TSIG
	GSSAPI specifies that last message in TKEY exchange has TSIG
	  last message is empty, and this proves the key negotiated is
	  working from security point of view this is a good thing

	TSIG needs minor updates before advancing to draft standard:
	     is this extensions one of them?

The sense of the room was that this was a reasonable extensions and the
chair is instructed to take this question to the mailing list.


RFC1886/AAAAbis  Vladimir Ksinant  presenting
	RFC 1886 Update:
	goal:  push AAAA to draft standard
	tests done in July '02
	Results:
		minor changes in 1886 needed
	Status of draft:  00 in Sept, now -01 in Oct.
		Now in WG last call - comment now please.


dnssec protocol changes
opt-in David Blacka
	03 to 04: editorial
	02 to 03:
		interaction with wild-cards clarification
		ad-bit clarification
		validation process changes made more explicit

	increases code complexity
	2 independent code exists
	decreased cost in big registries (signing/whatever)
	way NXDOMAIN works in presence of DS and opt-in
	how NXDOMAIN change affect application?

There was a comment that security section needs stronger language,
Clearly list the need for zone transfer protection and risk from zone
hijacking of opt-outed delegations.
Authors agreed examine if the current text is insufficient .

Opt-in issues: Rob Austein
opinions about OPT-IN from a study done by Rob and Roy A. -
         1. Corner cases are actually DNSSEC issues, not OPT-in specific.
         2. DNSSEC pushes a change to the cache algorithm that is
	considered standard in DNS today.  You have to keep things
	together under query names now in order to build auth chain.
	Especially when NXT RRs are involved.
         3. OPT IN does make the code more complex - resolvers have to
	be more intelligent now.
         4. No workshop experience dealing with OPT-IN.  That would be
	nice, since DS has shown problems.
         5. It seems to help large delegation heavy zones, but not resolvers.
         6. From a technical (coding) viewpoint:  the costs are larger
	than the benefits.  However, higher, operational interests may
	rule the day.

Mark Kosters stated there are 2 independent implementations of opt-in
authorative server code. and 2 "independent" implementations of
resolver, both done by the same person in two different code bases.
There where some discussion on if Opt-in is delaying or enabling the
roll-out of DNSSEC. All the speakers stressed the need for some kind of
DNSSEC Real Soon Now.

DS status Olafur Gudmundsson
Implementations:
	1 resolver (or 2)
	2 server implementation
	3 different management tools in development
	3 workshops since Yokohama

	3 under specified corner cases found
	  - need to specify what child server returns for DS query at apex
	       parent not found
           - if child is served by the same server as ancestor other
	       than parent
	  - RFC2535 capable caches have problem with DS
	are there more undiscovered?


	one more document update to deal with ancestor problem
	solution: resolver detects this from authority section and
	  asks for delegation information on parent nameservers and then
	  asks them the question.

	TIME TO DECIDE if DS goes forward, is close.


There's no way to determine if all relays are DS capable, does this
require flag to state if DNS entity is DS aware?
Discussion addressed the problems experienced with DNSSEC failing due
to middle boxes that do not understand DNSSEC types or DS processing.
Is it acceptable during deployment to not be able to do DNSSEC
resolution, or should DNSSEC require "clear path"?
The sense of the room was that broken middle-boxes need to be updated
and as long as DNSSEC answers are not messing up middle boxes it is
acceptable to be only able to do DNSSEC resolution in places where
resolvers can talk directly to authorative servers.

KS flag in KEY: Olaf Kolkman
    version 03 of draft.
    Using a bit in the flags of the KEY record to denote a Key signing
    key.  No protocol value assigned, for user/operator use only.
    Going to WG last call.

Wild-card optimization: Olaf Kolkman
    assumption: one needs proof for non-existence of a wild-cards
	the proof is to be supplied in the common case where there is
         no wild-card in a zone that proof is complicated and somewhat
         expensive in terms of computational resources and packet size
	is there a way to signal that there is no wild-card in a zone?

	proposal:
	use a bit in the NXT RR's type bitmap to signal non-existence
	of wild-cards
	the meaning:
	there is no wild-card expansion possible of any name in the
	zone's namespace spanned by a NXT RR simplest algorithm to set
	the bit	turn it on on all NXT RRs in the zone if there are no
	wild-cards in the zone turn it off on all NXT RRs in the zone
	if there is any wild-card in the zone


	pro:
	shortcut to a simple and fast code path for server and resolver
	smaller footprint
	con:
	bypassed in the common case, the complicated verification code
	is still needed RR type code without RR backward incompatible

	current version of doc
	the suggested algorithm for setting the bit contain an error
	clarifications are needed

	what's next
	update the draft
	does the working group think this is a sane path
	dnssec protocol specs need to describe algorithm for denial of
	authentication of wild-cards
		if not, resolver implementers will do it wrong
		no need for more than 2 NXT RRs?

	if it makes things more complicated, object.
There where some questions about savings on the wire (about 150 bytes
in the common case). Requires more code, not a lot in resolvers, some
in servers, a lot in signers.
Take issues to the mailing list.


Domain Name Auto Registration for plugged in IPv6 nodes: Hiroshi Kitamura
        This document is in a need of home for working group review is
        DNSEXT the right home ?
        The DNSEXT chairs have suggested advancing the document either
        as informational or experimental RFC. Authors would like a
        working group last call for that status.
Erik Nordmark commented that he thinks Experimental is a better status
        for this as it might be promoted to standards track if it
        becomes widely used.
After author updates document chair is to start working group last
        call.


End of meeting. 


--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>