From owner-dns-security@lists.tislabs.com Wed Jun 2 20:03:23 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12522 for ; Wed, 2 Jun 1999 20:03:23 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA04892 Wed, 2 Jun 1999 18:53:28 -0400 (EDT) From: Mark Gritter Message-Id: <199906022302.QAA12472@Xenon.Stanford.EDU> Subject: Delegation Points To: dns-security@lists.tislabs.com Date: Wed, 2 Jun 1999 16:02:22 -0700 (PDT) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-dns-security@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 7bit I see a potential problem with the handling of keys at delegation points. (In reference to section 2.3.4 of RFC2535.) Suppose the RRset "gritter.stanford.edu, KEY" has three records. The first key is for an email address (gritter@stanford.edu's public key), the second is a host key, and the third is a zone key for the *.gritter.stanford.edu subdomain. The RFC suggests that these nodes occur in both master files--- for the stanford.edu domain and for the gritter.stanford.edu. However, in the second paragraph of that section: > There MUST be a zone KEY RR, signed by its superzone, for every > subzone... [snip] > For all but one other RR type[s] the data from the subzone is more > authoritative so only the subzone KEY RR should be signed in the > superzone if it appears there. The NS and any glue address RRs SHOULD > only be signed in the subzone. The SOA and any other RRs that have the > zone name as [the] owner should appear only in the subzone and thus are > signed only there. Does this require that other KEY RRs with the same owner also be signed with the superzone key? The KEY RRset must be signed as a unit, unless the resolver is explicitly required to recognize and deal with such a situation. I would think the host key (#2) should be signed with the "gritter.stanford.edu" zone key (#3), but is this not the intent? On the other hand, if the "gritter.stanford.edu" zone key is used to sign the RRset, the key has "signed itself". Resolvers must not accept such a signature as valid. I would appreciate your comments on this--- I find the section confusing. Also, I would favor a stronger statement in section 6.3, "Chaining Through the DNS" than the current "it should be possible to retrieve signed keys..." If every zone key is signed by its superzone key (as required in 2.3.4) then simple "downward" chaining from the root zone _is_ (not "should be") sufficient to find all zone keys. Mark Gritter mgritter@cs.stanford.edu From owner-dns-security@lists.tislabs.com Thu Jun 3 09:12:05 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04296 for ; Thu, 3 Jun 1999 09:12:04 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA06485 Thu, 3 Jun 1999 08:20:23 -0400 (EDT) X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 2 Jun 1999 20:35:35 -0700 To: dns-security@lists.tislabs.com, Mark Gritter From: Edward Lewis Subject: Re: FW: Delegation Points Cc: lewis@tislabs.com Sender: owner-dns-security@lists.tislabs.com Precedence: bulk Sigh. A short answer - the RFC is confusing in many places. As an implementer, I do not agree with much of section 6. Hence, I won't arge the spec. You raise a situation I hadn't considered though - stuffing non-zone keys in the apex. I am in the midst of writing a key handling document for the DNSOP proto-WG, and already have a document into the DNSIND on "zone key referral" (co-written with Jerry Scharf). Both of these relate to your concern. I have also had a draft (retired) on the "Chaining signed keys" that is an alternative to section 6, which is likely to rise again now that more folks are combing throught RFC 2535. List note: given that DNSSEC is being merged with DNSIND, folks should raise similar issues like this to either namedroppers or the coming dnsop mailing lists, as appropriate. (namedroppers deals with protocol issues, dnsop deals with ops issues. What is addresses here hits both.) At 4:07 PM -0700 6/2/99, Lewis, Edward wrote: >Message-ID: <199906022302.QAA12472@Xenon.Stanford.EDU> >From: Mark Gritter >To: dns-security@lists.tislabs.com >Subject: Delegation Points >Date: Wed, 2 Jun 1999 16:02:22 -0700 >MIME-Version: 1.0 >X-Mailer: Internet Mail Service (5.5.2448.0) >Content-Type: text/plain > >I see a potential problem with the handling of keys at delegation >points. (In reference to section 2.3.4 of RFC2535.) Suppose >the RRset "gritter.stanford.edu, KEY" has three records. The first >key is for an email address (gritter@stanford.edu's public key), the >second is a host key, and the third is a zone key for the >*.gritter.stanford.edu subdomain. > >The RFC suggests that these nodes occur in both master files--- for >the stanford.edu domain and for the gritter.stanford.edu. >However, in the second paragraph of that section: >> There MUST be a zone KEY RR, signed by its superzone, for every >> subzone... >[snip] >> For all but one other RR type[s] the data from the subzone is more >> authoritative so only the subzone KEY RR should be signed in the >> superzone if it appears there. The NS and any glue address RRs SHOULD >> only be signed in the subzone. The SOA and any other RRs that have the >> zone name as [the] owner should appear only in the subzone and thus are >> signed only there. > >Does this require that other KEY RRs with the same owner also be >signed with the superzone key? The KEY RRset must be signed as a unit, >unless the resolver is explicitly required to recognize and deal with >such a situation. > >I would think the host key (#2) should be signed >with the "gritter.stanford.edu" zone key (#3), but is this not the intent? >On the other hand, if the "gritter.stanford.edu" zone key is used to >sign the RRset, the key has "signed itself". Resolvers must not accept >such a signature as valid. > >I would appreciate your comments on this--- I find the section confusing. > >Also, I would favor a stronger statement in section 6.3, "Chaining >Through the DNS" than the current "it should be possible to retrieve >signed keys..." If every zone key is signed by its superzone key >(as required in 2.3.4) then simple "downward" chaining from the root zone >_is_ (not "should be") sufficient to find all zone keys. > >Mark Gritter >mgritter@cs.stanford.edu -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Network Associates/TIS Phone: +1 443-259-2352 Email: lewis@tislabs.com Think globally, scope locally. "Trying is the first step to failure." - Homer Simpson "No! Try not. Do... or do not. There is no try." - Yoda Opinions expressed are property of my evil twin, not my employer. From owner-dns-security@lists.tislabs.com Tue Jun 15 11:23:37 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20866 for ; Tue, 15 Jun 1999 11:23:37 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA15357 Tue, 15 Jun 1999 10:02:01 -0400 (EDT) Date: Mon, 14 Jun 1999 14:40:11 -0400 (EDT) From: "David M. Balenson" Message-Id: <199906141840.OAA22894@clipper.gw.tislabs.com> To: dns-security@lists.tislabs.com Subject: NDSS 2000 SUBMISSION DEADLINE EXTENDED TO JUNE 23RD Sender: owner-dns-security@lists.tislabs.com Precedence: bulk The Internet Society's Year 2000 Network and Distributed System Security Symposium (NDSS 2000) deadline for submissions of technical paper and panel proposals has been EXTENDED TO JUNE 23RD due to the large number of requests for an extension and the desire to accomodate people. The complete Call for Papers (CFP) is available at http://www.isoc.org/ndss2000/. Submissions are being accepted electronically at http://www.isi.edu/~ndss00. -David Balenson, NDSS 2000 Publicity Chair From owner-dns-security@lists.tislabs.com Tue Jun 22 12:56:25 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08603 for ; Tue, 22 Jun 1999 12:56:25 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA09037 Tue, 22 Jun 1999 11:39:36 -0400 (EDT) From: Robert Elz To: namedroppers@internic.net, dns-security@lists.tislabs.com Subject: First draft charter for combined dnsind/dnssec Date: Wed, 23 Jun 1999 01:38:54 +1000 Message-Id: <10925.930065934@munnari.OZ.AU> Sender: owner-dns-security@lists.tislabs.com Precedence: bulk To all DNSIND and DNSSEC members... Here is the (long awaited) first draft of a proposal for a charter for the (to be) new combined working group. Note that the WG name has not yet been determined. It is possible it might remain dnsind, it is possible that it might become dnsext (as suggested in the draft below) or it could become something else entirely. Keeping dnsind has the advbantage that less stuff needs to be altered. It has the disadvantage that the "ind" part has pretty much become meaningless, for some time now. Switching to dnsext would mean a more relevant name, but maeans a name switch with essentially no real practical benefits. On something else - we'll only know if/when it is proposed. Aside from that issue, on which reasoned comments are welcome, please look at the rest of the draft charter, and supply any missing information. Also please consider the milestones, and see which of them you believe we can make, where we can perhaps go quicker, ... Also, any that I have missed, or any active work I have missed (and should be being continued). Work from dnssec is an obvious candidate for that. Lastly, for credit where it is due - most of the substance of this draft charter came from Thomas Narten (one of our ADs) - I added the work items and milestones (which are the parts most likely in need of correction). This draft has not yet been to the IESG for consideration, that will happen after any WG concerns are addressed (from either of the merging working groups). kre ps: I already know from comments on the draft agenda for the Oslo WG meeting that some of the specific work items will ened updating. DNS Extensions (dnsext) --------------------------------------------------- Charter Last Modified: 11-May-1999 Current Status: Active Working Group (being rechartered) Chair(s): Randy Bush Robert Elz Internet Area Director(s): Thomas Narten Erik Nordmark Internet Area Advisor: Erik Nordmark Mailing Lists: General Discussion: namedroppers@internic.net To Subscribe: namedroppers-request@internic.net Archive: ftp://rs.internic.net/archives/namedroppers Description of Working Group: This working group is concerned with all DNS protocol and data format issues, as opposed to operational issues which are handled elsewhere (e.g., the DNSOP WG). Current work is focused on the following areas: Defining protocol extensions that allow DNS resolvers and servers to support new versions of the DNS protocols. Needed extensions include the ability to expand the size of some fixed size fields (e.g., error codes), a mechanism to indicate support for larger than current DNS payloads, compression mechanism for new RRs, etc. Securing the DNS protocol (i.e., DNSSEC). The groundwork for DNSSEC was laid down by the DNSSEC WG. That WG has been closed with the remaining work picked up by DNSEXT. Advancing DNS specifications (rfc1982, rfc1995, rfc1996, rfc2136, rfc2137 rfc2181, rfc2308, rfc2535, rfc2536, rfc2537, rfc2538, rfc2539, rfc2541) along the Standards Track. Serving as a place to review DNS-related documents produced by other working groups. New work items may be added from time to time with the approval of the working group and the responsible AD. Specific activities taking place at present: Designing extensions to the basic DNS protocol to allow for bigger packets, more error codes, new label types, multiple queries (etc). and Revising RFC 2052 (SRV records) and placing it on the Standards Track. Allowing DNS name compression that can survive caching and redistribution by caches that do not understand the format. Permitting dynamic DNS delete operations to be deferred to a later time. Designing a RR to store address prefix lists. Defining an simple shared secret key based mechanism for authenticating DNS transactions . Using that mechanism to allow for simplified security of dynamic updates. Providing a method to establish a shared secret key (suitable for tsig). Attempting to allow verification of unknown RR types, which might contain (case insensitive) domain names. Dealing with the problems of rollover of the timestamps in keys and signatures. Avoiding the need to have zone keys stored in the parent zone file. Allowing keys to contain a key reference, rather than the key itself. Goals and Milestones: Where there is no milestone for a work item mentioned above, the working group has not yet decided upon the priority for the item, or, in some cases, whether active work will be undertaken, and no target milestone has yet been set. Aug 99 Basic extensions to the DNS (edns0) resubmitted to the IESG Aug 99 local compression ready for IESG consideration Nov 99 notify and dynamic update interoperability testing complete Dec 99 tsig ready for iesg consideration May 00 simple secure update completed Mar 00 ixfr interoperability testing complete Dec 00 More DNS extensions (edns1) submitted to IESG Apr 13 rfc2052bis (SVR RRs) finally meets the IESG requirements From owner-dns-security@lists.tislabs.com Tue Jun 22 16:36:06 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16277 for ; Tue, 22 Jun 1999 16:36:05 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10326 Tue, 22 Jun 1999 15:39:55 -0400 (EDT) X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 22 Jun 1999 11:58:58 -0400 To: namedroppers@internic.net, dns-security@lists.tislabs.com From: Edward Lewis Subject: Re: FW: First draft charter for combined dnsind/dnssec Cc: lewis@tislabs.com Sender: owner-dns-security@lists.tislabs.com Precedence: bulk >Message-ID: <10925.930065934@munnari.OZ.AU> >From: Robert Elz >To: namedroppers@internic.net, dns-security@lists.tislabs.com >Subject: First draft charter for combined dnsind/dnssec >Date: Tue, 22 Jun 1999 08:38:54 -0700 ... >--------------------------------------------------- >Current work is focused on the following areas: > >Securing the DNS protocol (i.e., DNSSEC). The groundwork for DNSSEC >was laid down by the DNSSEC WG. That WG has been closed with the >remaining work picked up by DNSEXT. I think you should mention TSIG and securing dynamic update. DNSSEC, per se, doesn't include transaction security and is not sufficient for dynamic update. There is still quite some work to do in both TSIG and securing dynamic update. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "Trying is the first step to failure." - Homer Simpson "No! Try not. Do... or do not. There is no try." - Yoda Opinions expressed are property of my evil twin, not my employer. From owner-dns-security@lists.tislabs.com Tue Jun 22 21:51:38 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29943 for ; Tue, 22 Jun 1999 21:51:38 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA11299 Tue, 22 Jun 1999 20:43:11 -0400 (EDT) From: rja@corp.home.net (Randall Atkinson) Message-Id: <990622174242.ZM25066@dragonfly.eos.home.net> Date: Tue, 22 Jun 1999 17:42:42 -0700 In-Reply-To: Edward Lewis "Re: FW: First draft charter for combined dnsind/dnssec" (Jun 22, 11:58) References: X-Mailer: Z-Mail (4.0.1 13Jan97) To: namedroppers@internic.net, dns-security@lists.tislabs.com Subject: Re: FW: First draft charter for combined dnsind/dnssec MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-dns-security@lists.tislabs.com Precedence: bulk kre, I like the draft new merged charter. Because it makes the name align more clearly with the charter (hence is very helpful to newcomers to IETF), I would prefer that the merged WG be dnsext or some other name that is generic and has clear meaning. Ran rja@corp.home.net From owner-dns-security@lists.tislabs.com Wed Jun 23 01:36:45 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12819 for ; Wed, 23 Jun 1999 01:36:43 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA11718 Wed, 23 Jun 1999 00:35:28 -0400 (EDT) Message-Id: <199906230435.AAA02245@torque.pothole.com> X-Authentication-Warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol To: namedroppers@internic.net, dns-security@lists.tislabs.com Subject: Re: FW: First draft charter for combined dnsind/dnssec In-reply-to: Your message of "Tue, 22 Jun 1999 11:58:58 EDT." Date: Wed, 23 Jun 1999 00:35:03 -0400 From: "Donald E. Eastlake 3rd" X-Mts: smtp Sender: owner-dns-security@lists.tislabs.com Precedence: bulk Certainly TSIG, TKEY, and secret key secured dynamic update should be included. However, DNSSEC certainly does include public key transaction security and is sufficient for public key based secure dyanmic update. It is the lower overhead per transaction but higher set up overhead secret key versions of these that require TSIG, etc. Thanks, Donald From: Edward Lewis Message-Id: In-Reply-To: Date: Tue, 22 Jun 1999 11:58:58 -0400 >>Message-ID: <10925.930065934@munnari.OZ.AU> >>From: Robert Elz >>To: namedroppers@internic.net, dns-security@lists.tislabs.com >>Subject: First draft charter for combined dnsind/dnssec >>Date: Tue, 22 Jun 1999 08:38:54 -0700 >... >>--------------------------------------------------- >>Current work is focused on the following areas: >> >>Securing the DNS protocol (i.e., DNSSEC). The groundwork for DNSSEC >>was laid down by the DNSSEC WG. That WG has been closed with the >>remaining work picked up by DNSEXT. > >I think you should mention TSIG and securing dynamic update. DNSSEC, per >se, doesn't include transaction security and is not sufficient for dynamic >update. There is still quite some work to do in both TSIG and securing >dynamic update. > >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >Edward Lewis NAI Labs >Phone: +1 443-259-2352 Email: lewis@tislabs.com > >"Trying is the first step to failure." - Homer Simpson >"No! Try not. Do... or do not. There is no try." - Yoda > >Opinions expressed are property of my evil twin, not my employer. > From owner-dns-security@lists.tislabs.com Fri Jun 25 17:16:47 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05584 for ; Fri, 25 Jun 1999 17:16:46 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA25701 Fri, 25 Jun 1999 15:51:25 -0400 (EDT) Message-Id: <199906251740.NAA28382@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dns-security@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnssec-externalkeys-00.txt Date: Fri, 25 Jun 1999 13:40:23 -0400 Sender: owner-dns-security@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Security Working Group of the IETF. Title : Inter-operability of Secure Domain Name System with Other Key Distribution Services Author(s) : J.R. Rao, M.P. Rao Filename : draft-ietf-dnssec-externalkeys-00.txt Pages : 8 Date : 24-Jun-99 There are several mechanisms for distributing public keys and certificates today. These distribution services publish certificates which contain cryptographic public keys. Clients that use any of these distribution services to retrieve certificates, require additional software for the retrieval, parsing and verification of these certificates. In this draft, we propose an alternate scheme that takes advantage of the Secure DNS infrastructure to distribute verified public keys obtained from other distribution services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnssec-externalkeys-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnssec-externalkeys-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnssec-externalkeys-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990624134144.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-externalkeys-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-externalkeys-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990624134144.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dns-security@lists.tislabs.com Fri Jun 25 17:31:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05940 for ; Fri, 25 Jun 1999 17:31:56 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA25919 Fri, 25 Jun 1999 16:30:26 -0400 (EDT) X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: <199906251740.NAA28382@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 25 Jun 1999 16:16:23 -0400 To: Internet-Drafts@ietf.org From: Edward Lewis Subject: Re: I-D ACTION:draft-ietf-dnssec-externalkeys-00.txt Cc: lewis@tislabs.com, dns-security@lists.tislabs.com Sender: owner-dns-security@lists.tislabs.com Precedence: bulk Since DNSSEC is not meeting in Oslo, and will, with 99 44/100% certainty, never meet again, perhaps this draft should be addressed to the DNSIND (or whatever its new name is to be). Just a suggestion - there might be something going on with the DNSSEC WG I haven't heard about. At 1:40 PM -0400 6/25/99, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Domain Name System Security Working Group >of the IETF. > > Title : Inter-operability of Secure Domain Name System with > Other Key Distribution Services > Author(s) : J.R. Rao, M.P. Rao > Filename : draft-ietf-dnssec-externalkeys-00.txt > Pages : 8 > Date : 24-Jun-99 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "Trying is the first step to failure." - Homer Simpson "No! Try not. Do... or do not. There is no try." - Yoda Opinions expressed are property of my evil twin, not my employer. From owner-dns-security@lists.tislabs.com Sat Jun 26 15:51:27 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06991 for ; Sat, 26 Jun 1999 15:51:26 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA28563 Sat, 26 Jun 1999 15:11:52 -0400 (EDT) Message-Id: <199906261911.MAA08114@bb.rc.vix.com> To: namedroppers@internic.net, dns-security@lists.tislabs.com Subject: Re: (Almost final) Agenda for dnsind/dnssec in Oslo In-reply-to: Your message of "Sun, 27 Jun 1999 01:29:54 +1000." <7186.930410994@munnari.OZ.AU> Date: Sat, 26 Jun 1999 12:11:04 -0700 From: Paul A Vixie Sender: owner-dns-security@lists.tislabs.com Precedence: bulk > For anyone who won't be in Oslo, feel free to begin (or continue) > discussions on any of these issues on the list. i, for example, will not be in oslo this year. > If I have listed your name beside a topic below, them I am expecting you to > lead the discussion. If you're unable, please let me know soon (and if > you can suggest a proxy, please do). > 4. Attempting to resolve rfc2052bis. (15 minutes) > > > > The IESG rejected rfc2052bis, and requested several changes. > So far, we haven't been able to agree on exactly what to do. > One option is to defer this indefinitely, or even drop it > (simply leave 2052 as the experimental protocol as it is). > Otherwise we need to find some way to satisfy the IESG demands > if we ever expect tos ee this one become a RFC. as microsoft has implemented rfc2052bis rather than rfc2052, we would need at a minimum to reissue rfc2052bis as an experimental. or a bcp, since it's in win2k and no other SRV usage is extant in the field. > 5. EDNS1 (10 minutes) Paul Vixie > > > > This draft is currently an ongoing work item. Please be > prepared to (briefly) suggest improvements, and/or where it > should go next. since i won't be in oslo, any edns1 comments will come to me via the list, either by direct comment or from the oslo notes being posted here. > 9. GSS Tsig (5 minutes) Stuart Kwan > > > An alternate algorithm for tsig. "additional" not "alternate". tsig specifies a base protocol and an initial algorithm (hmac-md5). gss-tsig is just another algorithm, not an alternative to the protocol. > 11. SECure-RR (5 minutes) Edward Lewis > > > This general topic has changed names several times (the dnsind > appellation is new, hence the -00). i very much hope that john gilmore will be at the oslo meeting to defend his point of view (that we can't deploy a new RR at this time if we're expecting to use dnssec widely this year.) > 14. Internationalising DNS Names (5 minutes) Stuart Kwan > there is also a UTF-5 proposal -- hopefully its proponent will be in oslo to explain why it's a viable alternative to stuart's utf-8 proposal. > Reading list: > > Note that a few of the drafts listed below are not yet available in > the I-D directories (these URLs will not yet work). They should be > available by the time the backlog of last minute drafts has drained. and updated versions of ISC's drafts are always at http://www.vix.com/ietf/. From owner-dns-security@lists.tislabs.com Sat Jun 26 21:09:01 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09014 for ; Sat, 26 Jun 1999 21:09:00 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA29032 Sat, 26 Jun 1999 20:26:43 -0400 (EDT) From: marka@isc.org Message-Id: <199906270025.KAA26041@bsdi.dv.isc.org> To: namedroppers@internic.net, dns-security@lists.tislabs.com Subject: Re: (Almost final) Agenda for dnsind/dnssec in Oslo In-reply-to: Your message of "Sun, 27 Jun 1999 01:29:54 +1000." <7186.930410994@munnari.OZ.AU> Date: Sun, 27 Jun 1999 10:25:49 +1000 Sender: owner-dns-security@lists.tislabs.com Precedence: bulk > 16. Verifying Resource Records (5 minutes) Mark Andrews > > I won't be at Oslo either, impending fatherhood. This needs to be looked at along with draft-ietf-dnsind-local-compression-04.txt as they are alternatives to the same problem. The major problem with local-compression is once it is used you have to use it for all time for that RR as it is the compressed form that is signed not the uncompressed. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-dns-security@lists.tislabs.com Sun Jun 27 22:51:50 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07576 for ; Sun, 27 Jun 1999 22:51:50 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA01391 Sun, 27 Jun 1999 22:02:14 -0400 (EDT) From: marka@isc.org Message-Id: <199906280159.LAA29666@bsdi.dv.isc.org> To: Robert Elz cc: namedroppers@internic.net, dns-security@lists.tislabs.com Subject: Re: (Almost final) Agenda for dnsind/dnssec in Oslo In-reply-to: Your message of "Mon, 28 Jun 1999 01:21:00 +1000." <19551.930496860@munnari.OZ.AU> Date: Mon, 28 Jun 1999 11:59:48 +1000 Sender: owner-dns-security@lists.tislabs.com Precedence: bulk > Date: Sun, 27 Jun 1999 10:25:49 +1000 > From: marka@isc.org > Message-ID: <199906270025.KAA26041@bsdi.dv.isc.org> > > | > 16. Verifying Resource Records (5 minutes) Mark Andrews > | > > | > > | I won't be at Oslo either, impending fatherhood. This needs to be > | looked at along with draft-ietf-dnsind-local-compression-04.txt as > | they are alternatives to the same problem. > > OK. And thanks for the reminder, somehow I had managed to omit > local-compression from the agenda... It is there now, to be considered > along with verify (in a longer slot for the two of them, using time > taken from the edns1 slot, as it doesn't appear there will be as much > discussion of that one as I had anticipated there might be). > > | The major problem with local-compression is once it is used you > | have to use it for all time for that RR as it is the compressed > | form that is signed not the uncompressed. > > Would you like to expand upon this a little please? > > While I certainly understand that a server for a signed zone will always > return the same data, and in this case, that means the same format as > well, but I'm not sure how that extends to "all time". Maybe I'm missing > something, I'm certainly no dnssec expert, or even competent, but I would > have thought that when the zone is re-signed, nothing that had been there > before would matter too much - that is, if the server is upgraded such that > it now supports some new functionality, and then the zone is re-signed, could > not the RR that was using local-compression (in this particular zone) now > switch to something different? No, as global compression *may* cause case conversion, we can't use EDNS to say we know about this RR and hence use global compression unless we also state that all domain names in RRs that are to be locally compressed MUST be down cased. Also there is no definition of exactly how to arrive at the same bit patten given that you can have a LCP (local compression pointer) -> LCP -> label. Also there are cases where using a LCP will make the resulting wire form larger than the uncompressed form, do we use LC or not? > > I would have also assumed (perhaps totally incorrectly) that it would be > possible for the server to keep two signed representations of the RR, and > simply emit whichever one best met the needs of the resolver making the > query, if that seemed to be a good thing to do. You would have to emit both as in intermediate client (forwarder chain) may require the compressed signature where the current client needs the uncompressed one. This assumes both will get sent on and the one that didn't verify was not discarded. Mark > > kre > -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-dns-security@lists.tislabs.com Sun Jun 27 23:23:02 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07818 for ; Sun, 27 Jun 1999 23:23:02 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA01477 Sun, 27 Jun 1999 22:45:31 -0400 (EDT) From: marka@isc.org Message-Id: <199906280244.MAA00336@bsdi.dv.isc.org> To: namedroppers@internic.net, dns-security@lists.tislabs.com Subject: Re: (Almost final) Agenda for dnsind/dnssec in Oslo In-reply-to: Your message of "Mon, 28 Jun 1999 11:59:48 +1000." Date: Mon, 28 Jun 1999 12:44:47 +1000 Sender: owner-dns-security@lists.tislabs.com Precedence: bulk > No, as global compression *may* cause case conversion, we > can't use EDNS to say we know about this RR and hence use > global compression unless we also state that all domain > names in RRs that are to be locally compressed MUST be down > cased. Also there is no definition of exactly how to arrive > at the same bit patten given that you can have a LCP (local > compression pointer) -> LCP -> label. Also there are cases > where using a LCP will make the resulting wire form larger > than the uncompressed form, do we use LC or not? I forgot to mention that some of these issues preclude the use of master files for the transport of zones between servers or even between signing software and servers from different vendors (I assuming here that the way LC is done by a vendor will be consistent between the server and the signer, this is not always a safe assumption). Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-dns-security@lists.tislabs.com Mon Jun 28 06:47:02 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24306 for ; Mon, 28 Jun 1999 06:47:02 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA03187 Mon, 28 Jun 1999 04:50:12 -0400 (EDT) Message-Id: <199906280849.BAA18446@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Paul A Vixie cc: namedroppers@internic.net, dns-security@lists.tislabs.com, gnu@toad.com Subject: Re: (Almost final) Agenda for dnsind/dnssec in Oslo In-reply-to: <199906261911.MAA08114@bb.rc.vix.com> Date: Mon, 28 Jun 1999 01:49:48 -0700 From: John Gilmore Sender: owner-dns-security@lists.tislabs.com Precedence: bulk > > 11. SECure-RR (5 minutes) Edward Lewis > > > i very much hope that john gilmore will be at the oslo meeting to defend his > point of view (that we can't deploy a new RR at this time if we're expecting > to use dnssec widely this year.) I won't be in Oslo, unfortunately. Hugh Daniel will be there, but he doesn't have the history. Deploying an RR type that only exists in superzones is not quite as bad as deploying one that exists everywhere. The number of superzones is smaller than the number of zones, and the most critical superzones (. and .com and etc) are running on machines that "nominally" always upgrade to the latest BIND anyway, so they'll be able to serve new RR types. Having scanned the draft once: Summary: REJECT WITH PREJUDICE. Poorly defined, unnecessarily complex, doesn't solve the problem it claims to, doesn't even address the real problems of DNSSEC. The biggest problem with DNSSEC appears to be paper designs that do not benefit from operational evolution. In other words, DNSSEC is not going through the winning part of the IETF process (draft, implement, try, redraft, implement, try, ... standardize). Instead we go through a series of paper specs trying to standardize them with no operational experience. Note I said operational, not programming. I suggest that we operate with the specs we have and learn from 'em. THEN change 'em. This paper design continues many of the problems of prior DNSSEC drafts; it lays out grand schemes without considering the operational details. The open-ended "Security parameters of a zone" is one example (including things like "Signature policy. This is an untested issue."). The draft goes to even more ridiculous lengths than NXT to secure negative answers. (NXT more than doubles the size of your zone, to give definitive "NO"s for names that aren't in the zone.) In addition to NXT, we now have a bitmap in the parent zone (!!!) that gives five options on how the child zone might handle negative answers. These options can be used in combination. (At least if the WG thinks this level of abomination is needed, it should be expressed in the child zone rather than in the parent. Such a record in the child would be signed by the zone key, so it can't be spoofed. Though I suppose its *absence* could be spoofed, hmm...) Then we get to the meat. The SEC record doesn't really have fields that specify security parameters. Instead it holds little sub-packets, each of which has to be parsed, each of which specifies security parameters. These sub-packets have option specifier bytes, optional lengths, and data. The length of most of the options is defined in the spec, so that when new options are added, all existing implementations will be unable to parse them. The draft specifies various combinations of options that are not permitted together. I don't see why we don't just go straight to X.509 and ASN.1 instead -- it's simpler and easier. The text file format is highly readable, consisting of a series of hex numbers. (At least the numbers are in hex; the DNSSEC KEY record has bit-flags expressed in decimal.) The parsing of the hex is screwy; some fields have 0x, some do not, and this difference appears to have some meaning, though it's not clear what meaning. The draft claims it's a successor to Zone Key Referral by me and Jerry Scharf. Did I really do that? It doesn't actually include the name of the Zone Key Referral draft, but elsewhere it says it's "by the same authors" (as itself, presumably). John From owner-dns-security@lists.tislabs.com Mon Jun 28 10:11:17 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00548 for ; Mon, 28 Jun 1999 10:11:16 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04049 Mon, 28 Jun 1999 09:27:25 -0400 (EDT) X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: <199906280849.BAA18446@toad.com> References: <199906261911.MAA08114@bb.rc.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Jun 1999 07:11:03 -0400 To: John Gilmore From: Edward Lewis Subject: Re: (Almost final) Agenda for dnsind/dnssec in Oslo Cc: Paul A Vixie , namedroppers@internic.net, dns-security@lists.tislabs.com, gnu@toad.com Sender: owner-dns-security@lists.tislabs.com Precedence: bulk At 4:49 AM -0400 6/28/99, John Gilmore wrote: >Summary: REJECT WITH PREJUDICE. Poorly defined, unnecessarily complex, >doesn't solve the problem it claims to, doesn't even address the >real problems of DNSSEC. Hey - it's a -00. I'd like to hear comments from operators, but there aren't many yet. One question - is the problem statement right? I'd like to at least get that straightened up before trying to solve the wrong problem. >The draft claims it's a successor to Zone Key Referral by me and Jerry >Scharf. Did I really do that? It doesn't actually include the name of >the Zone Key Referral draft, but elsewhere it says it's "by the same >authors" (as itself, presumably). I figured that the SEC RR might not be a cure all, but I wanted to describe the idea in detail. By linking the two drafts, I was trying to save folks time if they planned to read both - I copied vast amounts of text in the introduction from Referral to SEC. However, I wasn't confident that the SEC RR would fly far, so I also kept the names separate. As far as putting planning ahead of implementation, the excuse is that "isn't getting something secure" a bit different that "getting something to work?" (I'll leave the question as that for now.) One reason there's a lot of planning smoke around even without much operational fire is the need to secure dynamic update. There are still issues there. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "Trying is the first step to failure." - Homer Simpson "No! Try not. Do... or do not. There is no try." - Yoda Opinions expressed are property of my evil twin, not my employer. From owner-dns-security@lists.tislabs.com Mon Jun 28 10:13:55 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00610 for ; Mon, 28 Jun 1999 10:13:54 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04061 Mon, 28 Jun 1999 09:28:24 -0400 (EDT) From: Robert Elz To: namedroppers@internic.net Cc: dns-security@lists.tislabs.com Subject: (Almost final) Agenda for dnsind/dnssec in Oslo Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 27 Jun 1999 01:29:54 +1000 Message-Id: <7186.930410994@munnari.OZ.AU> Sender: owner-dns-security@lists.tislabs.com Precedence: bulk If there are any more requests related to this agenda, you will need to send them soon - the agenda needs to be at the secretariat by Thursday (after which I will be out of e-mail contact for almost a week - and for this I mean Thursday Australian time, not US). For anyone who won't be in Oslo, feel free to begin (or continue) discussions on any of these issues on the list. The dns* meeting is scheduelled for Monday July 12, 15:30, in the Kunst room (but don't believe the room until you get to Oslo and see it confirmed there). If I have listed your name beside a topic below, them I am expecting you to lead the discussion. If you're unable, please let me know soon (and if you can suggest a proxy, please do). Please don't bring a prepared presentation - or at most no more than one or two slides (max of *one* for a 5 minute slot), for any of these. We have a very full workload, and no time to go through what is in drafts for the benefit of those who have not read them. Where no name is listed, Randy, Jim Galvin, or I (or some combination thereof) will be looking after it. As listed below, the 2 hour slot is fully allocated, though it is possible that one or two of the items below might be relegated to the list. To all - expect the time limits below to be rigorously enforced. Please assist by making as many comments as you can via e-mail in advance of the meeting. The meeting *will* start on time! 1. Administrativia, agenda bashing, etc (3 minutes) 2. Review of current PS RFCs and progress on advancing them. (5 minutes) rfc1982 rfc1995 rfc1996 rfc2136 rfc2137 rfc2181 rfc2308 rfc2535 rfc2536 rfc2537 rfc2538 rfc2539 3. Updating status on all known dns* drafts (15 minutes) The idea here is that we go through everything which seems to be on the dns* plate, and determine just what we're really working on, what the priority for eevrything is, when we expect to complete each doc, and what status we currently expect they will have. 4. Attempting to resolve rfc2052bis. (15 minutes) The IESG rejected rfc2052bis, and requested several changes. So far, we haven't been able to agree on exactly what to do. One option is to defer this indefinitely, or even drop it (simply leave 2052 as the experimental protocol as it is). Otherwise we need to find some way to satisfy the IESG demands if we ever expect tos ee this one become a RFC. 5. EDNS1 (10 minutes) Paul Vixie This draft is currently an ongoing work item. Please be prepared to (briefly) suggest improvements, and/or where it should go next. Securing the DNS ... 6. TKey (5 minutes) Don Eastlake Now tsig is (apparently) done, it makes sense to get tkey out there following it asap, if it is ever going to. 7. Simple Secure Update (10 minutes) Brian Wellington This shows how to secure dns dynamic update using tsig. How close are we to being finished with this draft? (the -00 is misleading, it moved from dnssec) 8. DNSSEC update (update2) (10 minutes) Don Eastlake (or later draft if it appears) The alternative (original) way of securing DNS updates. This is an intended replacement for rfc2137. 9. GSS Tsig (5 minutes) Stuart Kwan An alternate algorithm for tsig. 10. Security Key Rollover (5 minutes) Don Eastlake Dealing with key time rollover (since the time is imbedded in a fixed width field, it has to rollover sometime - this draft specifies how that works). New Resource Records... 11. SECure-RR (5 minutes) Edward Lewis This general topic has changed names several times (the dnsind appellation is new, hence the -00). 12. Kitchen Sink RR (5 minutes) Don Eastlake This has also changed names, it has been floating for ages. 13. Address Prefix List RR (5 minutes) Peter Koch Extended functionality... 14. Internationalising DNS Names (5 minutes) Stuart Kwan 15. Deferred Dynamic Delete (5 minutes) Brian Wellington 16. Verifying Resource Records (5 minutes) Mark Andrews 17. Local Names (5 minutes) Don Eastlake Reading list: Note that a few of the drafts listed below are not yet available in the I-D directories (these URLs will not yet work). They should be available by the time the backlog of last minute drafts has drained. For access via HTTP: http://www.ietf.org/internet-drafts/draft-ietf-dnsind-apl-rr-02.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsind-dddd-01.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsind-edns1-03.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsind-kitchen-sink-00.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsind-local-names-07.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsind-rfc2052bis-02.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsind-rollover-00.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsind-sec-rr-00.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsind-simple-secure-update-00.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsind-verify-00.txt http://www.ietf.org/internet-drafts/draft-ietf-dnssec-tkey-01.txt http://www.ietf.org/internet-drafts/draft-ietf-dnssec-update2-00.txt http://www.ietf.org/internet-drafts/draft-skwan-gss-tsig-04.txt http://www.ietf.org/internet-drafts/draft-skwan-utf8-dns-02.txt (or) for access via FTP: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsind-apl-rr-02.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsind-dddd-01.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsind-edns1-03.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsind-kitchen-sink-00.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsind-local-names-07.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsind-rfc2052bis-02.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsind-rollover-00.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsind-sec-rr-00.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsind-simple-secure-update-00.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsind-verify-00.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnssec-tkey-01.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnssec-update2-00.txt ftp://ftp.ietf.org/internet-drafts/draft-skwan-gss-tsig-04.txt ftp://ftp.ietf.org/internet-drafts/draft-skwan-utf8-dns-02.txt From owner-dns-security@lists.tislabs.com Mon Jun 28 10:18:27 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00742 for ; Mon, 28 Jun 1999 10:18:26 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04100 Mon, 28 Jun 1999 09:29:24 -0400 (EDT) From: Robert Elz To: Paul A Vixie Cc: namedroppers@internic.net, dns-security@lists.tislabs.com Subject: Re: (Almost final) Agenda for dnsind/dnssec in Oslo In-Reply-To: Your message of "Sat, 26 Jun 1999 12:11:04 MST." <199906261911.MAA08114@bb.rc.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 28 Jun 1999 01:02:54 +1000 Message-Id: <19445.930495774@munnari.OZ.AU> Sender: owner-dns-security@lists.tislabs.com Precedence: bulk Date: Sat, 26 Jun 1999 12:11:04 -0700 From: Paul A Vixie Message-ID: <199906261911.MAA08114@bb.rc.vix.com> | we would need at a minimum to reissue rfc2052bis as an experimental. That is certainly an option. | or a bcp, since it's in | win2k and no other SRV usage is extant in the field. I think PS would raise less obstacles than BCP... | "additional" not "alternate". tsig specifies a base protocol and an | initial algorithm (hmac-md5). gss-tsig is just another algorithm, not | an alternative to the protocol. Unfortunate choice of words on my part ... that's exactly what I meant, an alternative for the application to choose, not an alternative to the protocol. | there is also a UTF-5 proposal -- hopefully its proponent will be in oslo to | explain why it's a viable alternative to stuart's utf-8 proposal. I have not seen that one. Do you have a reference? kre From owner-dns-security@lists.tislabs.com Mon Jun 28 10:20:47 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00826 for ; Mon, 28 Jun 1999 10:20:46 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04097 Mon, 28 Jun 1999 09:29:23 -0400 (EDT) From: Robert Elz To: marka@isc.org Cc: namedroppers@internic.net, dns-security@lists.tislabs.com Subject: Re: (Almost final) Agenda for dnsind/dnssec in Oslo In-Reply-To: Your message of "Sun, 27 Jun 1999 10:25:49 +1000." <199906270025.KAA26041@bsdi.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 28 Jun 1999 01:21:00 +1000 Message-Id: <19551.930496860@munnari.OZ.AU> Sender: owner-dns-security@lists.tislabs.com Precedence: bulk Date: Sun, 27 Jun 1999 10:25:49 +1000 From: marka@isc.org Message-ID: <199906270025.KAA26041@bsdi.dv.isc.org> | > 16. Verifying Resource Records (5 minutes) Mark Andrews | > | > | I won't be at Oslo either, impending fatherhood. This needs to be | looked at along with draft-ietf-dnsind-local-compression-04.txt as | they are alternatives to the same problem. OK. And thanks for the reminder, somehow I had managed to omit local-compression from the agenda... It is there now, to be considered along with verify (in a longer slot for the two of them, using time taken from the edns1 slot, as it doesn't appear there will be as much discussion of that one as I had anticipated there might be). | The major problem with local-compression is once it is used you | have to use it for all time for that RR as it is the compressed | form that is signed not the uncompressed. Would you like to expand upon this a little please? While I certainly understand that a server for a signed zone will always return the same data, and in this case, that means the same format as well, but I'm not sure how that extends to "all time". Maybe I'm missing something, I'm certainly no dnssec expert, or even competent, but I would have thought that when the zone is re-signed, nothing that had been there before would matter too much - that is, if the server is upgraded such that it now supports some new functionality, and then the zone is re-signed, could not the RR that was using local-compression (in this particular zone) now switch to something different? I would have also assumed (perhaps totally incorrectly) that it would be possible for the server to keep two signed representations of the RR, and simply emit whichever one best met the needs of the resolver making the query, if that seemed to be a good thing to do. kre From owner-dns-security@lists.tislabs.com Mon Jun 28 10:21:11 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00851 for ; Mon, 28 Jun 1999 10:21:10 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04050 Mon, 28 Jun 1999 09:27:26 -0400 (EDT) Message-Id: <4.2.0.56.19990628144601.02388af0@dokka.maxware.no> X-Sender: hta@dokka.maxware.no X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.56 (Beta) Date: Mon, 28 Jun 1999 14:47:46 +0200 To: Edward Lewis , John Gilmore From: Harald Tveit Alvestrand Subject: Re: (Almost final) Agenda for dnsind/dnssec in Oslo Cc: Paul A Vixie , namedroppers@internic.net, dns-security@lists.tislabs.com, gnu@toad.com In-Reply-To: References: <199906280849.BAA18446@toad.com> <199906261911.MAA08114@bb.rc.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-dns-security@lists.tislabs.com Precedence: bulk At 07:11 28.06.99 -0400, Edward Lewis wrote: >As far as putting planning ahead of implementation, the excuse is that >"isn't getting something secure" a bit different that "getting something to >work?" (I'll leave the question as that for now.) actually I think not - "secure" can never mean more than "secure against a certain class of attacks". So you can see the "working" here as "a particular attack fails". There are ALWAYS other attack paths. Harald A -- Harald Tveit Alvestrand, Maxware, Norway Harald.Alvestrand@maxware.no From owner-dns-security@lists.tislabs.com Mon Jun 28 10:22:13 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00870 for ; Mon, 28 Jun 1999 10:22:13 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04012 Mon, 28 Jun 1999 09:26:24 -0400 (EDT) X-Authentication-Warning: spiral.gw.tislabs.com: bwelling owned process doing -bs Date: Sat, 26 Jun 1999 21:48:20 -0400 (EDT) From: Brian Wellington X-Sender: bwelling@spiral.gw.tislabs.com To: Robert Elz cc: namedroppers@internic.net, dns-security@lists.tislabs.com Subject: Re: (Almost final) Agenda for dnsind/dnssec in Oslo In-Reply-To: <7186.930410994@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@lists.tislabs.com Precedence: bulk On Sun, 27 Jun 1999, Robert Elz wrote: > For anyone who won't be in Oslo, feel free to begin (or continue) > discussions on any of these issues on the list. I won't be in Oslo either. > If I have listed your name beside a topic below, them I am expecting you to > lead the discussion. If you're unable, please let me know soon (and if > you can suggest a proxy, please do). Ed Lewis should be able to talk about simple secure update and deferred delete. > 7. Simple Secure Update (10 minutes) Brian Wellington > > > This shows how to secure dns dynamic update using tsig. > How close are we to being finished with this draft? > (the -00 is misleading, it moved from dnssec) Based on feedback from the last IETF and various discussions recently, I modified the draft to allow updates to be signed by DNSSEC SIG(0) transaction signatures as well as TSIG records. This doesn't change the fundamental nature of the draft, and should make it more acceptable, since it doesn't have the scaling problems associated with TSIG manual configuration. -01 was submitted Friday at about 11AM EDT, so it should be announced soon (if it hasn't been announced already). dnssec-simple-update-01 and dnsind-simple-secure-update-00 were identical, so the numbering is only one off... > 15. Deferred Dynamic Delete (5 minutes) Brian Wellington > The only major change since -00 is that the TTL modification policy has been changed from reuired to optional, and several vague sections were cleaned up. There have been no changes or comments since -01 was written in mid April. If there are any comments, I'll try to address them here. Brian From owner-dns-security@lists.tislabs.com Mon Jun 28 13:57:27 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08254 for ; Mon, 28 Jun 1999 13:57:26 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05133 Mon, 28 Jun 1999 12:31:27 -0400 (EDT) Message-Id: <199906281508.KAA06462@gungnir.fnal.gov> To: namedroppers@internic.net, dns-security@lists.tislabs.com From: "Matt Crawford" Subject: Re: (Almost final) Agenda for dnsind/dnssec in Oslo In-reply-to: Your message of Sat, 26 Jun 1999 12:11:04 PDT. <199906261911.MAA08114@bb.rc.vix.com> Date: Mon, 28 Jun 1999 10:08:28 -0500 Sender: owner-dns-security@lists.tislabs.com Precedence: bulk > as microsoft has implemented rfc2052bis rather than rfc2052, we would need at > a minimum to reissue rfc2052bis as an experimental. or a bcp, since it's in > win2k and no other SRV usage is extant in the field. There are some (non-MS) Kerberos 5 implementations that use 2052bis -- NOT 2052 -- style lookups to locate the KDCs for a realm. Matt From owner-dns-security@lists.tislabs.com Mon Jun 28 13:59:26 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08328 for ; Mon, 28 Jun 1999 13:59:25 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05161 Mon, 28 Jun 1999 12:33:28 -0400 (EDT) Message-Id: <199906281546.LAA16872@r93aag001866.sbo-smr.ma.cable.rcn.com> To: John Gilmore Cc: namedroppers@internic.net, dns-security@lists.tislabs.com Subject: Re: (Almost final) Agenda for dnsind/dnssec in Oslo In-Reply-To: Your message of "Mon, 28 Jun 1999 01:49:48 PDT." <199906280849.BAA18446@toad.com> Date: Mon, 28 Jun 1999 11:46:18 EDT From: Greg Hudson Sender: owner-dns-security@lists.tislabs.com Precedence: bulk > [Criticism of encoding in SEC RR] > I don't see why we don't just go straight to X.509 and ASN.1 instead > -- it's simpler and easier. If anyone is considering using an externally specified encoding schemes in drafts (this one or others), I'd appreciate it if they could consider simpler alternatives to ASN.1/BER. My own simpler alternative is SPADE: http://www.ietf.org/internet-drafts/draft-hudson-spade-01.txt And there's also XDR (RFC 1832), which is perfectly capable of standing apart from sunrpc. (I'm deliberately omitting XML here; I don't think it's simpler than ASN.1 and I doubt anyone would propose using such a verbose encoding for DNS.) I realize that the phrase "X.509 and ASN.1" covers directory stuff as well as data encoding, so XDR or SPADE would only do half of what John was talking about. But a full-fledged directory may not be necessary here. Anyway, apologies for the digression. The IETF doesn't have a working group or other forum to discuss encodings (as far as I know), so I kind of have to pipe up whenever I see the topic come up in a working group list I follow. From owner-dns-security@lists.tislabs.com Mon Jun 28 14:04:08 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08556 for ; Mon, 28 Jun 1999 14:04:07 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05029 Mon, 28 Jun 1999 12:10:27 -0400 (EDT) Message-Id: <199906281457.QAA00098@gunilla.TechFak.Uni-Bielefeld.DE> To: namedroppers@internic.net, dns-security@lists.tislabs.com Subject: Re: (Almost final) Agenda for dnsind/dnssec in Oslo In-reply-to: Mark Andrews' message of "Mon, 28 Jun 1999 12:44:47 +1000." <199906280244.MAA00336@bsdi.dv.isc.org> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Date: Mon, 28 Jun 1999 16:57:54 +0200 From: Peter Koch Sender: owner-dns-security@lists.tislabs.com Precedence: bulk Version -05 of the local compression draft should be announced soon (also at http://www.TechFak.Uni-Bielefeld.DE/~pk/dns/draft-ietf-dnsind-local-compression-05.txt) The relevant change compared to -04 is some text to address this problem: > > cased. Also there is no definition of exactly how to arrive > > at the same bit patten given that you can have a LCP (local > > compression pointer) -> LCP -> label. Also there are cases By mandating "optimal" compression and usage of the earliest occurence of a possible target, pointer chains like above are now implicitly disallowed. > > where using a LCP will make the resulting wire form larger > > than the uncompressed form, do we use LC or not? The only case I see is a terminating zero octet as a compression target. Section 6 forbids this case. Anything else has at least a one character top level domain resulting in three octets ('1', , '0'), which is less than a pointer. Maybe I missed something? > I forgot to mention that some of these issues preclude the > use of master files for the transport of zones between servers > or even between signing software and servers from different > vendors (I assuming here that the way LC is done by a vendor > will be consistent between the server and the signer, this is > not always a safe assumption). Although I believe this can be solved for local compression this item should be considered in general. In the chain -> --(AXFR)-> -> , which reflects the data path BIND and probably others use, can one assume that both representations are identical? Is the unambiguously derived from the ? At least for TXT RRs differences may exist, should the input "string" exceed 255 characters. -Peter From owner-dns-security@lists.tislabs.com Mon Jun 28 14:56:31 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10021 for ; Mon, 28 Jun 1999 14:56:30 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05436 Mon, 28 Jun 1999 13:18:38 -0400 (EDT) X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: <199906281546.LAA16872@r93aag001866.sbo-smr.ma.cable.rcn.com> References: Your message of "Mon, 28 Jun 1999 01:49:48 PDT." <199906280849.BAA18446@toad.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Jun 1999 13:14:41 -0400 To: Greg Hudson From: Edward Lewis Subject: Re: (Almost final) Agenda for dnsind/dnssec in Oslo Cc: John Gilmore , namedroppers@internic.net, dns-security@lists.tislabs.com Sender: owner-dns-security@lists.tislabs.com Precedence: bulk I wasn't proposing anything like ASN.1 - more like DHCP (or the OPT RR) options. At 11:46 AM -0400 6/28/99, Greg Hudson wrote: >> [Criticism of encoding in SEC RR] >> I don't see why we don't just go straight to X.509 and ASN.1 instead >> -- it's simpler and easier. > >If anyone is considering using an externally specified encoding >schemes in drafts (this one or others), I'd appreciate it if they >could consider simpler alternatives to ASN.1/BER. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "Trying is the first step to failure." - Homer Simpson "No! Try not. Do... or do not. There is no try." - Yoda Opinions expressed are property of my evil twin, not my employer. From owner-dns-security@lists.tislabs.com Tue Jun 29 00:38:17 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22271 for ; Tue, 29 Jun 1999 00:38:17 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA09033 Mon, 28 Jun 1999 23:52:14 -0400 (EDT) Message-ID: From: Stuart Kwan To: "'Robert Elz'" , namedroppers@internic.net Cc: dns-security@lists.tislabs.com Subject: RE: (Almost final) Agenda for dnsind/dnssec in Oslo Date: Mon, 28 Jun 1999 19:50:18 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-dns-security@lists.tislabs.com Precedence: bulk Unfortunately, Levon Esibov and I will not be attending in Oslo. I have no suitable proxy to lead a discussion on UTF-8 DNS (ftp://ftp.ietf.org/internet-drafts/draft-skwan-utf8-dns-02.txt) or on the GSS algorithm for TSIG (http://www.ietf.org/internet-drafts/draft-skwan-gss-tsig-04.txt), so you may remove those from the schedule. Both Levon and I would be happy to hear comments on the mailing list. No surprise, I'd like to see rfc2052bis (ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsind-rfc2052bis-02.txt) take another shot at PS. I thought the WG had a good rebuttal for all the issues raised by the IESG. I'll see if I can grep the discussion out of the archive. Cheers, - Stuart -----Original Message----- From: Robert Elz [mailto:kre@MUNNARI.OZ.AU] Sent: Saturday, June 26, 1999 8:30 AM To: namedroppers@internic.net Cc: dns-security@lists.tislabs.com Subject: (Almost final) Agenda for dnsind/dnssec in Oslo If there are any more requests related to this agenda, you will need to send them soon - the agenda needs to be at the secretariat by Thursday (after which I will be out of e-mail contact for almost a week - and for this I mean Thursday Australian time, not US). For anyone who won't be in Oslo, feel free to begin (or continue) discussions on any of these issues on the list. The dns* meeting is scheduelled for Monday July 12, 15:30, in the Kunst room (but don't believe the room until you get to Oslo and see it confirmed there). If I have listed your name beside a topic below, them I am expecting you to lead the discussion. If you're unable, please let me know soon (and if you can suggest a proxy, please do). Please don't bring a prepared presentation - or at most no more than one or two slides (max of *one* for a 5 minute slot), for any of these. We have a very full workload, and no time to go through what is in drafts for the benefit of those who have not read them. Where no name is listed, Randy, Jim Galvin, or I (or some combination thereof) will be looking after it. As listed below, the 2 hour slot is fully allocated, though it is possible that one or two of the items below might be relegated to the list. To all - expect the time limits below to be rigorously enforced. Please assist by making as many comments as you can via e-mail in advance of the meeting. The meeting *will* start on time! 1. Administrativia, agenda bashing, etc (3 minutes) 2. Review of current PS RFCs and progress on advancing them. (5 minutes) rfc1982 rfc1995 rfc1996 rfc2136 rfc2137 rfc2181 rfc2308 rfc2535 rfc2536 rfc2537 rfc2538 rfc2539 3. Updating status on all known dns* drafts (15 minutes) The idea here is that we go through everything which seems to be on the dns* plate, and determine just what we're really working on, what the priority for eevrything is, when we expect to complete each doc, and what status we currently expect they will have. 4. Attempting to resolve rfc2052bis. (15 minutes) The IESG rejected rfc2052bis, and requested several changes. So far, we haven't been able to agree on exactly what to do. One option is to defer this indefinitely, or even drop it (simply leave 2052 as the experimental protocol as it is). Otherwise we need to find some way to satisfy the IESG demands if we ever expect tos ee this one become a RFC. 5. EDNS1 (10 minutes) Paul Vixie This draft is currently an ongoing work item. Please be prepared to (briefly) suggest improvements, and/or where it should go next. Securing the DNS ... 6. TKey (5 minutes) Don Eastlake Now tsig is (apparently) done, it makes sense to get tkey out there following it asap, if it is ever going to. 7. Simple Secure Update (10 minutes) Brian Wellington This shows how to secure dns dynamic update using tsig. How close are we to being finished with this draft? (the -00 is misleading, it moved from dnssec) 8. DNSSEC update (update2) (10 minutes) Don Eastlake (or later draft if it appears) The alternative (original) way of securing DNS updates. This is an intended replacement for rfc2137. 9. GSS Tsig (5 minutes) Stuart Kwan An alternate algorithm for tsig. 10. Security Key Rollover (5 minutes) Don Eastlake Dealing with key time rollover (since the time is imbedded in a fixed width field, it has to rollover sometime - this draft specifies how that works). New Resource Records... 11. SECure-RR (5 minutes) Edward Lewis This general topic has changed names several times (the dnsind appellation is new, hence the -00). 12. Kitchen Sink RR (5 minutes) Don Eastlake This has also changed names, it has been floating for ages. 13. Address Prefix List RR (5 minutes) Peter Koch Extended functionality... 14. Internationalising DNS Names (5 minutes) Stuart Kwan 15. Deferred Dynamic Delete (5 minutes) Brian Wellington 16. Verifying Resource Records (5 minutes) Mark Andrews 17. Local Names (5 minutes) Don Eastlake Reading list: Note that a few of the drafts listed below are not yet available in the I-D directories (these URLs will not yet work). They should be available by the time the backlog of last minute drafts has drained. For access via HTTP: http://www.ietf.org/internet-drafts/draft-ietf-dnsind-apl-rr-02.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsind-dddd-01.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsind-edns1-03.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsind-kitchen-sink-00.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsind-local-names-07.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsind-rfc2052bis-02.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsind-rollover-00.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsind-sec-rr-00.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsind-simple-secure-update-0 0.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsind-verify-00.txt http://www.ietf.org/internet-drafts/draft-ietf-dnssec-tkey-01.txt http://www.ietf.org/internet-drafts/draft-ietf-dnssec-update2-00.txt http://www.ietf.org/internet-drafts/draft-skwan-gss-tsig-04.txt http://www.ietf.org/internet-drafts/draft-skwan-utf8-dns-02.txt (or) for access via FTP: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsind-apl-rr-02.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsind-dddd-01.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsind-edns1-03.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsind-kitchen-sink-00.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsind-local-names-07.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsind-rfc2052bis-02.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsind-rollover-00.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsind-sec-rr-00.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsind-simple-secure-update-00 .txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsind-verify-00.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnssec-tkey-01.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnssec-update2-00.txt ftp://ftp.ietf.org/internet-drafts/draft-skwan-gss-tsig-04.txt ftp://ftp.ietf.org/internet-drafts/draft-skwan-utf8-dns-02.txt From owner-dns-security@lists.tislabs.com Tue Jun 29 11:30:47 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13364 for ; Tue, 29 Jun 1999 11:30:47 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA10955 Tue, 29 Jun 1999 09:13:33 -0400 (EDT) From: marka@isc.org Message-Id: <199906282214.IAA06442@bsdi.dv.isc.org> To: Peter Koch cc: namedroppers@internic.net, dns-security@lists.tislabs.com Subject: Re: (Almost final) Agenda for dnsind/dnssec in Oslo In-reply-to: Your message of "Mon, 28 Jun 1999 16:57:54 +0200." <199906281457.QAA00098@gunilla.TechFak.Uni-Bielefeld.DE> Date: Tue, 29 Jun 1999 08:14:41 +1000 Sender: owner-dns-security@lists.tislabs.com Precedence: bulk > Version -05 of the local compression draft should be announced soon (also at > http://www.TechFak.Uni-Bielefeld.DE/~pk/dns/draft-ietf-dnsind-local-compressi > on-05.txt) > > The relevant change compared to -04 is some text to address this problem: > > > > cased. Also there is no definition of exactly how to arrive > > > at the same bit patten given that you can have a LCP (local > > > compression pointer) -> LCP -> label. Also there are cases > > By mandating "optimal" compression and usage of the earliest occurence of > a possible target, pointer chains like above are now implicitly disallowed. > > > > where using a LCP will make the resulting wire form larger > > > than the uncompressed form, do we use LC or not? > > The only case I see is a terminating zero octet as a compression target. > Section 6 forbids this case. Anything else has at least a one character top > level domain resulting in three octets ('1', , '0'), which is less than > a pointer. Maybe I missed something? Bit string labels. > > > I forgot to mention that some of these issues preclude the > > use of master files for the transport of zones between servers > > or even between signing software and servers from different > > vendors (I assuming here that the way LC is done by a vendor > > will be consistent between the server and the signer, this is > > not always a safe assumption). > > Although I believe this can be solved for local compression this item should > be considered in general. In the chain -> --(AXFR > )-> > -> , which reflects the data path BIND and probabl > y > others use, can one assume that both representations are > identical? Is the unambiguously derived from the ? > At least for TXT RRs differences may exist, should the input "string" exceed > 255 characters. If you have a TXT example where the two wire formats differ it is a bug and I would like to see it so it can be fixed. > > -Peter > Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-dns-security@lists.tislabs.com Wed Jun 30 10:22:26 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17299 for ; Wed, 30 Jun 1999 10:22:25 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA17791 Wed, 30 Jun 1999 09:18:33 -0400 (EDT) From: marka@isc.org Message-Id: <199906300218.MAA16529@bsdi.dv.isc.org> To: namedroppers@internic.net, dns-security@lists.tislabs.com Subject: Re: (Almost final) Agenda for dnsind/dnssec in Oslo In-reply-to: Your message of "Mon, 28 Jun 1999 16:57:54 +0200." <199906281457.QAA00098@gunilla.TechFak.Uni-Bielefeld.DE> Date: Wed, 30 Jun 1999 12:18:16 +1000 Sender: owner-dns-security@lists.tislabs.com Precedence: bulk > Version -05 of the local compression draft should be announced soon (also at > http://www.TechFak.Uni-Bielefeld.DE/~pk/dns/draft-ietf-dnsind-local-compressi > on-05.txt) > > The relevant change compared to -04 is some text to address this problem: > > > > cased. Also there is no definition of exactly how to arrive > > > at the same bit patten given that you can have a LCP (local > > > compression pointer) -> LCP -> label. Also there are cases > > By mandating "optimal" compression and usage of the earliest occurence of > a possible target, pointer chains like above are now implicitly disallowed. > > > > where using a LCP will make the resulting wire form larger > > > than the uncompressed form, do we use LC or not? > > The only case I see is a terminating zero octet as a compression target. > Section 6 forbids this case. Anything else has at least a one character top > level domain resulting in three octets ('1', , '0'), which is less than > a pointer. Maybe I missed something? > > > I forgot to mention that some of these issues preclude the > > use of master files for the transport of zones between servers > > or even between signing software and servers from different > > vendors (I assuming here that the way LC is done by a vendor > > will be consistent between the server and the signer, this is > > not always a safe assumption). > > Although I believe this can be solved for local compression this item should > be considered in general. In the chain -> --(AXFR > )-> > -> , which reflects the data path BIND and probabl > y > others use, can one assume that both representations are > identical? Is the unambiguously derived from the ? > At least for TXT RRs differences may exist, should the input "string" exceed > 255 characters. > > -Peter > These is still the issue that we can't use EDNS to say that we can use global compression as the case may change as the result of using a global compression pointer. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-dns-security@lists.tislabs.com Wed Jun 30 10:23:04 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17335 for ; Wed, 30 Jun 1999 10:23:03 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA17788 Wed, 30 Jun 1999 09:18:32 -0400 (EDT) Message-Id: <199906301140.HAA13363@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dns-security@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnssec-externalkeys-01.txt Date: Wed, 30 Jun 1999 07:40:52 -0400 Sender: owner-dns-security@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Security Working Group of the IETF. Title : Inter-operability of Secure Domain Name System with Other Key Distribution Services Author(s) : M. Rao, J. Rao Filename : draft-ietf-dnssec-externalkeys-01.txt Pages : 8 Date : 29-Jun-99 There are several mechanisms for distributing public keys and certificates today. These distribution services publish certificates which contain cryptographic public keys. Clients that use any of these distribution services to retrieve certificates, require additional software for the retrieval, parsing and verification of these certificates. In this draft, we propose an alternate scheme that takes advantage of the Secure DNS infrastructure to distribute verified public keys obtained from other distribution services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnssec-externalkeys-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnssec-externalkeys-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnssec-externalkeys-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990629142217.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-externalkeys-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-externalkeys-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990629142217.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dns-security@lists.tislabs.com Wed Jun 30 16:07:10 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26675 for ; Wed, 30 Jun 1999 16:07:09 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA18928 Wed, 30 Jun 1999 13:46:58 -0400 (EDT) From: Robert Elz To: agenda@ietf.org, namedroppers@internic.net, dns-security@lists.tislabs.com Subject: Agenda for DNSIND WG meeting at 45th IETF, Oslo Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 Jul 1999 01:39:30 +1000 Message-Id: <27874.930757170@munnari.OZ.AU> Sender: owner-dns-security@lists.tislabs.com Precedence: bulk This is the agenda for the dnsind (and dnssec) meeting in Oslo, July 1999. 1. Administrativia, agenda bashing, etc (3 minutes) 2. Progress towards a new charter. (5 minutes) 3. Review of current PS RFCs and progress on advancing them. (5 minutes) rfc1982 rfc1995 rfc1996 rfc2136 rfc2137 rfc2181 rfc2308 rfc2535 rfc2536 rfc2537 rfc2538 rfc2539 4. Updating status on all known dns* drafts (15 minutes) The idea here is that we go through everything which seems to be on the dns* plate, and determine just what we're really working on, what the priority for eevrything is, when we expect to complete each doc, and what status we currently expect they will have. 5. Attempting to resolve rfc2052bis. (15 minutes) The IESG rejected rfc2052bis, and requested several changes. So far, we haven't been able to agree on exactly what to do. One option is to defer this indefinitely, or even drop it (simply leave 2052 as the experimental protocol as it is). Otherwise we need to find some way to satisfy the IESG demands if we ever expect tos ee this one become a RFC, or perhaps publich the updated version as experimental. 6. EDNS1 (5 minutes) This draft is currently an ongoing work item. Please be prepared to (briefly) suggest improvements, and/or where it should go next. Securing the DNS ... 7. TKey (5 minutes) Don Eastlake Now tsig is (apparently) done, it makes sense to get tkey out there following it asap, if it is ever going to. 8. Simple Secure Update (10 minutes) Edward Lewis This shows how to secure dns dynamic update using tsig. How close are we to being finished with this draft? 9. DNSSEC update (update2) (10 minutes) Don Eastlake (or later draft if it appears) The alternative (original) way of securing DNS updates. This is an intended replacement for rfc2137. 10. Security Key Rollover (5 minutes) Don Eastlake Dealing with key time rollover (since the time is imbedded in a fixed width field, it has to rollover sometime - this draft specifies how that works). New Resource Records... 11. SECure-RR (5 minutes) Edward Lewis This general topic has changed names several times (the dnsind appellation is new, hence the -00). 12. Kitchen Sink RR (5 minutes) Don Eastlake This has also changed names, it has been floating for ages. 13. Address Prefix List RR (5 minutes) Peter Koch Extended functionality... 14. Deferred Dynamic Delete (5 minutes) Edward Lewis 15. Verifying Resource Records (10 minutes) & Local Name Compression Peter Koch 16. Local Names (5 minutes) Don Eastlake 17. Other business, new work suggestions. Etc. (5 minutes) Reading list: Note that a few of the drafts listed below are not yet available in the I-D directories (these URLs will not yet work). They should be available by the time the backlog of last minute drafts has drained. For access via HTTP: http://www.ietf.org/internet-drafts/draft-ietf-dnsind-apl-rr-02.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsind-dddd-01.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsind-edns1-03.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsind-kitchen-sink-00.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsind-local-compression-05.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsind-local-names-07.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsind-rfc2052bis-02.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsind-rollover-00.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsind-sec-rr-00.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsind-simple-secure-update-01.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsind-verify-00.txt http://www.ietf.org/internet-drafts/draft-ietf-dnssec-tkey-01.txt http://www.ietf.org/internet-drafts/draft-ietf-dnssec-update2-00.txt (or) for access via FTP: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsind-apl-rr-02.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsind-dddd-01.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsind-edns1-03.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsind-kitchen-sink-00.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsind-local-compression-05.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsind-local-names-07.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsind-rfc2052bis-02.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsind-rollover-00.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsind-sec-rr-00.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsind-simple-secure-update-01.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsind-verify-00.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnssec-tkey-01.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnssec-update2-00.txt