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