Last Modified: 2004-10-04
| Done | Forward NSEC rdata to IESG for Proposed Standard | |
| Done | Forward RFC2535-bis to IESG for proposed standard | |
| Feb 04 | Forward Case Insensitive to IESG for Proposed Standard | |
| Done | Forward LLMNR to IESG for Proposed Standard | |
| Mar 04 | Forward Wildcard clarification to IESG for proposed standard | |
| Mar 04 | Submit KEY algorithm documents RFC253[69]bis and RFC3110 to IESG for proposed standard | |
| Mar 04 | Start of process of reviewing the following RFCs and to move them to Draft Standard status | |
| Apr 04 | Update boilerplate text on OPT-IN | |
| Apr 04 | Submit to IESG RFC2845 (TSIG)to Draft standard | |
| May 04 | RFC1982 (Serial Number Arithmetic) | |
| May 04 | RFC2782 (SRV RR) to Draft Standard | |
| May 04 | RFC2538 (CERT RR) to Draft Standard | |
| Jun 04 | RFC1995 (IXFR) to Draft standard | |
| Jun 04 | RFC1996 (Notify) to Draft Standard | |
| Jun 04 | RFC2136 (Dynamic Update) to Draft Standard | |
| Jul 04 | RFC3007 (Secure Update) to Draft Standard | |
| Jul 04 | Submit to IESG RFC2930 (TKEY) to Draft standard | |
| Jul 04 | RFC2672 (DNAME) to Draft Standard or revision | |
| Sep 04 | RFC2181 (Clarify) to Draft Standard | |
| Sep 04 | RFC2671 (EDNS0) to Draft Standard | |
| Sep 04 | RFC2308 (Neg Caching) to Draft Standard | |
| Nov 04 | RFC3090 (DNSSEC zones tatus) to Draft Standard | |
| Nov 04 | FRC2539 (DH Key RR) to Draft Standard | |
| Nov 04 | RFC3226 (Message Size) to Draft Standard |
| RFC | Status | Title |
|---|---|---|
| RFC2782 | PS | A DNS RR for specifying the location of services (DNS SRV) |
| RFC2845 | Standard | Secret Key Transaction Authentication for DNS (TSIG) |
| RFC2929 | BCP | Domain Name System (DNS) IANA Considerations |
| RFC2930 | PS | Secret Key Establishment for DNS (TKEY RR) |
| RFC2931 | PS | DNS Request and Transaction Signatures ( SIG(0)s ) |
| RFC3007 | PS | Secure Domain Name System (DNS) Dynamic Update |
| RFC3008 | PS | Domain Name System Security (DNSSEC) Signing Authority |
| RFC3090 | PS | DNS Security Extension Clarification on Zone Status |
| RFC3110 | PS | RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) |
| RFC3123 | E | A DNS RR Type for Lists of Address Prefixes (APL RR) |
| RFC3197 | I | Applicability Statement for DNS MIB Extensions |
| RFC3225 | PS | Indicating Resolver Support of DNSSEC |
| RFC3226 | PS | DNSSEC and IPv6 A6 aware server/resolver message size requirements |
| RFC3363 | I | Representing IPv6 addresses in DNS |
| RFC3364 | I | Tradeoffs in DNS support for IPv6 |
| RFC3425 | PS | Obsoleting IQUERY |
| RFC3445 | PS | Limiting the Scope of the KEY Resource Record out |
| RFC3596 | Standard | DNS Extensions to support IP version 6 |
| RFC3597 | PS | Handling of Unknown DNS Resource Record (RR) Types |
| RFC3645 | Standard | GSS Algorithm for TSIG (GSS-TSIG) |
| RFC3655 | Standard | Redefinition of DNS AD bit |
| RFC3658 | Standard | Delegation Signer Resource Record |
| RFC3755 | Standard | Legacy Resolver Compatibility for Delegation Signer |
| RFC3757 | Standard | KEY RR Secure Entry Point Flag |
| RFC3833 | I | Threat Analysis Of The Domain Name System |
| RFC3845 | Standard | DNSSEC NSEC RDATA Format |
|
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 |