From owner-dns-security Wed Oct 1 10:22:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA02818 for dns-security-outgoing; Wed, 1 Oct 1997 10:19:14 -0400 (EDT) Date: Wed, 1 Oct 1997 10:30:13 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: dns-security@tis.com Subject: Complexities with wildcards... (fwd) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk Since there have been no comments, I plan to merge the following material into the ..-dnssec-secext2-... It can still be changed, of course, if questions come up later. Donald ===================================================================== Donald E. Eastlake 3rd +1 978-287-4877(tel) dee@cybercash.com 318 Acton Street +1 978-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.privacy.org/ipc ---------- Forwarded message ---------- Date: Thu, 11 Sep 1997 15:42:18 -0400 (EDT) From: Donald E. Eastlake 3rd To: dns-security@tis.com Cc: "Donald E. Eastlake" Subject: Complexities with wildcards... In the process of implementation, some additional complexities have been noted in connection with answers that are based on wildcard RRs or the absence of wildcard RRs: Assume zone.example is a zone with a wild card *.zone.example MX 100 mailhandler.zone.example *.zone.example NXT 1.zone.example MX SIG NXT 1.zone.example MX 100 foo.zone.example 1.zone.example NXT 3.zone.example MX SIG NXT ... 1.zone.example ... 3.zone.example MX 100 bar.zone.exzmple 3.zone.example NXT ... plus the SIGs to authenticate the above. (1) In answer to a query for type MX, name 2.zone.example, you would get the expansion of the wildcard MX and the expansion of its SIG. A secure resolver can verifty all this which involves converting back to the wildcard form for SIG verification. But how does the resolver know that there isn't actaully a non-wildcard 2.zone.example MX which MXes to a different place? In fact, a bad guy could have captured a wildcard expansion response and use it to deny service to more specific names which should override the wildcard. The answer is that, with any wildcard expansion response, you need to also provide an NXT proving that the specific name did not exist. Thus in this case, the "1.zone.example NXT 3.zone.example ..." and its authentication SIG(NXT) would have to appear in the authority section of the response to justify returning the wildcard expansion answer. (2) In answer to a query for type A, name 2.zone.example, you would get a failure with the *.zone.example NXT RR in the authority section to prove that type A is not present but, as above, this does not show that the *.zone.example NXT is the right one as there might be a 2.zone.example NXT with a different type bit map. The answer, as above, is that you need to return two NXTs, with their authenticating SIGs, in the authority section. One to prove that 2.zone.example is a non-existent name so the *.zone.example is applicable and the *.zone.example NXT to show that that name has no type A. --- --- Now assume that zone.example no longer has the wild card: (3) When a non-existent name is returned for 2.zone.example with the "1.zone.example NXT 3.zone.example ..." NXT RR, how does the resolver know that an wildcard expansion should not have been returned instead? It appears that it is necessary to also return a second NXT proving that there isn't a wildcard which should have been used to answer the query, although the potential for denial of service by a bad guy saving the "1.zone... NXT 3.zone..." RR to deny access to an existing wildcard is a narrower threat that the bad guy saving a wildcard NXT and using it to deny access to a vast range of existing names. (4) Non-existent type at an exisitng non-wildcard name isn't a problem. You can just return the one NXT for the existing non-wildcard name. (5) To be complete: an existing type at an existing name isn't a problem as no wildcard would effect the response and, of course, no NXTs are needed (unless the query was for NXT). --- --- Things become even more complex if you think about multiple level zones. For example, if you were querying for x.2.zone.example and a.2.zone.example and z.2.zone.example existed, you would need to prove that x.2.zone.example and *.2.zone.example did not exist to justify a response based on *.zone.example. Possible algorithms are given below. If anyone can think of a way to maintain security and avoid these complexities, I'd love to hear about it. One good thing to note is that a security aware resolver must reduce a wild card expansion RR back to its wild card form for signature verification. Thus it could optionally cache the wildcard form and reduce queries to the authoritative servers BUT it can locally expand the wildcard ONLY in cases where it also has cached NXT RRs that prove a more specific name does not exist. Donald ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html WARNING, on 1 Oct 1997, +1-508 may change to +1-978. First stab at query algorithms: WILD CARD EXPANSION RESPONSE: 1. always include the NXT the proves the specific name queried does not exist. 2. replace the left most label of the name queried with *. 3. if the current name matches the wild card you expanded, you are done. 4. othewise check to see if the NXTs you are returning so far prove the current name does not exist. If they don't, add the NXT which does prove the current name does not exist. 5. remove the next to the left most label, leaving the current name a shorter wildcar, and go to 3. WILD CARD NON-EXISTENT TYPE: as for wild card expansion response above except you also return the wild card NXT to prove the type does not exist. NON-EXISTENT NAME RESPOPNSE 1. always include the NXT showing the specific name does not exist. 2. replace the left most label of the name queried with *. 3. check to see if the NXTs you are returning so far prove the current name does not exist. If they don't, add the NXT which does prove the current name does not exist. 4. remove the next to the left most label, leaving the current name one label shorter. If the current name (which will be a wildcard) matches the zone name, you are through, otherwise, go to step 3. On VALDIATING a response, you need to check that the NXTs that would be included above are present. From owner-dns-security Mon Oct 6 14:46:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA11342 for dns-security-outgoing; Mon, 6 Oct 1997 14:42:00 -0400 (EDT) Date: Mon, 6 Oct 1997 14:52:08 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: "Carl Malamud [IMS]" Cc: dns-security@tis.com Subject: Re: Secure DNS Implementation in BIND In-Reply-To: <199710061559.LAA25208@also.media.org> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk Agreement by RSA to permit royalty free use for DNS security is certainly good news... Donald On Mon, 6 Oct 1997, Carl Malamud [IMS] wrote: > Date: Mon, 6 Oct 1997 11:59:50 -0400 (EDT) > From: Carl Malamud [IMS] > > The Internet Software Consortium is pleased to announce that > we have reached an agreement with RSA Data Security, Inc., > a wholly owned subsidiary of Security Dynamics > Technologies, Inc. The agreement from RSA provides us > with a free license of DNSsafe, an implementation of the > RSA cryptosystem. This license limits DNSsafe for use only in > authenticating Domain Name System resource records. > > The donation allows the implementation of the DNS Security > standards in BIND, a publicly-available implementation of > the Domain Name System. RSA has also agreed to offer the same > license to other DNS developers for a three-year period, so that > non-BIND-based DNS products can also be secured. Virtually every > device on the Internet currently implements the existing (insecure) > DNS. We believe the DNSsafe security engine will be embedded in a > wide variety of products, including routers and firewalls, and we > hope that eventually Secure DNS will appear in every device on the > Internet. > > In addition, the DNS is a natural infrastructure for the publication > of public keys for use by other protocols, such as IPSec. Because > DNSSEC offers only authentication and not privacy, implementations > will be available to Internet users worldwide. > > The cooperative agreement was reached between RSA > President Jim Bidzos and ISC volunteer John Gilmore, a co- > founder of the Electronic Frontier Foundation and a trustee of > the Internet Society. The ISC would like to thank John and Jim for > reaching this valuable agreement. We'd also like to thank > DARPA and Trusted Information Systems, who funded and > built the first prototypes of DNSSEC. John Gilmore and Paul > Vixie are both donating their time for the implementation of > DNSSEC in BIND. > > The Internet Software Consortium is a volunteer effort > founded by BIND developer Paul Vixie to ensure publicly > available implementations of software that is crucial to the > operation of the Internet Infrastructure. Programs released in > 1996 include implementations of the Domain Name System > (BIND), Netnews (INN), the Dynamic Host Configuration > Protocol (DHCP), and portions of Kerberos Version 5.0. The > Internet Software Consortium is funded by contributions from > industry and individuals, including major support in 1997 > from Usenix and Network Solutions, Inc. Information about > the ISC is available at http://www.isc.org. > > We anticipate availability of BIND with DNSsafe by the end > of this year as beta software. We will provide a meeting in > conjunction with the December IETF to brief developers and > network operators on the implications of this software. We will > also be present at other forums, such as RIPE in Europe to answer > questions. Please check our web site for status reports on the > development efforts. > > RSA Data Security, Inc., a wholly owned subsidiary of > Security Dynamics Technologies, Inc., develops and markets > platform-independent developer's kits and end-user products > and provides comprehensive cryptographic consulting services. > Founded in 1982 by the inventors of the RSA Public Key Cryptosystem, > the company is headquartered in Redwood City, Calif. Details > of the RSA announcement are available at http://www.rsa.com/ > on the web. > > -30- ===================================================================== Donald E. Eastlake 3rd +1 978-287-4877(tel) dee@cybercash.com 318 Acton Street +1 978-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.privacy.org/ipc From owner-dns-security Mon Oct 6 15:21:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA11580 for dns-security-outgoing; Mon, 6 Oct 1997 15:20:59 -0400 (EDT) Message-Id: <34393C57.4A49D688@Clorox.com> Date: Mon, 06 Oct 1997 12:30:32 -0700 From: "Paul Rarey" Organization: The Clorox Company X-Mailer: Mozilla 4.03 [en] (WinNT; U) Mime-Version: 1.0 To: "Donald E. Eastlake 3rd" Cc: "Carl Malamud [IMS]" , dns-security@tis.com Subject: Re: Secure DNS Implementation in BIND References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-dns-security@ex.tis.com Precedence: bulk What happens at the end of three years? Donald E. Eastlake 3rd wrote: > Agreement by RSA to permit royalty free use for DNS security is certainly > good news... > > The donation allows the implementation of the DNS Security > standards in BIND, a publicly-available implementation of > the Domain Name System. RSA has also agreed to offer the same > license to other DNS developers for a three-year period, so that ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [ psr ] From owner-dns-security Mon Oct 6 16:10:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA12035 for dns-security-outgoing; Mon, 6 Oct 1997 16:10:04 -0400 (EDT) Date: Mon, 6 Oct 1997 16:21:18 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: Paul Rarey Cc: "Carl Malamud [IMS]" , dns-security@tis.com Subject: Re: Secure DNS Implementation in BIND In-Reply-To: <34393C57.4A49D688@Clorox.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk After three years the RSA patent expires, I believe, so no license will be needed. Donald On Mon, 6 Oct 1997, Paul Rarey wrote: > Date: Mon, 06 Oct 1997 12:30:32 -0700 > From: Paul Rarey > To: "Donald E. Eastlake 3rd" > Cc: "Carl Malamud [IMS]" , dns-security@tis.com > Subject: Re: Secure DNS Implementation in BIND > > What happens at the end of three years? > > Donald E. Eastlake 3rd wrote: > > > Agreement by RSA to permit royalty free use for DNS security is certainly > > good news... > > > > > The donation allows the implementation of the DNS Security > > standards in BIND, a publicly-available implementation of > > the Domain Name System. RSA has also agreed to offer the same > > license to other DNS developers for a three-year period, so that > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > [ psr ] > > ===================================================================== Donald E. Eastlake 3rd +1 978-287-4877(tel) dee@cybercash.com 318 Acton Street +1 978-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.privacy.org/ipc From owner-dns-security Wed Oct 8 22:21:07 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA01374 for dns-security-outgoing; Wed, 8 Oct 1997 22:17:37 -0400 (EDT) Message-Id: <199710090225.TAA19658@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: "Paul Rarey" , gnu@toad.com cc: "Donald E. Eastlake 3rd" , "Carl Malamud [IMS]" , dns-security@tis.com Subject: Re: Secure DNS Implementation in BIND In-reply-to: <34393C57.4A49D688@Clorox.com> Date: Wed, 08 Oct 1997 19:25:52 -0700 From: John Gilmore Sender: owner-dns-security@ex.tis.com Precedence: bulk > What happens at the end of three years? The RSA patent expires, and you don't need to negotiate with RSA to build a DNS implementation that uses RSA. Until then, RSA has committed to offer perpetual DNSsafe licenses to anyone who wants to implement DNS Security. If you base your DNSSEC work on BIND, you are covered by ISC's license; if you have an independent implementation, you can get your own license from RSA. John From owner-dns-security Wed Oct 8 22:53:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA01605 for dns-security-outgoing; Wed, 8 Oct 1997 22:53:06 -0400 (EDT) From: Masataka Ohta Message-Id: <199710090249.LAA12317@necom830.hpcl.titech.ac.jp> Subject: Re: Secure DNS Implementation in BIND To: gnu@toad.com (John Gilmore) Date: Thu, 9 Oct 97 11:49:27 JST Cc: Paul.Rarey@Clorox.com, gnu@toad.com, dee@cybercash.com, carl@also.media.org, dns-security@tis.com In-Reply-To: <199710090225.TAA19658@toad.com>; from "John Gilmore" at Oct 8, 97 7:25 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-dns-security@ex.tis.com Precedence: bulk > > What happens at the end of three years? > > The RSA patent expires, In which contries? All? Masataka Ohta From owner-dns-security Wed Oct 8 23:05:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA01697 for dns-security-outgoing; Wed, 8 Oct 1997 23:05:36 -0400 (EDT) Message-Id: Date: Wed, 8 Oct 97 20:15 PDT From: Randy Bush To: John Gilmore Cc: dns-security@tis.com Subject: Re: Secure DNS Implementation in BIND References: <34393C57.4A49D688@Clorox.com> <199710090225.TAA19658@toad.com> Sender: owner-dns-security@ex.tis.com Precedence: bulk >> What happens at the end of three years? > The RSA patent expires, and you don't need to negotiate with RSA to build > a DNS implementation that uses RSA. Until then, RSA has committed to > offer perpetual DNSsafe licenses to anyone who wants to implement DNS > Security. John, please excuse my not doing sufficient homework and burdening you with clue transfer. Is DNSsafe licensed IPR or is it a software product? If the former, then is it safe to follow the above implied logic that we're home free as we'll have a license until the restriucted rights on DNSsafe IPR? If the latter, is there any concern that, once the three year license is up, there could be i$$ues for continuing use of the software product. Or does the 'perpetual' mean that work based on DNSsafe which is started before the three years is up may continue without further fear of i$$ues. Thanks. randy From owner-dns-security Wed Oct 8 23:09:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA01716 for dns-security-outgoing; Wed, 8 Oct 1997 23:09:06 -0400 (EDT) Date: Wed, 8 Oct 1997 23:18:02 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: Masataka Ohta Cc: carl@also.media.org, Paul.Rarey@Clorox.com, dns-security@tis.com Subject: Re: Secure DNS Implementation in BIND In-Reply-To: <199710090249.LAA12317@necom830.hpcl.titech.ac.jp> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk It's only patented in the USA, I believe. Donald On Thu, 9 Oct 1997, Masataka Ohta wrote: > Date: Thu, 9 Oct 97 11:49:27 JST > From: Masataka Ohta > To: John Gilmore > Cc: Paul.Rarey@Clorox.com, gnu@toad.com, dee@cybercash.com, > carl@also.media.org, dns-security@tis.com > Subject: Re: Secure DNS Implementation in BIND > > > > What happens at the end of three years? > > > > The RSA patent expires, > > In which contries? All? > > Masataka Ohta > ===================================================================== Donald E. Eastlake 3rd +1 978-287-4877(tel) dee@cybercash.com 318 Acton Street +1 978-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.privacy.org/ipc From owner-dns-security Wed Oct 8 23:21:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA01823 for dns-security-outgoing; Wed, 8 Oct 1997 23:21:08 -0400 (EDT) From: Masataka Ohta Message-Id: <199710090324.MAA12477@necom830.hpcl.titech.ac.jp> Subject: Re: Secure DNS Implementation in BIND To: dee@cybercash.com (Donald E. Eastlake 3rd) Date: Thu, 9 Oct 97 12:24:13 JST Cc: mohta@necom830.hpcl.titech.ac.jp, carl@also.media.org, Paul.Rarey@Clorox.com, dns-security@tis.com In-Reply-To: ; from "Donald E. Eastlake 3rd" at Oct 8, 97 11:18 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-dns-security@ex.tis.com Precedence: bulk Donald; > It's only patented in the USA, I believe. Donald Thank you for presenting your blief. But, I need an answer authenticated by RSA. :-) Masataka Ohta From owner-dns-security Thu Oct 9 09:12:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA05060 for dns-security-outgoing; Thu, 9 Oct 1997 09:11:06 -0400 (EDT) Message-ID: <343CD71F.6146@sprynet.com> Date: Thu, 09 Oct 1997 06:07:43 -0700 From: Kelly McGrew Reply-To: kmcgrew@sprynet.com X-Mailer: Mozilla 3.01Gold (WinNT; I) MIME-Version: 1.0 To: dee@cybercash.com CC: dns-security@tis.com Subject: Detached DNS Information Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-dns-security@ex.tis.com Precedence: bulk I noticed this draft expired last month. There are some good points made therein. Is the author or anyone else was going to reissue it? Has it been incorporated into another draft? From owner-dns-security Thu Oct 9 09:19:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA05140 for dns-security-outgoing; Thu, 9 Oct 1997 09:19:36 -0400 (EDT) Date: Thu, 9 Oct 1997 09:30:29 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: Kelly McGrew Cc: dns-security@tis.com Subject: Re: Detached DNS Information In-Reply-To: <343CD71F.6146@sprynet.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk That's interesting. I didn't get a notice. I'll do an update pass and re-submit it. Thanks, Donald On Thu, 9 Oct 1997, Kelly McGrew wrote: > Date: Thu, 09 Oct 1997 06:07:43 -0700 > From: Kelly McGrew > To: dee@cybercash.com > Cc: dns-security@tis.com > Subject: Detached DNS Information > > I noticed this draft expired last month. There are some good points > made therein. Is the author or anyone else was going to reissue it? Has > it been incorporated into another draft? > > ===================================================================== Donald E. Eastlake 3rd +1 978-287-4877(tel) dee@cybercash.com 318 Acton Street +1 978-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.privacy.org/ipc From owner-dns-security Fri Oct 10 10:14:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA13126 for dns-security-outgoing; Fri, 10 Oct 1997 10:11:28 -0400 (EDT) X-Sender: lewis@pop.hq.tis.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 10 Oct 1997 10:02:12 -0400 To: dee@cybercash.com, ogud@tis.com, gnu@toad.com, charlie_kaufman@iris.com From: Edward Lewis Subject: Wildcards, NXTs, and other gremlins Cc: dns-security@tis.com Sender: owner-dns-security@ex.tis.com Precedence: bulk Thinking ahead...which is dangerous given the current state of the software... Let's say I have this: *.a txt "hello world" *.a sig txt *.a nxt d.a *.a sig nxt d.a something d.a sig something d.a nxt g.a d.a sig nxt g.a something g.a sig something b cname f.a b sig cname I query for "b/txt". Now we are including the nxt proving that there is no f.a, hence, the wildcard value of *.a is returned. Will the response packet look like the following? ANSWER: b. cname f.a b. sig cname f.a txt "Hello world" -- match w/ *.a f.a sig txt -- match w/ *.a AUTHORITY: d.a nxt g.a d.a sig nxt Will there be an NS record in there too? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: +1 301-854-5794 Email: lewis@tis.com "What's it say about me that you'd think I'd fall for that" James McMurtry - "Where'd You Hide the Body" (1995) Opinions expressed are property of my evil twin, not my employer. From owner-dns-security Fri Oct 10 14:17:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA14633 for dns-security-outgoing; Fri, 10 Oct 1997 14:16:26 -0400 (EDT) Date: Fri, 10 Oct 1997 14:27:43 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: Edward Lewis Cc: ogud@tis.com, gnu@toad.com, charlie_kaufman@iris.com, dns-security@tis.com Subject: Re: Wildcards, NXTs, and other gremlins In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk I think the responser you provide is correct and I do not think there would be an NS in the response. Donald On Fri, 10 Oct 1997, Edward Lewis wrote: > Date: Fri, 10 Oct 1997 10:02:12 -0400 > From: Edward Lewis > > Thinking ahead...which is dangerous given the current state of the software... > > Let's say I have this: > > > *.a txt "hello world" > *.a sig txt > *.a nxt d.a > *.a sig nxt > > d.a something > d.a sig something > d.a nxt g.a > d.a sig nxt > > g.a something > g.a sig something > > b cname f.a > b sig cname > > I query for "b/txt". Now we are including the nxt proving that there is no > f.a, hence, the wildcard value of *.a is returned. > > Will the response packet look like the following? > > ANSWER: > b. cname f.a > b. sig cname > f.a txt "Hello world" -- match w/ *.a > f.a sig txt -- match w/ *.a > AUTHORITY: > d.a nxt g.a > d.a sig nxt > > Will there be an NS record in there too? > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis Trusted Information Systems > Phone: +1 301-854-5794 Email: lewis@tis.com > > "What's it say about me that you'd think I'd fall for that" > James McMurtry - "Where'd You Hide the Body" (1995) > > Opinions expressed are property of my evil twin, not my employer. > > > ===================================================================== Donald E. Eastlake 3rd +1 978-287-4877(tel) dee@cybercash.com 318 Acton Street +1 978-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.privacy.org/ipc From owner-dns-security Tue Oct 14 16:07:28 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA12979 for dns-security-outgoing; Tue, 14 Oct 1997 16:01:02 -0400 (EDT) Date: 14 Oct 1997 04:35:16 -0000 Message-ID: <19971014043516.20831.qmail@cr.yp.to> From: "D. J. Bernstein" To: dns-security@tis.com Subject: 88-microsecond 1024-bit verification on a Pentium-100 Sender: owner-dns-security@ex.tis.com Precedence: bulk I have a digital signature system with verification 10 times faster than RSA-3. A sample implementation for Intel processors is available through http://pobox.com/~djb/sigs.html. ---Dan From owner-dns-security Wed Oct 22 16:54:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA12024 for dns-security-outgoing; Wed, 22 Oct 1997 16:49:22 -0400 (EDT) X-Sender: lewis@pop.hq.tis.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 22 Oct 1997 17:00:12 -0400 To: dee@cybercash.com, ogud@tis.com, gnu@toad.com, charlie_kaufman@iris.com, dns-security@tis.com From: Edward Lewis Subject: Who can sign matrix Sender: owner-dns-security@ex.tis.com Precedence: bulk Here is a ("proposed") matrix of what can sign what in DNSSEC-approved validation. Olafur & I want to limit the trust model of DNSSEC to this. Realize that we also understand that there are needs for other trust models - such as those including the notion of third-party signing authorities - that we intend to support through the means of multiple signatures. This matrix's columns are keys, the rows data sets. | Signing-only[1] Keys | Zone[2] Keys Data Set | Owner={same[5],wildcard[6]} | Same[7] Parent[8] Child[9] KEY-p [0] | N | Y N N \ KEY-s [1] | N | Y N N /same KEY-z [2] | N | N Y Y NXT-u [3] | N | N Y N NXT-l [4] | N | Y N N \ NS / SOA | N | Y N N /same All others| Y | Y N N Notes [0] KEY-p These are keys that have no DNSSEC signing ability. This is either designated in the flags (e.g., a NULL key) or a failure in the validation of the key's set. [1] KEY-s or Signing-only key These are keys that are DNSSEC-approved for signing but do not have the zone bit set. These are most commonly dynamic update keys. These keys attain this status only if validated. A set with at least one signing key and has no zone keys is treated as a KEY-p. [2] KEY-z or Zone key A key with the zone bit set to 1 (bits 6,7 have the value 0b01) and the set is properly validated. A set with at least one zone key is treated as a KEY-z. [3] NXT-u An NXT with the NS bit set to 1 and the SOA bit set to 0. This is only found at delegation points, and is the "upper" NXT associated with the domain name. [4] NXT-l An NXT which has the NS bit 0 or the SOA bit 1. This is all NXT's that are not NXT-u's. [5] Same Owner The owner of the key set is the same as the owner of the data set. [6] Wildcard Owner The owner of the key set matches the owner of the data set and is in the same zone. [7] Same Zone The name of the owner of the data set belongs to the same zone as the zone key doing the signing. For all record sets at a delegation point, the "same" zone is the zone to which the (owning) name's SOA belongs. [8] Parent Zone The parent zone of a name is the zone who signs the NXT-u associated with the "same" zone's [7] name. [9] Child Zone The child zone's name has an NXT-u signed by one of the "same" zone [7]'s zone keys. Hope these notes make sense - it's hard being precise in English...it's much easier in C. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: +1 301-854-5794 Email: lewis@tis.com "Serenity now, insanity later" -- Lloyd Braun Opinions expressed are property of my evil twin, not my employer. From owner-dns-security Fri Oct 24 09:22:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA24832 for dns-security-outgoing; Fri, 24 Oct 1997 09:18:50 -0400 (EDT) X-Sender: lewis@pop.hq.tis.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 24 Oct 1997 09:16:02 -0400 To: dee@cybercash.com, ogud@tis.com, gnu@toad.com, charlie_kaufman@iris.com, dns-security@tis.com From: Edward Lewis Subject: Re: Who can sign matrix Sender: owner-dns-security@ex.tis.com Precedence: bulk At 5:00 PM -0400 10/22/97, Edward Lewis wrote: >Here is a ("proposed") matrix of what can sign what in DNSSEC-approved ... > | Signing-only[1] Keys | Zone[2] Keys >Data Set | Owner={same[5],wildcard[6]} | Same[7] Parent[8] Child[9] >KEY-z [2] | N | N Y Y ... The righttmost case here is proving to be problematic, at least in my implementation. The problem (philosophicly) is that I start at a root of a trusted tree and learn downwards. I use verified keys to learn, and the learning must be incrementally downward - or else an infinite loop occurs. I can't learn laterally or upward. Allowing children to sign for parents means that I can establish that a child is a child of the parent whom I'm learning about. However, I can't establish whether a name is a child or not until I know (for certain) about the parent. I know that there is ultimately a solution to this as I can work out the problem on paper, but codifying this requires me to redesign the internal data structures... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: +1 301-854-5794 Email: lewis@tis.com "Serenity now, insanity later" -- Lloyd Braun Opinions expressed are property of my evil twin, not my employer. From owner-dns-security Fri Oct 31 07:41:28 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA15836 for dns-security-outgoing; Fri, 31 Oct 1997 07:36:47 -0500 (EST) Date: 31 Oct 1997 03:14:30 -0000 Message-ID: <19971031031430.22396.qmail@cr.yp.to> From: "D. J. Bernstein" To: dns-security@tis.com Subject: Re: 88-microsecond 1024-bit verification on a Pentium-100 Sender: owner-dns-security@ex.tis.com Precedence: bulk Several people have asked how the system works. A draft of my paper on the topic is available from http://pobox.com/~djb/papers/sigs.ps. ---Dan