IETF61 DNSEXT Minutes
"Olaf M. Kolkman" <olaf@ripe.net> Thu, 09 December 2004 11:32 UTC
Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14205 for <dnsext-archive@lists.ietf.org>; Thu, 9 Dec 2004 06:32:13 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CcMQN-000Kbw-5A for namedroppers-data@psg.com; Thu, 09 Dec 2004 11:25:31 +0000
Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CcMQK-000Kbb-72 for namedroppers@ops.ietf.org; Thu, 09 Dec 2004 11:25:28 +0000
Received: by postman.ripe.net (Postfix, from userid 8) id 8C32425896; Thu, 9 Dec 2004 12:25:27 +0100 (CET)
Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 12E90244C2 for <namedroppers@ops.ietf.org>; Thu, 9 Dec 2004 12:25:25 +0100 (CET)
Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id iB9BPPLE008034 for <namedroppers@ops.ietf.org>; Thu, 9 Dec 2004 12:25:25 +0100
Date: Thu, 09 Dec 2004 12:25:24 +0100
From: "Olaf M. Kolkman" <olaf@ripe.net>
To: namedroppers@ops.ietf.org
Subject: IETF61 DNSEXT Minutes
Message-Id: <20041209122524.2fab51f6.olaf@ripe.net>
Organization: RIPE NCC
X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_05
X-RIPE-Spam-Status: U 0.220068 / -3.7
X-RIPE-Signature: 08466b3a4f53947f6d31cffbb63c0839
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
DNSEXT WG notes 11/10/04 @ 13:00 Washington DC, IETF 61 Scribe: Scott Rose Jabber scribe: George Michaelson - 2538bis Request for input proxy: Olafur Gudmundsson draft-josefsson-rfc2538bis-00.txt RFC2538bis CERT RR Simon Josefsson has taken on the task of updating and advancing the document along the standards track. Send him comments on the document and reports of implementations. If no changes, we can advance it, otherwise rev it and then advance it. Goal: to finish this before next IETF meeting - Key crypto Donald Eastlake draft-ietf-dnsext-ecc-key-05 and draft-ietf-dnsext-tsig-sha-00 o ECC - Draft only defines key format, not RRSIG format. Questions for group: - Include RRSIG format back into draft? - Make format applicable to KEY/DNSKEY and IPSECKEY There was a question if there are any crypto libraries that contain ECC, at least one open source one was identified. o TSIG-SHA: Specification of the SHA with various http://www1.ietf.org/proceedings_new/04nov/slides/dnsext-8/sld1.htm sizes. includes specification for truncation to shorter MACs Open questions that need to go to WG: - Why go to SHA1 it it is no longer than MD5? - Why not standardize on longer SHA1? Donald's answer:Some crypto people like SHA1, and it is quicker to compute. Follow up - why have to allocate all these names? - take discussion to list WGLC action to be issued soon - QR clarification Roy Arends draft-arends-dnsext-qr-clarification-00.txt Summary in one line: Servers must not answer an incoming message with the QR bit set. Room does not object if this document becomes a WG document. Based on discussion Roy needs to update document to have slightly better definition on what the scope is (ie. only about the Q/R bits). - Wildcard clarification Ed Lewis draft-ietf-dnsext-wcard-clarify-03.txt New material (editorial concerns) 1. Drop "clarifying" from title 2. include text on "* IN DS" presentation on what "* IN DS" could mean RFC1034: if the query has a qname="*", the results should not be cached... Example in presentation: ************************************************ Zone has *.example. IN 3600 NS bogon.example. *.example. IN 3600 NSEC twn.example. NS NSEC RRSIG twn.example. IN 3600 NSEC twp.example. ... twn.example. IN 3600 RRSIG NSEC ... signed by example. ... twp.example. IN 3600 NSEC example. ... Query: two.example. IN NS Answer has (?): AA = 1, RCODE = 0 (not name error) Answer: two.example. IN 3600 NS bogon.example. Authority: twn.example. IN 3600 NSEC twp.example. ... twn.example. IN 3600 RRSIG NSEC ... signed by example. ... Suggested fixes: a. outlaw loading zones with * NS b. exempt certain types from wildcard processing c. instruct DNSSEC validators to ignore "problem" d. Specify * label can't have certain types and cannot be subdomained Questions: There where some statements that c. was the right way to go, but need for a clear definition what that means. There was also discussion that this is an answer not a referral but that needs to be discussed on the mailing list. - Requirements for future work on Denial of Existence (approx 20 minutes) Olaf Kolkman Chairs had a meetings with req. editors and others to prioritize reqs and solution sets at the IETF to facilitate high bandwidth exchanges. Rip Loomis presentation on the priority of requirements" http://www1.ietf.org/proceedings_new/04nov/slides/dnsext-2/sld1.htm Please read slides for full contents of this presentation) New ID Will contain a list of the requirements as the priority: Required, med-level desire, low-level desire, very low-level desire. There was discussion on exposing online keys, not everyone is concerned with zone enumeration, but some are. Some of the "don't care" about zone walking may care about having keys online In the discussion about "Universal signing": Which zones can (under which conditions) not be signed? Ans: some zones with long domain names may not be able to be signed with hashed based schemes (over 255 label limit) A comment was made that current NSEC design and DNSSEC does not cover the RCODE in the message. Some of the proposed solutions to zone walking cover RCODE. Olaf K and proposals for zone walking: http://www1.ietf.org/proceedings_new/04nov/slides/dnsext-0.pdf (pages 9-11) There are basicly two characteristics of proposals, hash-based or online-signing both have various flavors, and they measure differently against requirements/constraints. WG needs to evaluate proposals against priority list of requirements and form plan for possible long term solution. The three main categories of solutions are Epsilon signing (white lies) New type for Negative answers that contains information from the query (called magic type in the discussion, better name needed) Hash based solutions with varying flavors of Opt-in and wildcards Proposed way forward: o Fast track Epsilon Signing as that has minimal impact on implementations (only authorative servers affected) and moves the cost of deployment on the parties that can not live with NSEC; o and work on a protocol change that does not need on-line keys. Goal is to have at most one DNSSECter (ie solutions that require changes in resolvers) Question: Does this way forward make sense? Room seems to think so. - DNSSEC keymanagement issues Johan Ihren draft-ietf-dnsext-trustupdate-threshold-00.txt Mike StJohns Ben Laurie draft-laurie-dnssec-key-distribution-00.txt DNSSEC key management issues Johan Ihren (Threshold based trust update) http://www1.ietf.org/proceedings_new/04nov/slides/dnsext-3/sld1.htm Possible IPR issues with schema editors will investigate. Draft is better, implementation of version 00 is available Changes in draft: o Simplified Definition of M and N threshold params o Documented the state machine better o Fixed the replay attack that was possible before No questions Question: how long to complete? Ihren: fairly complete with some issues. Priming stuff needs more work. Overall it works. IPR issues are up in the air. Mike St Johns (rolling over the trust anchor) http://www1.ietf.org/proceedings_new/04nov/slides/dnsext-4/sld1.htm No major changes from prior version mainly related to timers and DNSKEY removal from apex. Question to group - is it worth pursuing an in-band mechanism? Ben Laurie (DNS Key distribution) new, individual submission (draft-laurie-dnssec-key-distribution-00.txt) not a WG item yet: need more readers/comments/etc! Islands of trust issues, some people don`t like single auth. inband stuff is tricky. lots of keys, lots of data Mechanism is cross-signing scheme. start with one, fetch more. can recurse or stop Closing remarks Olafur Gudmundsson: WG is to consider which KEY mechanisms to promote. Timers and Threshold both say they are close to be ready for LC. Chair to check with Security AD if there are any obvious security problems with either proposal. - Cross fertilization (DNS related work in other groups that needs review) James Snell draft-snell-dnsepd-00.txt draft-iab-dns-choices-00.txt Patrik Faltstrom DNS issues in SPF Stephane Bortzmeyer + James Snell(DNS Endpoint discovery) http://www1.ietf.org/proceedings_new/04nov/slides/dnsext-5/sld1.htm Individual submission not seeking to be a WG document (draft-snell-dnsepd-00.txt) This is used for providing web-services tools 2 new RR: XML and EPR There where concerns that the XML RR was to open and should be changed to Web services only with restrictions. Number of people suggested that they use NAPTR records for this. Editors thanked for feedback and will update documents based on that. + Patrik Faltstrom (DNS Design Choices) IAB draft: (draft-iab-dns-choices) - discussion of DNS choices in protocol design. - question about scope of who to go to with DNS questions involving new DNS RRs - TomasN: 2 part response: 1 is it going to hurt DNS? 2. Does it help the protocol in question that is requesting it? DNSEXT or successor will deal with topic 1. . - Is there a need to have a separate draft to request the new RR type? A: no. Stephane Bortzmeyer (DNS and SPF) http://www1.ietf.org/proceedings_new/04nov/slides/dnsext-6.pdf non-wg draft: draft-lentczner-spf-00.txt SPF: Sender Policy Framework. this is a request for a new RR type used by mail-servers to detect spoofed email's. SPF is defined as TXT RR with a new name. There where concerns with reusing TXT due to implementation problems in the past. Suggestion from WG to specify a new RR with one RDATA field and use RDLEN as indicator of how long the data is. There where also questions raised about the recommendation that Mail server check for both types (TXT and SPF) and the policies for issuing these queries (serial, parallel, which one takes preference). End of meeting -- 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/>
- IETF61 DNSEXT Minutes Olaf M. Kolkman