Draft minutes of DNSEXT @ IETF48

[Olafur Gudmundsson <[e-mail]>]

3 August 2000, DNSEXT WG
Meeting run by chairs Olafur Gudmundsson and Randy Bush
Minutes by Donald Eastlake and Mark Kosters (thanks to both of you)
Edited by Olafur Gudmundsson.

Agenda Bashing: three additions,  Levon Esibov on A6 dynamic update
problem, David Conrad on "Got DNSSEC?", Donald Eastlake on RSA-SHA1.

WG Status was given by Olafur Gudmundsson (OG):

RFC 2845 "Secret Key Transaction Authentication for DNS (TSIG)" is
out.  The IANA DNS, TKEY, and Secure Update drafts have all three been
approved and should be out as RFCs in not too long.  Secure Update and
Signing Authority are at IESG, minor text needed to added to Secure
Update.  APL is pending Area Director action to bring to IESG.

The IXFR draft is in WG last call.

RFC status: a list of all the RFC's within the WG's charter
area was given with their status.

New Items: standards track
	For advancement to Draft Standard
		SRV Interoperation testing needed
		Notify needs minor technical changes
		IXFR interoperation testing needed
		Neg Caching interoperation report needed
	Advance AXFR clarify & Msg Size to Proposed Standard

Next Items
	retire SNMP RFC's to historic: Rob Austein to write up
	continue clarify and simplify off DNSSEC.
	Advance other lower priority items
	A few new items
New Items
	Message Size document by Olafur Gudmundsson
	GSS API Stewart Kwan
	DNSSEC awareness ENDS option David Conrad
	EDNS0.5 (Austein & Alvestrand)
	DNS Server expectation & clarification document:
		Michael Patton
	DNS Resolver expectation & clarification document:
		(needs author, contact Olafur)

Knocking on the door
	DNSSEC Roadmap Glen Rose
	NO Record (NXT replacement)
	Multicast DNS

New Charter Items
	Multicast DNS
		local link scope and/or enterprise wide
	IDN - being handled in a separate WG, but DNSEXT will handle
	all DNS protocol changes. Possibilities include:
		new label types
		EDNS flags, EDNS options
		New record types
	Chair has dropped hints in IDN working group, that teams
	creating new solutions SHOULD use EDNS and leave DNS header
	alone.
	
Bill Manning: IETF 48 Interoperabilty Notes (Slides)
	Cisco, CheckPoint, Lucent, Microsoft, Nominum, NAI Labs,
		hosted by ISI
	Items to test:
	NCACHE & SRV have test suites
	All other testing was ad-hoc
	NCACHE - three interoperable versions and may proceed
		to Draft Standard pending some clarification
	All SRV implementations passed XFR, RELOAD, and compression
		Ad-hoc testing
	EDNS0 worked between two implementations in one direction
	SIG/KEY/NXT would pass between all implementations but did
		not share assumptions
	Two parties tested some TSIG with limited success
	Three implementations have working client & server code for
		IXFR
	We should (1) construct an online testbed,
	          (2) formulate standardized test suites, and
                   (3) have scheduled testing sessions
         people interested in testing implementations should subscribe
	to the testing mailing list
	[e-mail]

IXFR Last Call
	Bill Manning: some implementor concerns, to be provided in
		last call period

