DNSEXT IETF-67 meeting minutes

[Ólafur Guðmundsson /DNSEXT co-chair <ogud@ogud.com>]

Sorry for the late posting.

				DNSEXT @ IETF-67
Date: Tuesday November 7'th
Time: 15:20 - 17:20
Location: Harbor Island II
Chairs: Olafur Gudmundsson
 	 Olaf Kolkman
Minute taker: Michael Richardson
Jabber Scribe: George Michaelson
Jabber Log: http://www3.ietf.org/meetings/ietf-logs/dnsext/2006-11-07.html


The minutes of IETF-66 meeting where approved.

Note: This set of minutes will not repeat what is in presentations,
      unless it is related to milestones or working group actions.
      Links to presentations are provided.

Document status:
    RFCs Published since last IETF-66
	  RFC4471 Derivation of DNS Name Predecessor and Successor
	  RFC4592 Wildcard Clarify
	  RFC4635 HMAC SHA TSIG algorithm Identifiers
	  RFC4701 DHCID
    Documents advanced:
	  MDNS			Informational   RFC-editor
	  NSID			Standards track IESG Discuss state
	  DNSSEC-experiments    Experimental    IESG Discuss state
	  OPT-In		Experimental    IESG Discuss state
	
    Deferred:
	  Use of RSA/SHA-256 DNSKEY and RRSIG Resource Records in
	  DNSSEC

    Last call completed:
	 DSA Keying		   Standards track	Proto Summary needed
	 Diffie-Helman Keying  	   Standards track	Proto Summary needed
	 Key Rollover Requirements Informational	Proto Summary needed
	 Key Rollover Timers	   Standards track	Proto Summary needed
	 RFC2929bis		   BCP			Summary needed
         DNSSEC Transition Mechanisms Informational	Summary needed

Agenda bashing:

Sam Weiler:
    Q: Is 2929bis on the agenda later?
    	suggests that we remove the template from the document.
Chairs will take taking the suggestion under advisement


DNAME presentation.   Wouter Wijngaards
	http://www3.ietf.org/proceedings/06nov/slides/dnsext-1.pdf
	http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-rfc2672bis-dname/
		version 00 covered.
	The document is chartered by the working group to update
	RFC2672 and address any issues that people have with the
	original specification based on implementation or operational
	experience, as well as better understanding of DNS and
	aliasing in general.
	The editors have started an issues tracker and are looking for
	feedback on the issues. (see presentations for list of
	issues).
	
	
Discussion.
Q:	Rather than increase the TTL, could we drop the CNAME synthesis?
A:	added to list of issues.

Q:	signaling the end to end issue.
	do not do versioning, 2672 is broken.
	
Q:	back when DNAME was designed, the intent of the versioning
	was to be able to remove the CNAME. To do that, it means that
	caches have to be able to synthesize CNAMEs.

Q:	the CNAME has compression in it.
	how many bytes are saved by dropping the CNAME?

A	(depends upon the name)
	(the query is there, and the answer will likely have it..)

Q:	On the topic of delegation tool. Never seen it as a delegation tool.
A:	IP6.int. -->

NSEC3 update:  David Blacka.
	http://www3.ietf.org/proceedings/06nov/slides/dnsext-2.pdf
	http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-nsec3/
	version 08 discussed.
Various issues updated since last version based on feedback from
	Workshop in Sept.

CHAIR:	this document will be LC after the next revision.

I:	NSEC3 + DNAME must be recommended against.
Chair:	Mark Andrews to provide text and open issue on this.



Sam Weiler. dnssec-bis-updates.
    http://www3.ietf.org/proceedings/06nov/slides/dnsext-6.pdf
    http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-dnssec-bis-updates/
       version 04

    Stable for a while. Some minor issues need addressing, send editors
    any issues discovered or not clear in RFC435x documents.

WG:    Keep document alive for one more year at least before issuing
       as RFC

BCP on resolvers: Olafur for Bert Hubert
    http://www3.ietf.org/proceedings/06nov/slides/dnsext-5.pdf
    http://tools.ietf.org/html/draft-hubert-dns-anti-spoofing-00

Peter: sourcing of port-53 in advised... may be good for implementors,
       but may not be BCP for operators yet.

Ed:    Should this become a WG item?
       Why bother expanding it's scope?
       A: keep it lean and mean.

       This sounds like observations about what would be a good idea
       to do in DNS. Does this need collaboration?

HOW MANY READ? half the group.
HOW MANY WOULD ADVANCE: nobody.
HOW MANY WOULD WORK: 6 persons.

Mohsen:	this is more of an operational issue than protocol implementations
	and so it should go to DNSOP.

Chairs; Will make formal announcement of adoption on the mailing
	list.


GSS-TSIG.   Rob Austein.
	 http://tools.ietf.org/wg/dnsext/draft-austein-dnsext-relax-gratuitous-tsig-01.txt

	TSIG-- very simple.
	GSS (kerberos/etc.) -- could be used.
	While implementing ISC discovered that the implementations did
	not conform with document, this draft is about bringing
	documentation in line with implementations.


Willing work on document:
	Wouter. Walter. Josh. Sam Weiler. Jerry Wilson.	
Chairs: Will make formal announcement of adoption on the mailing list.


Eastlake. DNS cookies.
	  http://www3.ietf.org/proceedings/06nov/slides/dnsext-0/sld1.htm
	  http://www.ietf.org/internet-drafts/draft-eastlake-dnsext-cookies-01.txt
  Rob:	  20 years too late.
  Peter:	  does this say that we do not believe in DNSSEC?
		  	  (a perception, even if that's not the case)
  Donald:	  this is a weak version of TSIG.

  How many READ: 10 persons.


Signature Only DNSSEC: Mike St.Johns.
    http://www3.ietf.org/proceedings/06nov/slides/dnsext-3.pdf
    http://www.ietf.org/internet-drafts/draft-stjohns-dnssec-sigonly-00.txt
	  - why I went down this path.
	  - the details of the document.

HOW MANY HAVE SEEN THIS: 20-30
HOW MANY WERE INTERESTED: 4-5... negative: some as well.

Johan:	what if the DS is just removed?
A:	show me an application that cares about
	      bogus vs unsecured vs unknown.

Rob:	gives example of MX vs A that requires PNE.
	(much discussion about this, and intermediate validation)

Rob:	intrigued by the off-tree stuff.
	suggests splitting the draft.

Ed:	doesn't understand why PNE conflicts with off-tree signatures
	thinks that off-tree was removed because the code was hard.
	We needed a policy language to do off-tree.

Sam:	PNE requires intermediate validation?
	A: No. Intermediate validation requires PNE.

	Discussion about unvalidated data.

Wes:	insecure/unvalidated distinguish.
	My applications would do something different.
	And with PNE, I have to encode the list of valid zones.
	Firefox does this.

Peter:	will this work for a PNE subtree of a SO zone?
	A: yes, but the PNE resolver will see the PNE subtree as insecure.

Rob:	thinks this may be interesting, but may take as long as anything
	else.

Olafur:	what do you want the WG to say?
MikeStJohns:	I want them to think about it.
		Good points here.
	
Olafur: This is the 6 or so time this issue has been brought up,
	have we answered it wrong in the past ?
	
Olaf:	wants closure on this before the next IETF.

Wes:	a lot of people have given this a lot of thought...
	why not ask the room now?

Olaf:	we asked about this before, and got some feedback.
	We need to look deeper before we ask again.
	Informed consent is needed.

Mundy:	the conclusion that we need provable non-existence
	was that we need PNE.   It wasn't a question about	
	whether or not we were done.

Meeting ended


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