AXFR Clarify
Andreas Gustafsson: (01 draft posted to mailing list because
it didn't make it out before the IETF meeting)
	
Draft version 00 provides the long missing specification of AXFR.  For
example, multiple answer records are permitted, specifies header
fields of multiple messages, specifies when a question section is
required, states that AXFR begins and ends with just SOA not all apex
data.
	
01 adds security considerations section and definition of glue.
Purpose of AXFR is to copy zone including necessary and unnecessary
glue as originally loaded from master file.  This requires servers to
store zones in separate structures so glue in one zone can be
distinguished from authoritative data in other zones.  (This has
actually always been required.)  It was noted by observation that one
implementation of AXFR advertised its ability to accept multiple
answers by appending the two ASCII characters "MS" to the end of its
AXFR query.

EDNS0.5
Harald Alvestrand (HA): "To Make sure that IDN and other rabid adders
of DNS features can get what they want done without damaging the
stability of the Internet".  Some discussion if this should be
renumbered to be EDNS1 rather than ENDS0.5 no consensus. Question on
what features should be enumerated, answer was only the ones t added
since 1034/1035, and features that might be obsoleted or replaced.

Message Size

Olafur Gudmundsson: Current DNS restricts UDP answers to 512 bytes,
DNSSEC & A6 answers are bigger and frequently need more space
resulting in unnecessary TCP transfers, etc.  EDNS0 provides a way to
indicate readiness to receive a bigger answer.
	
This draft says that if you support DNSSEC or A6 your MUST support
EDNS0.  Minimum EDNS0 indicated MTU in draft is set at 1280 bytes.
Next version will have 1220 or 1240 (IPv6 MTU is 1280 bytes and you
need to subtract the UDP header size.)  Will revise draft based on
comments.  Number people voiced opinions on the size, IPv6 people
argue for 1024 to avoid fragmentation, DNS people argue for large
number to maintain number of nameservers high.

Kazu Yamamoto (KY): EDNS0 is needed for IPv6.  512 bytes is too small.
The root zone needs NS RRs +A/AAAA/A6 "glue".  AAAA/A6 only meaningful
for IPv6 transport ready resolvers Mandate EDNS0 for IPv6. No
objections to this idea at IPng WG yesterday.  This should be put in
the IPv6 host requirements.  Olafur and Kazu to bring issue on how to
address IPv6 requirements up on the IPng mailing list.

Masataka Ohta (MO):Number of root servers is a DNSOP matter.  Anycast
is the answer.  Five roots is enough using Anycast.

Bill Manning (BM) wants to see the calculations of packet size.


GSS TSIG (slides)
	Levon Esibov (LE): draft-dnsext-gss-tsig-00.txt
	Original draft submitted three years ago.
	Authentication between clients and servers as well as between
	servers.  Generate shared secret key using TKEY & GSSAPI.
	Then authenticate using TSIG & GSSAPI.
	Draft does NOT cover authorization of DNS requests.
	GSS-TSIG developer need not develop a security infrastructure,
	just piggy backs on GSSAPI infrastructure.
	Security mechanism independence since its accessed via GSSAPI.
	(diagram)

Some questions about performance implications and delays using this,
compared to MD5 TSIG, no answers available at this time.  Olafur
mentioned that two other people are implementing this, in addition to
MS, and this document will not leave WG until there are interoperable
implementations.

Clarification on Zone Status
Ed Lewis (EL): Motivation is that RFC 2535 talks about securing a
resolver, not about how a server secures itself.  The server point of
view is not given.  If a server uses an obscure algorithm, it has done
a bad thing in terms of getting its data securely into the hands of
most resolvers.  And administrator can leave a zone secured, can
secure it as part of the secure DNS tree, or secure it and still not
be part of the tree, depending on algorithm used, parental vouching,
etc.
	
Changes this draft makes to RFC 2535:
	(1) Definition if a zone is secured or not secured.  RFC
	2535 says per algorithm.  Changed to per zone.
	(2) Protocol octet in KEY has to be DNSSEC or ANY.  RFC
	2535 permits it to be zero in a KEY used for DNSSEC.
	(3) Dropping the "experimentally secure" status.  If desired,
	it can be achieved in other ways, such as limited public
	key distribution.
	
An important point of this draft is to define "fully secured" and
"privately secured".  Probably "Fully" secured should be "Globally"
and "Privately" should be "Locally".  To be globally secure, it is
required that your parent says you are secure.  (If your parent isn't
secure, then you have to give everyone who will trust you your public
key in some secure fashion they will trust.)
	
This draft depends on the Signing Authority draft.
	
Gone from earlier versions of this draft is the NXT hack.  That would
have gotten rid of NULL keys.  But operators indicate that these do
not seem to actually be a problem.
	
Draft needs a further revision of the English, due to
misunderstandings but non English readers.

Draft will go for WG Last Call after these revisions.	

DHCID: DHCP needs a semaphore RR...
Want their own RR so DHCP servers can mark names so others will know
who set them.  They have tried to specify using TXT, SIG, and KEY to
store the data they want in the DNS but those are misuses of RRs
intended for other purposes.  Lively discussion about the need for
this and why DHCP people want this. The final consensus was that this
is not a good idea but if DHCP wants to store some information to
arbitrate between servers and/or clients this is harmless from DNS
perspective.

NXT RR -> NO Record
Simon Josefson (not here) (Olafur gave a summary)
Uses hashes of names.  List of integers instead of bit map.
Discussion to the list.
Question if this is extra work for WG and if it should be allowed in
Olafur: This can fit under the fixing of DNSSEC umbrella which is on
the charter. Admit document as WG document,

DNSSEC Roadmap
Scott Rose

Purpose of the document is to help inform people about what it's all
about and where it is.  Similar to IPSEC Roadmap.  First part lists
documents and what they cover.  Second part tries to give a unified
overview of what it all means.
	
Document will have to be frequently revised and should stay as a draft
for some time.  Perhaps become an Informational RFC at some point.
Might be extended to include all the DNS extensions...

Chairs: take it on, it's useful, keep it small and restrict to DNSSEC
only (including TKEY and TSIG).

Multicast DNS (MDNS), draft-aboba-dnsext-mdns-01.txt
	Levon Esibov (LE).  Some requirements come out of zeroconf.
	Will talk about what the draft isn't.
	Goals: resolve when no DNS server or no DNS server that
		hosts all the local names.
	Not service location.  Not a substitute for dynamic DNS.
	Not for use on global Internet or in Enterprise nets.
	For home/ad-hoc networks and the like.
	Query under lcl.arpa to link-local scope for IPv4 or IPv6.

Number of comments, replace lcl.arpa with local.arpa. Stewart Cheshire
of Apple has reserved an multicast Address for this purpose, question
if zeroconf people are happy with link local only scope?


Anycast DNS, draft-manning-dnsext-mdns-06.txt
Bill x: Draft has been cut down to three pages.  Study shows that
traffic impact is not a problem.  Comment that this is a problem in
global networks with slow links, as scope off local is not restricted
by many organizations.  Number of questions on why an organization
would want to do this as if it has infrastructure it most likely has
DNS servers configured.

Add Multicast DNS to WG items ? (Olafur)
Comments included "Against taking this on because we get rat holed on
multicast issues, not DNS.", "limit to link local", consensus was to
accept both at this point for future work and be careful how these
proposals grow.

A6 Dynamic update problem: (Levon)
Need technique for clients to find out prefix info for non-zero
prefixes for A6 updates. No standardized way to find this out. Matt
Crawford will take this issue up with IPNG wg.

David Conrad, Got DNSSEC?
	Non-DNSSEC aware client can't say it doesn't want DNSSEC
	additional RRs including SIG and spontaneous KEYs.
	So server will always send big packets which may result
	in unnecessary truncation and TCP transfers.
	Solutions:
		Everyone does ENDS0.
		Client can indicate it doesn't want DNSSEC.
		Forget DNSSEC?
	BIND v9 uses the AD bit in the query for this purpose.
		Pro: Does not require EDNS0, really simple.
		Con: Uses a scarce bit, doesn't promote EDNS0
		Con: May screw up caches/forwarders
	Use a bit in the EDNS0 header
		Pro: Doesn't use a scare bit, simple, encourage EDNS0
		Con: Disadvantage of requiring EDNS0
	Use EDNS0.5
		Pro: Doesn't use a scarce bit, encourages EDNS0, finer
			grained
		Con: Requires EDNS0
	New Denial of Service
		Bad guy spoofs a response indicating the server does not
		support DNSSEC??
	What to do?
		It is late to make much change in BIND v9.0.0

Consensus was to add this to the working group tasks.

Donald Eastlake, RSA-SHA1.
If you are using RSA, most of the data in the DNS is probably
adequately protected by the RSA-MD5 of algorithm 1 specified in RFC
2537.  But MD5 is showing its age and the most sensitive root/TLD/etc.
data deserves the protection of SHA1 and any better padding techniques
that have been deployed for a while.  The additional computation for
SHA1 versus MD5, etc., is trivial compared with the main RSA modular
exponentiation.

Mark Andrews and others: Not only should RSA-SHA1 be added, it should
be MANDATORY to implement, and RSA-MD5 should be obsoleted.  RSA SHA1
draft (to be submitted by Donald Eastlake) approved as a work item.



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