From owner-dns-security Wed Nov 6 13:52:27 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA04729 for dns-security-outgoing; Wed, 6 Nov 1996 13:46:29 -0500 (EST) Date: Wed, 6 Nov 1996 13:48:13 -0500 (EST) From: John Kelley Message-Id: <199611061848.NAA16006@clipper.hq.tis.com> To: dns-security@tis.com Subject: ANNOUNCEMENT -- New majordomo server Sender: owner-dns-security@ex.tis.com Precedence: list ANNOUNCEMENT All majordomo lists, including this one, that have been maintained on neptune.hq.tis.com, have been moved to portal.ex.tis.com. This has allowed us to upgrade our software and hardware to hopefully provide much better mailing list service. There may be a few rough spots during the transition and until all the pieces are fitted together. One major temporary problem is that the access to the current list archives is not available at this time. Another announcement will not be made when they are available, but the info file for each particular list will mention that they are back. Please send any problems you may see about the new server to majordomo-owner@ex.tis.com. Commands to the majordomo@neptune address will be forwarded to the new server for the forseeable future. For the most efficient response to commands or postings, it is recommended using the majordomo@ex.tis.com or @ex.tis.com addresses. Thank you for your patience in this matter. -TIS Majordomo Administrators From owner-dns-security Fri Nov 15 07:43:18 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA25692 for dns-security-outgoing; Fri, 15 Nov 1996 07:39:11 -0500 (EST) Message-Id: <199611151239.HAA25692@portal.ex.tis.com> To: dns-security@tis.com Subject: name compression Date: Thu, 14 Nov 1996 22:26:15 -0800 From: Paul A Vixie Sender: owner-dns-security@ex.tis.com Precedence: list in DNSSEC (5-August-96 version) we see: The "signer's name" field is the domain name of the signer generating the SIG RR. This is the owner of the public KEY RR that can be used to verify the signature. It is frequently the zone which contained the RR(s) being authenticated. The signer's name may be compressed with standard DNS name compression when being transmitted over the network. in RFC 1035 we see: The following RR definitions are expected to occur, at least potentially, in all classes. In particular, NS, SOA, CNAME, and PTR will be used in all classes, and have the same format in all classes. Because their RDATA format is known, all domain names in the RDATA section of these RRs may be compressed. ... Pointers can only be used for occurances of a domain name where the format is not class specific. If this were not the case, a name server or resolver would be required to know the format of all RRs it handled. As yet, there are no such cases, but they may occur in future RDATA formats. now, as it turns out, BIND does this wrong and i should not open the worm can. but i think it is fair to say that DNSSEC should not specify compression here. --BAA05077.848038975/relay.hq.tis.com-- From owner-dns-security Fri Nov 15 12:55:35 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA27294 for dns-security-outgoing; Fri, 15 Nov 1996 12:50:29 -0500 (EST) Date: Fri, 15 Nov 1996 12:19:40 -0500 (EST) From: "Donald E. Eastlake 3rd" To: Paul A Vixie Cc: dns-security@tis.com Subject: Re: name compression In-Reply-To: <199611151239.HAA25692@portal.ex.tis.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: list On Thu, 14 Nov 1996, Paul A Vixie wrote: > Date: Thu, 14 Nov 1996 22:26:15 -0800 > From: Paul A Vixie > To: dns-security@tis.com > Subject: name compression > > in DNSSEC (5-August-96 version) we see: > > The "signer's name" field is the domain name of the signer generating > the SIG RR. This is the owner of the public KEY RR that can be used > to verify the signature. It is frequently the zone which contained > the RR(s) being authenticated. The signer's name may be compressed > with standard DNS name compression when being transmitted over the > network. While it is true that this makes it non-cachable by security non-aware DNS implementaitons, don't BIND not cache RRs it doesn't know about anyway? > in RFC 1035 we see: > > The following RR definitions are expected to occur, at least > potentially, in all classes. In particular, NS, SOA, CNAME, and PTR > will be used in all classes, and have the same format in all classes. > Because their RDATA format is known, all domain names in the RDATA > section of these RRs may be compressed. > ... > Pointers can only be used for occurances of a domain name where the > format is not class specific. If this were not the case, a name server > or resolver would be required to know the format of all RRs it handled. > As yet, there are no such cases, but they may occur in future RDATA > formats. The SIG RR isn't class specific. Neither is KEY or NXT. They work fine for securing RRs of any class. So RFC 1035 would imply they can be compressed. On the other hand, I think RFC 1035 is way too conservative here. At the time, I believe, it was thought that there might be many classes, perhaps even some whose RR formats were not under IETF change control. That might have made keeping track of the formats of class specific RRs a nightmare. However, given that the IN class has turned out to be so totally dominant, it makes perfect sense to name compress any RR understood by all the DNS implementations out there, even if it is an IN class only RR. > now, as it turns out, BIND does this wrong and i should not open the worm can. > but i think it is fair to say that DNSSEC should not specify compression here. As per the above, I still think it should. > --BAA05077.848038975/relay.hq.tis.com-- 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 From owner-dns-security Tue Nov 19 15:55:35 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA02030 for dns-security-outgoing; Tue, 19 Nov 1996 15:51:13 -0500 (EST) Date: Tue, 19 Nov 1996 15:50:23 -0500 (EST) From: "Donald E. Eastlake 3rd" To: Randy Bush Cc: namedroppers , dns-security@tis.com Subject: Re: dnsind dnssec joint meeting in San Jose 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 What about the TSIG draft? Donald On Wed, 16 Oct 1996, Randy Bush wrote: > Date: Wed, 16 Oct 96 15:18 PDT > From: Randy Bush > To: namedroppers > Cc: "James M. Galvin" > Subject: dnsind dnssec joint meeting in San Jose > > At the ADs' recommendation, we have scheduled a joint session with dnssec > for San Jose as follows: > > > Date: Fri, 11 Oct 1996 10:40:06 -0400 > To: Randy Bush > From: Marcia Beaulieu > Subject: SAN JOSE IETF: DNSIND/DNSSEC > Cc: "James M. Galvin" , kasten+iesg@ftp.com, > jburgan@baynetworks.com, jis@mit.edu > > This is to confirm one joint session for DNSIND/DNSSEC as follows: > > Friday, December 13 at 0900 > > If you plan to use the DNSSEC session on Wednesday at 0900 to hold this > meeting, please let me know. This meeting would be opposite rmonmib, rtfm, > tagsw-bof). > > Please remember to send us the agenda for the meeting so we can post it. > > Marcia > > > The sole agenda item of which I am aware is DynUpd and Donald's parallel > document. Please submit other agenda items to me. > > As I suspect that dnssec's Wednesday meeting has the same agenda, I am > hoping we can merge and save a session. James? > > Thanks. > > randy > ===================================================================== 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 From owner-dns-security Wed Nov 20 01:23:15 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA02429 for dns-security-outgoing; Wed, 20 Nov 1996 01:21:25 -0500 (EST) Message-Id: Date: Tue, 19 Nov 96 22:22 PST From: randy@psg.com (Randy Bush) To: "Donald E. Eastlake 3rd" Cc: namedroppers , dns-security@tis.com Subject: Re: dnsind dnssec joint meeting in San Jose References: Sender: owner-dns-security@ex.tis.com Precedence: bulk > What about the TSIG draft? I intend to delay it until after we get o the chartered work of dnsind done o any incidentals which do not impinge on the chartered work done TSIG impinges on the chartered work and does not clearly help complete it. If I had been asked whether it should be published as a dnsind ID, as is supposed to be part of the process, I would have hesitated. Do you see discussion of it as needed to get dynamic update and secure dynamic update out of draft? randy From owner-dns-security Wed Nov 20 17:11:31 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA05272 for dns-security-outgoing; Wed, 20 Nov 1996 17:04:22 -0500 (EST) Date: Wed, 20 Nov 1996 14:06:28 -0800 (PST) X-btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: dns-security@tis.com From: paul@vix.com (Paul A Vixie) Subject: Re: dnsind dnssec joint meeting in San Jose Organization: Vixie Enterprises Message-ID: References: NNTP-Posting-Host: wisdom.home.vix.com In-reply-to: randy@psg.com's message of 19 Nov 1996 23:08:05 -0800 Xref: vixie local.mail.dns.security:418 Sender: owner-dns-security@ex.tis.com Precedence: bulk > Do you see discussion of it as needed to get dynamic update and secure > dynamic update out of draft? The way things have turned out, no. -- Paul Vixie La Honda, CA "Illegitimibus non carborundum." pacbell!vixie!paul From owner-dns-security Mon Nov 25 07:20:51 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA10561 for dns-security-outgoing; Mon, 25 Nov 1996 07:17:20 -0500 (EST) Date: Mon, 25 Nov 1996 07:17:20 -0500 (EST) From: owner-dns-security@ex.tis.com Message-Id: <199611251217.HAA10561@portal.ex.tis.com> To: namedroppers@internic.net Cc: dns-security@tis.com Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and draft-ietf-dnsind-clarify-02.txt) From: Havard.Eidnes@runit.sintef.no In-Reply-To: Your message of "Mon, 18 Nov 1996 15:41:07 -0500 (EST)" References: X-Mailer: Mew version 1.51 on Emacs 19.34.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Date: Sun, 24 Nov 1996 20:16:12 +0100 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id OAA10072 Sender: owner-dns-security@portal.ex.tis.com Precedence: bulk > Unfortunately, DNS Security makes all this a bit more complex. > > For example, you need to be able to have all of the security > RRs types (SIG, NXT, & KEY) present with a CNAME. And the > superzone's version of the KEY RR at a cut point is better than > the subzone's. Hm, let me see if I have understood this correctly. DNSSEC seems to specify that at a zone cut the parent zone contains an RR (e.g. KEY RR) with identical label, class and type as what can potentially be found in the child zone, but the two records have different data fields, different semantics, and that the RR from the parent is supposed to be considered "more credible" (or what else means "better") than the data from the child zone? I hope that I am not the only one feels uncomfortable with this. The way I understand it this would in effect create an RRset split over two different zones, which is in direct conflict with the clarify-02 draft (at least with my interpretation of it). Under DNSSEC, what other records have this property that they can be present both in the parent and the child zones (at a zone cut) and have different semantics attached to them dependent on where the data originates? SIG and NXT in addition to KEY? Are these the only ones? Can this be avoided? Cleanly? I thought a bit about the KEY RRs in conjunction with zone cuts, and the architectural purists among you can skip the rest of this paragraph... What about having the parent KEY RR stored with a different label in the parent zone (e.g. by adding "/pkey" or something like that to the label)? That way the name server for the parent zone can claim authority in the traditional manner for the KEY record, and you avoid having an RRset being "split" over two zones. (Ok, I have probably not understood the impact this might have on the NXT records.) I think that the broader issue here is "how strong a departure from existing practices should DNSSEC be allowed to impose", with the practical consequences from the decision being "how difficult will it be to gradually deploy DNSSEC into the DNS" (?). - Hevard From owner-dns-security Mon Nov 25 08:08:57 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA10632 for dns-security-outgoing; Mon, 25 Nov 1996 08:08:49 -0500 (EST) Date: Mon, 25 Nov 1996 08:08:49 -0500 (EST) From: Masataka Ohta Message-Id: <199611251156.UAA04363@necom830.hpcl.titech.ac.jp> Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and draft-ietf-dnsind-clarify-02.txt) To: Havard.Eidnes@runit.sintef.no Date: Mon, 25 Nov 96 20:56:24 JST Cc: namedroppers@internic.net, dns-security@tis.com In-Reply-To: <199611241916.UAA28839@vader.runit.sintef.no>; from "Havard.Eidnes@RUNIT.SINTEF.NO" at Nov 24, 96 8:16 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-dns-security@portal.ex.tis.com Precedence: bulk Havard; > > Unfortunately, DNS Security makes all this a bit more complex. > > > > For example, you need to be able to have all of the security > > RRs types (SIG, NXT, & KEY) present with a CNAME. And the > > superzone's version of the KEY RR at a cut point is better than > > the subzone's. > > Hm, let me see if I have understood this correctly. I'm afraid your attempt to persuade Donald will fail. Even if it had succeeded, there remains a problem that the glue information makes the packet size exceed 512 bytes. This is a problem of WG management. Long time ago, in some (Seatle?) DNSSEC meeting, there was a discussion and the WG agreements that: Cryptographically, glue informaiton in the parent zone gives no protection. For DNS compatibility, there should be no additional glue. Before and after the meeting, I repeatedly says Donald that he should remove it. But, he didn't. The chairman of the WG, James Galvin, also knows, but does not understand either, the issue. I finally gave up and abandoned the WG. The problems are: Donald does not know DNS well to understand subtle architecural principles of it. Donald is a bad editor not to reflect the WG consensus to the WG draft. James Galvin is a bad chair not to be able to remove Donald. They are not technical problems and I know technical discussion is meaningless until after the chair and the editor are replaced. Donald and James, do you want to voluntarily step down or, at least, let DNSIND modify the draft? Masataka Ohta From owner-dns-security Mon Nov 25 08:36:15 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA10701 for dns-security-outgoing; Mon, 25 Nov 1996 08:35:53 -0500 (EST) Date: Mon, 25 Nov 1996 08:39:06 -0500 (EST) From: Edward Lewis X-Sender: lewis@singsing.hq.tis.com To: owner-dns-security@tis.com cc: namedroppers@internic.net, dns-security@tis.com, Olafur Gudmundsson Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and In-Reply-To: <199611251217.HAA10561@portal.ex.tis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk On Mon, 25 Nov 1996 owner-dns-security@tis.com wrote: Pardon my ignorance, but I'm thrown be the headers. I hope this reply gets back to (at least) the real sender... > From: Havard.Eidnes@runit.sintef.no > Sender: owner-dns-security@portal.ex.tis.com > > Hm, let me see if I have understood this correctly. DNSSEC seems to > specify that at a zone cut the parent zone contains an RR (e.g. KEY > RR) with identical label, class and type as what can potentially be > found in the child zone, but the two records have different data > fields, different semantics, and that the RR from the parent is > supposed to be considered "more credible" (or what else means > "better") than the data from the child zone? In a nutshell, the "child" data is *always* more credible than the "parent" data. At a zone cut, the parent zone is authoritative for 1) the existence of the zone cut name, 2) for the existence of the zone cut, and 3) whether the child zone is secured or not secured by a zone key. The result of the parent's being authoritive for the existence of the name is that the parent has an NXT including the name. (For the sake of clarity, assume that we are not considering dynamic update.) A zone cut is signified by an NS RR set. What's in the NS RR set is not important here, but that an NS RR set is present. This gets complicated. The child zone is authoritative for the contents of the NS record. The NS record has two authoritative parts - it's existence and it's contents. As long as the parent has one NS record for the child, the child may hold as many as they wish - but this would constitute a configuration error. Any queryier should trust the child's data. (If the parent held NS record has a wrong nameserver, then there is a lame delegation and this problem needs fixing.) A secured child is signified by the parent's signing of a child's zone key. The zone key arrives "out of band" of the normal DNS data flow. (I.e., not via a recursive lookup or zone transfer.) The out of band transfer is needed because the key arrives unsigned. The parent signs the key and sends the signature back, also out of band - since there is no other mechanism for this "in band." > The way I understand it this would in effect create an RRset split > over two different zones, which is in direct conflict with the With one exception, this is not a problem. The exception involves the NXT RR set. As the name of the zone cut appears in two zones, there are two different NXT's, each pointing to a different next name (one each in the zone above and in the zone below the cut). In all other cases, the child's data is more credible. Care must be taken though, during zone transfers, not to eliminate the parent's signature of the zone key(s). That is not a credibility issue, however. > Under DNSSEC, what other records have this property that they can be > present both in the parent and the child zones (at a zone cut) and > have different semantics attached to them dependent on where the > data originates? SIG and NXT in addition to KEY? Are these the > only ones? Only the NXT data is different, but the semantics are the same. This is because the zones below and above the cut are different and have different "next" names. If there are any other conflicts, then there is a configuration error, or a old RR's haven't been refreshed yet (TTL hasn't expired yet). KEY and SIG RR's do not have different contents nor semantics on different sides of the zone cut. > Can this be avoided? Cleanly? I don't think anything is in need of being avoided cleanly. Given more consideration, dynamic update does not pose much of a problem, but I don't want to get into that here, as details are still being reviewed. > paragraph... What about having the parent KEY RR stored with a > different label in the parent zone (e.g. by adding "/pkey" or > something like that to the label)? That way the name server for the > parent zone can claim authority in the traditional manner for the > KEY record, and you avoid having an RRset being "split" over two > zones. (Ok, I have probably not understood the impact this might > have on the NXT records.) The parent zone has no authority over the zone key for a subzone. By signing it, the parent is recognizing that the child is a secured zone, and that's all the parent needs to know. The parent will have to give the child the SIG record for inclusion in the child's zone transfers. (The parent may keep the data around - the zone key and the signature, but this is for performance reasons. The name server implementing the parent zone may be asked for the key and signature and it can assume the data is kept is accurate. At some time, however, it might get the real data from the child - and it should be the same. This transfer might be a zone transfer because many times a parent zone's nameserver acts as a name server [primary or secondary] for the child too.) > I think that the broader issue here is "how strong a departure from > existing practices should DNSSEC be allowed to impose", with the > practical consequences from the decision being "how difficult will > it be to gradually deploy DNSSEC into the DNS" (?). > > - Hevard I think the only issue will be the out of band mechanisms for running delegated (child) zones. I don't forsee a significant impact of DNSSEC on the current mode of operations of DNS. Of course, there DNSSEC will result in more data being passed, and more activity to verify signatures, but DNS will still "look" like it used too. (I'm simplifying my argument here since the statement above is very general.) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: 301-854-5794 Email: lewis@tis.com From owner-dns-security Mon Nov 25 09:21:06 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA10899 for dns-security-outgoing; Mon, 25 Nov 1996 09:20:54 -0500 (EST) Date: Mon, 25 Nov 1996 09:20:11 -0500 (EST) From: "Donald E. Eastlake 3rd" To: Havard.Eidnes@runit.sintef.no Cc: namedroppers@internic.net, dns-security@tis.com Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and draft-ietf-dnsind-clarify-02.txt) In-Reply-To: <199611241916.UAA28839@vader.runit.sintef.no> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by portal.ex.tis.com id JAA10896 Sender: owner-dns-security@ex.tis.com Precedence: bulk On Sun, 24 Nov 1996 Havard.Eidnes@RUNIT.SINTEF.NO wrote: > Date: Sun, 24 Nov 1996 20:16:12 +0100 > From: Havard.Eidnes@RUNIT.SINTEF.NO > To: namedroppers@internic.net > Cc: dns-security@TIS.COM > Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and draft-ietf-dnsind-clarify-02.txt) > > > Unfortunately, DNS Security makes all this a bit more complex. > > > > For example, you need to be able to have all of the security > > RRs types (SIG, NXT, & KEY) present with a CNAME. And the > > superzone's version of the KEY RR at a cut point is better than > > the subzone's. > > Hm, let me see if I have understood this correctly. DNSSEC seems to > specify that at a zone cut the parent zone contains an RR (e.g. KEY > RR) with identical label, class and type as what can potentially be > found in the child zone, but the two records have different data > fields, different semantics, and that the RR from the parent is > supposed to be considered "more credible" (or what else means > "better") than the data from the child zone? Well I wouldn't say that. If the superzone is secure, it is mandatory for it to have at least one KEY RR at each cut point leaf node. And, if the zone is secure, everything in it is signed, including these cut point KEY RRs, NS RRs, etc. (It could be that the signed key merely certifies that the subzone is not secure.) The superior authenticity of the KEY in the superzone really comes from it being signed by the superzone. If the same KEY and SIG appear at the apex of the subzone, they are equally authentic. If the subzone administrator is careful to put the zone public key and it's authenticating signature from above in the subzone, then it is not clear that any change in the standard DNS authority strategy is required for KEY in this case. > I hope that I am not the only one feels uncomfortable with this. > The way I understand it this would in effect create an RRset split > over two different zones, which is in direct conflict with the > clarify-02 draft (at least with my interpretation of it). > > Under DNSSEC, what other records have this property that they can be > present both in the parent and the child zones (at a zone cut) and > have different semantics attached to them dependent on where the > data originates? SIG and NXT in addition to KEY? Are these the > only ones? I think that for all the security RRs, the subzone RRs can be aranged to be superset of the superzone's RRs given enough cooperation between the subzone and superzone administrators. > Can this be avoided? Cleanly? > > I thought a bit about the KEY RRs in conjunction with zone cuts, and > the architectural purists among you can skip the rest of this > paragraph... What about having the parent KEY RR stored with a > different label in the parent zone (e.g. by adding "/pkey" or > something like that to the label)? That way the name server for the > parent zone can claim authority in the traditional manner for the > KEY record, and you avoid having an RRset being "split" over two > zones. (Ok, I have probably not understood the impact this might > have on the NXT records.) I don't think there is a need for this. > I think that the broader issue here is "how strong a departure from > existing practices should DNSSEC be allowed to impose", with the > practical consequences from the decision being "how difficult will > it be to gradually deploy DNSSEC into the DNS" (?). I'm not sure how strong the correlation is between these. TIS has implemented DNSSEC in BIND and my understanding is that the intent is for those changes to be incorporated in the main version at some point. And I believe Microsoft is doing a DNS implementation and looking at DNSSEC. If both of these happen, then deplying DNSSEC at a site is just switching to a more recent version of the software. If you are asking about interoperability of secure and non-secure DNS servers, I believe this is fully covered in the DNSSEC draft. The only insurmountable problem is that you can't secure CNAME RRs retrieved fron a non-secure server. > - Håvard 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 From owner-dns-security Mon Nov 25 09:27:55 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA10952 for dns-security-outgoing; Mon, 25 Nov 1996 09:27:53 -0500 (EST) From: Masataka Ohta Message-Id: <199611251415.XAA04706@necom830.hpcl.titech.ac.jp> Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and To: lewis@tis.com (Edward Lewis) Date: Mon, 25 Nov 96 23:15:39 JST Cc: owner-dns-security@tis.com, namedroppers@internic.net, dns-security@tis.com, ogud@tis.com In-Reply-To: ; X-Mailer: ELM [version 2.3 PL11] Sender: owner-dns-security@ex.tis.com Precedence: bulk Edward; > The result of the parent's being authoritive for the existence of the > name is that the parent has an NXT including the name. NXT is another bad design of Donald. Even though I'm the first to show how to authoritatively show that some domain does not exist, he modified it badly only to make the protocol incompatible to DNS. Masataka Ohta From owner-dns-security Mon Nov 25 12:47:28 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA11345 for dns-security-outgoing; Mon, 25 Nov 1996 12:46:26 -0500 (EST) Message-Id: Date: Mon, 25 Nov 96 09:48 PST From: randy@psg.com (Randy Bush) To: namedroppers@internic.net, dns-security@tis.com Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and draft-ietf-dnsind-clarify-02.txt) References: <199611241916.UAA28839@vader.runit.sintef.no> Sender: owner-dns-security@ex.tis.com Precedence: bulk Does this level of misunderstanding and complexity ring alarm bells in anybody's head other than mine? randy From owner-dns-security Mon Nov 25 13:29:50 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA11427 for dns-security-outgoing; Mon, 25 Nov 1996 13:29:34 -0500 (EST) Date: Mon, 25 Nov 1996 13:32:27 -0500 (EST) From: Edward Lewis X-Sender: lewis@singsing.hq.tis.com To: Randy Bush cc: namedroppers@internic.net, dns-security@tis.com Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and draft-ietf-dnsind-clarify-02.txt) 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 On Mon, 25 Nov 1996, Randy Bush wrote: > Does this level of misunderstanding and complexity ring alarm bells in > anybody's head other than mine? Being new to this game, I don't know about the "misunderstanding" issue, but having spent some time hammering away at a program to apply signatures to a zone, I don't think complexity is a serious issue. There is inherently the issue of lame delegations - wherein the information concerning a delegation is different in the delegating zone and the delegated zone (i.e., above and below the zone cut). DNSSEC definitely does not complicate that issue, but does offer some assistance - with signed NS records from the delegated zone and a signed NXT in the delegating zone, the resolver can safely assume there is a delegation and can identify the correct data. If the data as signed is inaccurate, then bets are off. Although the specifications may appear to be leading to a complex solution, as we have been delving deeper into the details *IMHO* I believe we are working towards at least one workable and simple solution to both DNSSEC and DNSSEC w/Dynamic Update. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: 301-854-5794 Email: lewis@tis.com From owner-dns-security Mon Nov 25 15:19:28 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA11636 for dns-security-outgoing; Mon, 25 Nov 1996 15:19:00 -0500 (EST) Date: Mon, 25 Nov 1996 15:18:24 -0500 (EST) From: "Donald E. Eastlake 3rd" To: namedroppers@internic.net, dns-security@tis.com Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and In-Reply-To: <199611251156.UAA04363@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 On Mon, 25 Nov 1996, Masataka Ohta wrote: > Date: Mon, 25 Nov 1996 08:08:49 -0500 (EST) > From: Masataka Ohta > Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and > draft-ietf-dnsind-clarify-02.txt) > To: Havard.Eidnes@runit.sintef.no > Date: Mon, 25 Nov 96 20:56:24 JST > Cc: namedroppers@internic.net, dns-security@tis.com > In-Reply-To: <199611241916.UAA28839@vader.runit.sintef.no>; from > "Havard.Eidnes@RUNIT.SINTEF.NO" at Nov 24, 96 8:16 pm > X-Mailer: ELM [version 2.3 PL11] > Sender: owner-dns-security@portal.ex.tis.com > Precedence: bulk > > Havard; > > > > Unfortunately, DNS Security makes all this a bit more complex. > > > > > > For example, you need to be able to have all of the security > > > RRs types (SIG, NXT, & KEY) present with a CNAME. And the > > > superzone's version of the KEY RR at a cut point is better than > > > the subzone's. > > > > Hm, let me see if I have understood this correctly. > > I'm afraid your attempt to persuade Donald will fail. > > Even if it had succeeded, there remains a problem that the > glue information makes the packet size exceed 512 bytes. Under what circumstances? Say you are using 768 bit keys (the draft recommends somewhat shorter ones) and retrieve NS from foo.com where the answers are ns1.foo.com and ns2.foo.com with glue A records. My real quick calculation of the answer size is 395 byte: 24 for the header, 32 each for the two NSs, and, as additional info, 23 for each of the two As, 121 for the zone KEY for the subzone and 140 for the SIG signing the KEY for the subzone. (I ignored name compression.) True if there are multiple KEYs or multiple SIGs, you can easily exceed the current UDP packet size but the explicit and overwhelming consensus of the WG was for simplicity even if it produced longer answers. People seemed to think that other changes would ameriorate the DNS UDP packet size problem before DNSSEC was sufficiently wide spread that this would be a serious problem. > This is a problem of WG management. > > Long time ago, in some (Seatle?) DNSSEC meeting, there was a > discussion and the WG agreements that: > > Cryptographically, glue informaiton in the parent zone gives > no protection. I don't quite know what your are saying in the above sentence but, indeed, the DNSSEC draft was modified from earlier versions to specifically prohibit SIGs on NS and glue A records in a superzone at cut points. > For DNS compatibility, there should be no additional glue. I don't know exactly what you mean here. If you are talking about NXT, for example, the WG did not decide to toally redesign that. > Before and after the meeting, I repeatedly says Donald that he should > remove it. > > But, he didn't. > > The chairman of the WG, James Galvin, also knows, but does not > understand either, the issue. > > I finally gave up and abandoned the WG. > > The problems are: > > Donald does not know DNS well to understand subtle > architecural principles of it. I don't know DNs as well as some people. But I trust Bob Austein, Paul Vixie, and the folks as TIS who are implementing DNSSEC. > Donald is a bad editor not to reflect the WG consensus to > the WG draft. There may be some reasonable points of technical disagreement but this isn't one of them. My draft is *exactly* the working group consensus. I understand that you don't like the DNSSEC WG consensus. I understand that you think the consensus is fatally flawed techncially. But, as far as I can tell, a completely overwhelming consensus of the WG supported the current draft. I stand by my job a editor in reflcting WG consensus. > James Galvin is a bad chair not to be able to remove Donald. I'm not sure why he would want to remove me since I've done everything he asked of me. > They are not technical problems and I know technical discussion > is meaningless until after the chair and the editor are replaced. > > Donald and James, do you want to voluntarily step down or, > at least, let DNSIND modify the draft? If you would like to propose specific changes to the IETF Proposed Standard, I'd be happy to look at them. I never thought it was carved in stone and would expect some changes as more implementation experience is gained. > Masataka Ohta 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 From owner-dns-security Mon Nov 25 15:27:30 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA11683 for dns-security-outgoing; Mon, 25 Nov 1996 15:27:29 -0500 (EST) Date: Mon, 25 Nov 1996 15:26:47 -0500 (EST) From: "Donald E. Eastlake 3rd" To: namedroppers@internic.net, dns-security@tis.com Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and In-Reply-To: <199611251415.XAA04706@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 There are a number of different ways to authenticate the non-existence of names. If I recall correcly, your technique had, for a zone of any size, an enormous pile of RRs with the zone name (or a smaller number of enourmous RRs) which would have had to be indexed by some new technique to find the right one to send back on a non-existent name query, your proposal had nothing about and didn't consider wildcards, and I also don't recall how your proposal handled non-existent types for existing, if at all. But maybe I don't remember correctly. Maybe your prospal didn't have any of these problems. It doesn't seem very relavent unless the Proposed Standard turns out to be a problem, does it? I know you are absolutely certain it is fatally flawed but so far your belief has not be bourne out in practice. As far as I can remember, the NXT proposal in my and Charlie Kaufman's draft was original work and was not produced by modifying your proposal and certainly neither it nor any other part of the DNSSEC Proposed Standard was motivated by a desire to be incompatible with classic DNS. However this also doens't seem very relevant since you are credited for contributing and I think it is part of the normal WG process for ideas to be combined. Donald On Mon, 25 Nov 1996, Masataka Ohta wrote: > Date: Mon, 25 Nov 96 23:15:39 JST > From: Masataka Ohta > To: Edward Lewis > Cc: owner-dns-security@tis.com, namedroppers@internic.net, > dns-security@tis.com, ogud@tis.com > Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and > > Edward; > > > The result of the parent's being authoritive for the existence of the > > name is that the parent has an NXT including the name. > > NXT is another bad design of Donald. Even though I'm the > first to show how to authoritatively show that some domain > does not exist, he modified it badly only to make the > protocol incompatible to DNS. > > Masataka Ohta > > > ===================================================================== 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 From owner-dns-security Mon Nov 25 15:39:31 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA11722 for dns-security-outgoing; Mon, 25 Nov 1996 15:39:29 -0500 (EST) Message-Id: <199611252039.PAA11722@portal.ex.tis.com> Date: Mon, 25 Nov 1996 15:19:50 -0500 (EST) From: "Donald E. Eastlake 3rd" To: namedroppers@internic.net, dns-security@tis.com Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and draft-ietf-dnsind-clarify-02.txt) In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@portal.ex.tis.com Precedence: bulk Masataka Ohta has always proclaimed the Proposed Standard for DNS Security to be fatally flawed. However, when I repeated challenged him to produce an exact specific case where it would not work (other than those document plainly in the draft), he never did. Since the people actually implementing it at TIS, who have a Beta release out and available, and other DNS experts who have looked at it to various depths, have yet to find any unsolvable problems, I suggest we wait a bit for more implementation and interoperation experience. Donald On Mon, 25 Nov 1996, Randy Bush wrote: > Date: Mon, 25 Nov 96 09:48 PST > From: Randy Bush > To: namedroppers@internic.net, dns-security@tis.com > Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and draft-ietf-dnsind-clarify-02.txt) > > Does this level of misunderstanding and complexity ring alarm bells in > anybody's head other than mine? > > randy > ===================================================================== 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 From owner-dns-security Mon Nov 25 17:27:08 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA11770 for dns-security-outgoing; Mon, 25 Nov 1996 17:26:07 -0500 (EST) Message-Id: <2.2.32.19961125222641.01677670@pop-sb.software.com> X-Sender: WrenP@pop-sb.software.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 25 Nov 1996 14:26:41 -0800 To: randy@psg.com (Randy Bush), namedroppers@internic.net, dns-security@tis.com From: Paul Wren Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and draft-ietf-dnsind-clarify-02.txt) Sender: owner-dns-security@ex.tis.com Precedence: bulk At 09:48 AM 11/25/96 PST, Randy Bush wrote: >Does this level of misunderstanding and complexity ring alarm bells in >anybody's head other than mine? > I had previously replied privately to Randy, not wanting to stomp on anybody's toes, and he suggested I cc the list. Okay. As the developer of a ground-up rewrite of a DNS server from the RFC's, I do find it worrisome that a number of very complex issues are arising that were definitely not apparent on a first, second, or third reading (for me) of the DNSSEC draft. Since it is a "proposed standard" document, that is problematic. And while Ohta is classically a trouble-maker, there are some level-headed comments as well that seem to be an issue. I agree that secure DNS is a must-have, and that security is a very complicated topic, but the interoperability of the Internet is not necessarily proven or supported by the statement that "TIS has a working BETA on top of BIND" and that "MS is working on it" as if those two are all that is required. (the second being a less-than-comforting thought to anyone without $1 billion in the bank) Note that my opinions are my own and all that... -- Paul W. From owner-dns-security Tue Nov 26 07:27:09 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA12772 for dns-security-outgoing; Tue, 26 Nov 1996 07:24:40 -0500 (EST) From: Masataka Ohta Message-Id: <199611260345.MAA06627@necom830.hpcl.titech.ac.jp> Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and To: dee@cybercash.com (Donald E. Eastlake 3rd) Date: Tue, 26 Nov 96 12:45:02 JST Cc: namedroppers@internic.net, dns-security@tis.com In-Reply-To: ; from "Donald E. Eastlake 3rd" at Nov 25, 96 3:26 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-dns-security@portal.ex.tis.com Precedence: bulk Donald; > There are a number of different ways to authenticate the non-existence of > names. If I recall correcly, your technique had, for a zone of any size, an > enormous pile of RRs with the zone name (or a smaller number of enourmous > RRs) which would have had to be indexed by some new technique to find the > right one to send back on a non-existent name query, your proposal had > nothing about and didn't consider wildcards, and I also don't recall how your > proposal handled non-existent types for existing, if at all. But maybe I > don't remember correctly. Maybe your prospal didn't have any of these > problems. >From the day one of my proposal, all the problems you mentioned was solved explicitely. See the following text: ZL (Zone List) data used to store sorted list of all the nodes in a zone. The information is necessary for protection against denial of service attacks, that is, if a node does not appear in certain ZLs, a negative response that a queried node does not exist is authenticated. The simplest way to authenticate negative answer that some data does not exist is to have an authenticated list of all the existing data. But, unless the number of existing data is expected to be small, as in the case with [RRD], listing up is inefficient. Especially, for a very large zone such as "com.", the size of the list is impractically large. So, existing data are sorted in a certain order and segmented appropriately into multiple ZL records. To authenticate the non-existence of a node, only a ZL RR containing the node (according to the sorting order) needs to be returned. To not to cause UDP size overflow, ZL RRs are intended to be returned as a partial RR in the additional section of a negative answer with truncation bit set. To authenticate a partial ZL RR, it is necessary to attach authentication signatures to individual ZL RRs. With wildcarding, actual authentication is a little more complicated and is discussed in section 5.3: "Resolver Algorithm". > It doesn't seem very relavent unless the Proposed Standard turns > out to be a problem, does it? It's your problem that it was not very relavent. I explained the problem several times by e-mail. > As far as I can remember, the NXT proposal in my and Charlie Kaufman's draft > was original work and was not produced by modifying your proposal and Your opinion before looking at my proposal was that negative authentication was impossible. > However this also > doens't seem very relevant since you are credited for contributing and I > think it is part of the normal WG process for ideas to be combined. That's fine if the ideas were combined. Masataka Ohta From owner-dns-security Tue Nov 26 07:27:09 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA12785 for dns-security-outgoing; Tue, 26 Nov 1996 07:25:40 -0500 (EST) From: Masataka Ohta Message-Id: <199611260447.NAA06809@necom830.hpcl.titech.ac.jp> Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and To: dee@cybercash.com (Donald E. Eastlake 3rd) Date: Tue, 26 Nov 96 13:47:27 JST Cc: namedroppers@internic.net, dns-security@tis.com X-Mailer: ELM [version 2.3 PL11] Sender: owner-dns-security@ex.tis.com Precedence: bulk Donald; > > I'm afraid your attempt to persuade Donald will fail. > > > > Even if it had succeeded, there remains a problem that the > > glue information makes the packet size exceed 512 bytes. > > Under what circumstances? Say you are using 768 bit keys (the draft > recommends somewhat shorter ones) and retrieve NS from foo.com where the > answers are ns1.foo.com and ns2.foo.com with glue A records. My real quick > calculation of the answer size is 395 byte: 24 for the header, 32 each for > the two NSs, and, as additional info, 23 for each of the two As, 121 for the > zone KEY for the subzone and 140 for the SIG signing the KEY for the subzone. > (I ignored name compression.) The problem is that the delegation packets are already full of A and NS records. But, it actually, is not a problem becasue we don't need any signature in the delegation, which was the WG consensus. > > Cryptographically, glue informaiton in the parent zone gives > > no protection. > > I don't quite know what your are saying in the above sentence but, > indeed, the DNSSEC draft was modified from earlier versions to > specifically prohibit SIGs on NS and glue A records in a superzone at cut > points. What? SIGs? Draft-ietf-dnssec-secext-10.txt still insists that: 2.3.4 Special Considerations at Delegation Points In general, there must be a zone KEY RR for the subzone in the superzone and the copy signed in the superzone is controlling. which is wrong. The glue KEY RR is useless. The following text of mine should be helpful to understand this cryptographical issue: No NSIG records are provided for non-authoritative data for a zone such as referral information. Thus, if a name server is compromised or its IP address is used by an attacker, it is possible to implant false referral information to a resolver. Still, as child zones have its own information, ZSIG (Zone SIGnature) described later, to authenticate themselves, the attacked resolver can detect that the referral information is bogus. The result is no worse than a simple denial of service attack by compromising name servers of the parent zone. That is, it is not necessary nor meaningful to try to authenticate referral NSes or glue A records for child zones. Masataka Ohta From owner-dns-security Tue Nov 26 08:40:48 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA13234 for dns-security-outgoing; Tue, 26 Nov 1996 08:40:27 -0500 (EST) Date: Tue, 26 Nov 1996 08:43:34 -0500 (EST) From: Edward Lewis X-Sender: lewis@singsing.hq.tis.com To: Masataka Ohta cc: "Donald E. Eastlake 3rd" , namedroppers@internic.net, dns-security@tis.com Subject: RE: ZL's (was Re: DNSSEC and split ...) In-Reply-To: <199611260345.MAA06627@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 On Tue, 26 Nov 1996, Masataka Ohta wrote: > ZL (Zone List) ... > authenticated. The simplest way to authenticate negative answer > that some data does not exist is to have an authenticated list of > all the existing data. But, unless the number of existing data is ... > inefficient. Especially, for a very large zone such as "com.", > the size of the list is impractically large. So, existing data > are sorted in a certain order and segmented appropriately into > multiple ZL records. To authenticate the non-existence of a node, ... This is very, very similar to the NXT record. Not that I am implying any "stealing" of ideas is evident - I do not know the history, nor as an engineer care to dwell on any of the issues relating to that. ZL's - assuming this is a ZL RR which holds all of the names, and presumable RR sets, in a zone or a subset of a zone - seem isomorphic to NXT RRs. By explicitly stating what is present, what is not stated can be assumed to be non-existant. Both ZL's and NXT's require an ordering of the zone's domain names and a grouping of all domain names together (at least at some point in the signing process) - which is a performance bear. I've written the code to do this and it is a bear. (Bear => a very annoyingly large problem.) Note: the ZL would not necessarily require an ordering of all names in a zone if it always was kept whole. But, for .COM, this is not practical. If all the names were listed - and all RR set too - then a linear search is all that would be needed. But then looking for a non-existant .COM name would be akin to an AXFR of .COM. Fortunately, there are few unclaimed names in .COM anymore ;) - sorry couldn't resist. Note note: notice "linear search." Try that on .COM. However, there are three facets of the NXT RR which IMHO give it an advantage over what I see here about ZL's. First, performance. An NXT return only has to send one domain name and a bit field representing what is at the owner. A ZL of N names would then be N times (on average) as long. This sucks bandwidth and processing time at the resolver. Second, denial of service. NXT's make denying access harder. An interloper would have to record more NXT's than ZL's to cover a zone to deny the existence of names and RR sets added later and/or added/deleted via (dynamic) updates. Third, generation. An NXT can be created as soon as I know, for a domain name, all of it's RR's, the signers for the RR's, the delegation points in the zone, and the next name in the zone. For a ZL, I would need to retain multiple copies of this until I fill the ZL. In other words, as I make my final run down a sorted zone I can see a domain name, process it and make the NXT and move on. With ZL's I need to hold a bunch more stuff in memory. Again the term "bear of a problem" comes to mind. The only ways I can see to improve on the concept of the NXTs is to either create a dynamically signed "no, (fill in blank) doesn't exist" response, defend against replay attacks, and/or add revokation of RR's to DNS. The first two are more or less could be covered by transaction signatures, the latter ain't gonna happen (easily). -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: 301-854-5794 Email: lewis@tis.com From owner-dns-security Tue Nov 26 08:56:24 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA13378 for dns-security-outgoing; Tue, 26 Nov 1996 08:56:22 -0500 (EST) Date: Tue, 26 Nov 1996 08:59:13 -0500 (EST) From: Edward Lewis X-Sender: lewis@singsing.hq.tis.com To: Masataka Ohta cc: "Donald E. Eastlake 3rd" , namedroppers@internic.net, dns-security@tis.com Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and In-Reply-To: <199611260447.NAA06809@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 On Tue, 26 Nov 1996, Masataka Ohta wrote: > What? SIGs? Draft-ietf-dnssec-secext-10.txt still insists that: > > 2.3.4 Special Considerations at Delegation Points > > In general, there must be a zone KEY RR for the subzone in the > superzone and the copy signed in the superzone is controlling. > > which is wrong. The glue KEY RR is useless. Not exactly useless - having information is never useless. IMHO - and this is a very subtle point - is that the presence of the KEY RR is not as security significant as the SIG RR that signs the KEY, which is signed by the "superzone." I am not supporting an effort to chsnge that text, but in reality, it's the signature of the key that is more significant. (There's always that issue in the wings: what happens when a delgating zone is not secured by a zone key, but the delgated zone is? No need to get into that now, it's just in the back of my mind...maybe that issue will go away.) > > The following text of mine should be helpful to understand this > cryptographical issue: > > No NSIG records are provided for non-authoritative data for a zone > such as referral information. Thus, if a name server is > compromised or its IP address is used by an attacker, it is > possible to implant false referral information to a resolver. (What are NSIG's? SIGs over NS RRs?) If the delegated zone is secure, then there will be a signed (by delegating zone) key present for the delegated zone. A false NS record could lead to a denial of service *but* the resolver would be able to detect that the attack was happening because there would be no verifyable signature for the false NS record - unless the signature was forged due to a compromise of the zone key (delegator or delgatee). Being able to avoid denial of service is not a reasonable expectation - being able to detect and respond to them is. The resolver can become suspicious, possibly resulting in an out of band call to the human running the zone under attack... > Still, as child zones have its own information, ZSIG (Zone > SIGnature) described later, to authenticate themselves, the > attacked resolver can detect that the referral information is > bogus. The result is no worse than a simple denial of service > attack by compromising name servers of the parent zone. That is, > it is not necessary nor meaningful to try to authenticate referral > NSes or glue A records for child zones. I'm sorry, I guess I don't understand your point. Are you arguing for or against signing delegation point records? You're last two paragraphs seem to contradict each other. I don't think it's the resolver that's under attack, but the zone... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: 301-854-5794 Email: lewis@tis.com From owner-dns-security Tue Nov 26 09:08:28 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA13433 for dns-security-outgoing; Tue, 26 Nov 1996 09:08:22 -0500 (EST) Date: Tue, 26 Nov 1996 09:07:44 -0500 (EST) From: "Donald E. Eastlake 3rd" To: dns-security@tis.com Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and In-Reply-To: <199611260345.MAA06627@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 Masataka, Your description is about as I remember it, a huge pile of stuff all under the zone name. How do you authenticate the non-existence of a type at an existing name under your scheme? Donald On Tue, 26 Nov 1996, Masataka Ohta wrote: > Date: Tue, 26 Nov 96 12:45:02 JST > From: Masataka Ohta > To: "Donald E. Eastlake 3rd" > Cc: namedroppers@internic.net, dns-security@tis.com > Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and > > "Donald E. Eastlake 3rd" at Nov 25, 96 3:26 pm > X-Mailer: ELM [version 2.3 PL11] > Sender: owner-dns-security@portal.ex.tis.com > Precedence: bulk > > Donald; > > > There are a number of different ways to authenticate the non-existence of > > names. If I recall correcly, your technique had, for a zone of any size, an > > enormous pile of RRs with the zone name (or a smaller number of enourmous > > RRs) which would have had to be indexed by some new technique to find the > > right one to send back on a non-existent name query, your proposal had > > nothing about and didn't consider wildcards, and I also don't recall how your > > proposal handled non-existent types for existing, if at all. But maybe I > > don't remember correctly. Maybe your prospal didn't have any of these > > problems. > > >From the day one of my proposal, all the problems you mentioned was > solved explicitely. > > See the following text: > > ZL (Zone List) > > data used to store sorted list of all the nodes in a zone. The > information is necessary for protection against denial of service > attacks, that is, if a node does not appear in certain ZLs, a > negative response that a queried node does not exist is > authenticated. The simplest way to authenticate negative answer > that some data does not exist is to have an authenticated list of > all the existing data. But, unless the number of existing data is > expected to be small, as in the case with [RRD], listing up is > inefficient. Especially, for a very large zone such as "com.", > the size of the list is impractically large. So, existing data > are sorted in a certain order and segmented appropriately into > multiple ZL records. To authenticate the non-existence of a node, > only a ZL RR containing the node (according to the sorting order) > needs to be returned. To not to cause UDP size overflow, ZL RRs > are intended to be returned as a partial RR in the additional > section of a negative answer with truncation bit set. To > authenticate a partial ZL RR, it is necessary to attach > authentication signatures to individual ZL RRs. With wildcarding, > actual authentication is a little more complicated and is > discussed in section 5.3: "Resolver Algorithm". > > ... > > Masataka Ohta ===================================================================== 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 From owner-dns-security Tue Nov 26 09:55:14 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA13653 for dns-security-outgoing; Tue, 26 Nov 1996 09:54:27 -0500 (EST) From: Masataka Ohta Message-Id: <199611261446.XAA08136@necom830.hpcl.titech.ac.jp> Subject: RE: ZL's (was Re: DNSSEC and split ...) To: lewis@tis.com (Edward Lewis) Date: Tue, 26 Nov 96 23:46:41 JST Cc: mohta@necom830.hpcl.titech.ac.jp, dee@cybercash.com, namedroppers@internic.net, dns-security@tis.com In-Reply-To: ; X-Mailer: ELM [version 2.3 PL11] Sender: owner-dns-security@ex.tis.com Precedence: bulk Edward; > This is very, very similar to the NXT record. Not that I am implying > any "stealing" of ideas is evident - It's OK to copy my idea. Note also that, as far as I know, the idea is NOT patent protected. > I do not know the history, nor > as an engineer care to dwell on any of the issues relating to that. The history is that, I explained by e-mail how to authenticate the non-existence of domains expecting to be picked up by Donald. I, also, continueously explained why Donald's draft is unnecessarily incomatible to the DNS architecture. But, nothing were reflected. So, I wrote my own. > By explicitly stating what is present, what is not stated can be > assumed to be non-existant. Both ZL's and NXT's require an ordering > of the zone's domain names Of course. > and a grouping of all domain names together > (at least at some point in the signing process) - which is a performance > bear. I've written the code to do this and it is a bear. I can't understand your point here. Each ZL RR's are signed separately. With B-tree like splitting and merging, deletions and additions of nodes can be done with a few ZL RRs near the node locally without affecting the rest of the ZL RRs. > Note note: notice "linear search." Try that on .COM. That's why ZL RRs are sorted to be useful for binary serach. > However, there are three facets of the NXT RR which IMHO give it an > advantage over what I see here about ZL's. I'm afraid you misunderstand the Internet. > First, performance. An NXT return only has to send one domain name and > a bit field representing what is at the owner. A ZL of N names would then > be N times (on average) as long. This sucks bandwidth and processing > time at the resolver. What? You can always make N 1. The reason why N can be larger than 1 is for better performance than NXT. As DNS RR headers are *LENGTHY*, it is inefficient for nameservers to have non-existence authentication separately for each node. This sucks memory of name servers and bandwidth and processing time for zone transfer. And, for usual transfer, it's a single UDP packet with less than 512 bytes of size with A LOT OF header overhead. As you know, on the Internet, it does not matter so much whether a packet is 200 byte long or 300. Moreover, a single ZL can be negatively cached to reduce bandwidth and processing power consumption. Thus, it is, IMO, beneficial to not to make N 1. You may disagree to set N 1. > Second, denial of service. NXT's make denying access harder. An > interloper would have to record more NXT's than ZL's to cover a zone > to deny the existence of names and RR sets added later and/or > added/deleted via (dynamic) updates. First, see above. You can always make N 1 if you don't mind performance loss. Second, ZL does not protect RR sets. There is separate mechanism for it. Third, it is unlikely that the interloper want to attack the zone as a whole. A single NXT or ZL RR is enough to fake that a target domain name does not exist. Forth, if you do want to attack a zone as a whole, you can collect as much NXT or ZL as you want by making simple queries on the zone about non-existent names. Fifth, the semantics of DNS, including secure DNS, is that the users must accept a fact that it may receive data with older versions. > Third, generation. An NXT can be created as soon as I know, for a domain > name, all of it's RR's, the signers for the RR's, the delegation points > in the zone, and the next name in the zone. Really? ZL needs a domain name only and is better, then. > For a ZL, I would need to retain > multiple copies of this until I fill the ZL. What is "this"? What do you mean "until I fill"? > In other words, as I make > my final run down a sorted zone I can see a domain name, process it and > make the NXT and move on. What is the "my final run"? If you think you must sign NXT as a whole, it is a problem of NXT. > With ZL's I need to hold a bunch more stuff > in memory. With ZL, I need to hold an existing domain names only. And, B-tree (or B+ or whatever) like algorithm is always applicable for local modification. > Again the term "bear of a problem" comes to mind. So, NXT has the "bear of a problem". > The only ways I can see to improve on the concept of the NXTs is to > either create a dynamically signed "no, (fill in blank) doesn't exist" > response, defend against replay attacks, No. Secondary servers won't know the secret keys. > and/or add revokation of RR's > to DNS. ZL and revokation of RR's is unrelated. Revocation of domain names is what I was thinking to add as a possible improvement but dropped. > The first two are more or less could be covered by transaction > signatures, No, it isn't covered. Nameservers are unreliable. > the latter ain't gonna happen (easily). It's easy. But, it's expensive, which is why I didn't make it included. Masataka Ohta From owner-dns-security Tue Nov 26 10:19:15 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA13842 for dns-security-outgoing; Tue, 26 Nov 1996 10:19:04 -0500 (EST) Date: Tue, 26 Nov 1996 10:22:03 -0500 (EST) From: Edward Lewis X-Sender: lewis@singsing.hq.tis.com To: Masataka Ohta cc: mohta@necom830.hpcl.titech.ac.jp, dee@cybercash.com, namedroppers@internic.net, dns-security@tis.com Subject: RE: ZL's (was Re: DNSSEC and split ...) In-Reply-To: <199611261446.XAA08136@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 On Tue, 26 Nov 1996, Masataka Ohta wrote: > I'm afraid you misunderstand the Internet. ;) I'm afraid I don't understand ZL's. Perhaps I misinterpreted your description. How about trying this to clear things up for me. Please, show me the (textual version of the) zone after ZL's are added for the following two zones. Please include whatever mechanism you propose to cover the RR sets for a given existing name. $ORIGIN zone. $SIGNER zone. @ SOA (SOA stuff) NS (NS stuff) KEY (KEY stuff) d NS (NS sutff) MX (MX stuff) KEY (KEY stuff) b MX (MX stuff) c TXT (TXT stuff) MX (MX stuff) a A (A stuff) e A (A stuff) a A (A stuff) ; yes, twice b A (A stuff) ;end and $ORIGIN d.zone. $SIGNER d.zone. @ SOA (SOA stuff) NS (NS stuff) NS (NS stuff) KEY (KEY stuff) x TXT (TXT stuff) w A (A stuff) y A (A stuff) ;end Nothing tricky about this example, I just want to see the simple version of your concept in plain ol' ISO-8859-1. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: 301-854-5794 Email: lewis@tis.com From owner-dns-security Tue Nov 26 10:40:14 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA13943 for dns-security-outgoing; Tue, 26 Nov 1996 10:40:10 -0500 (EST) Message-Id: <9611261541.AA15251@sol.hq.tis.com> To: Paul Wren Cc: ogud@tis.com, namedroppers@internic.net, dns-security@tis.com Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and draft-ietf-dnsind-clarify-02.txt) In-Reply-To: Your message of "Mon, 25 Nov 1996 14:26:41 PST." <2.2.32.19961125222641.01677670@pop-sb.software.com> Date: Tue, 26 Nov 1996 10:41:33 -0500 From: Olafur Gudmundsson Sender: owner-dns-security@ex.tis.com Precedence: bulk Paul Wren writes: > As the developer of a ground-up rewrite of a DNS server from the RFC's, I do > find it worrisome that a number of very complex issues are arising that were > definitely not apparent on a first, second, or third reading (for me) of the > DNSSEC draft. Since it is a "proposed standard" document, that is > problematic. And while Ohta is classically a trouble-maker, there are some > level-headed comments as well that seem to be an issue. I agree that there are issues that are not clear in the draft, but please understand the following: 1. This is the first time people are actualy securing a distributed database which has distributed authority (on the scale of DNS) 2. Donald and Charlie are writing the specs in their spare time. 3. Number of people have (including myself) have contributed many suggestions to the authors on how to make the document better, but it is not perfect. 4. DNS operating practice is different from the RFC's, see current ID's on dns-clarify, dns-names 5. DNS specs (1034, 1035) are not clear on many points, 6. DNS is being enhanced (dynamic update) and that design makes it harder to design security model. (we are close to one). 7. Not enough people have come forward with constructive suggestions, but there has been plenty of mud thrown around. 8. Unfortunately, in the realm of TCP/IP and the internet, rigid compliance with written documentation is rare. If you were to implement TCP rigidly, you would not be interoperable with many current versions (including commercial ones). This is an artifact of the open process and "rough consensus." It's not perfect, but it ordinarily "gets the job done." I expect that interoperabilty tests will point out number of things that need to be specified better, these changes will be incorporated before DNSSEC goes to full standard. Also, as we progress we may discover better ways to certain things. Please continue to forward your questions/comments to dns-security@tis.com. Olafur From owner-dns-security Tue Nov 26 11:11:53 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA14155 for dns-security-outgoing; Tue, 26 Nov 1996 11:11:33 -0500 (EST) From: Masataka Ohta Message-Id: <199611261605.BAA08436@necom830.hpcl.titech.ac.jp> Subject: RE: ZL's (was Re: DNSSEC and split ...) To: lewis@tis.com (Edward Lewis) Date: Wed, 27 Nov 96 1:05:33 JST Cc: mohta@necom830.hpcl.titech.ac.jp, dee@cybercash.com, namedroppers@internic.net, dns-security@tis.com In-Reply-To: ; X-Mailer: ELM [version 2.3 PL11] Sender: owner-dns-security@ex.tis.com Precedence: bulk Edward; > On Tue, 26 Nov 1996, Masataka Ohta wrote: > > I'm afraid you misunderstand the Internet. > > ;) > > I'm afraid I don't understand ZL's. Perhaps I misinterpreted > your description. > > How about trying this to clear things up for me. Please, show > me the (textual version of the) zone after ZL's are added for > the following two zones. The generic form is: ZL ... For the first zone, it can be: zone. ZL zone. zone. 6 zone. a.zone. b.zone. c.zone. d.zone. e.zone. or it can be: zone. ZL zone. ab.zone. 2 zone. a.zone. zone. ZL ab.zone. d.zone. 2 b.zone. c.zone. zone. ZL d.zone. zone. 2 d.zone. e.zone. For the second zone, it can be: zone. ZL zone. zone. 4 zone. w.zone. x.zone. y.zone. > Please include whatever mechanism > you propose to cover the RR sets for a given existing name. While it possible, the result is boring. If you insist that I should, could you please do it with NXT first? First, let me explain in English. > a A (A stuff) > e A (A stuff) > a A (A stuff) ; yes, twice No problem. Each node (NOT including referral one) has (MD5?) digest of all RRs of the node, which then, is signed. For details, see the attached text on RRD. BTW, I'll ask Cynthia to publish my expired Internet Draft again. The name of the draft was: and will be If you want to see it immediately, feel free to ask me privately. Masataka Ohta RRD (RR Digest) Digest value of all the data with a certain RR type in a secure node. [RRD] RRs have the following syntax ( and are omitted throughout the document): [RRD] where [RRD] is the RR name of RRD, is the digest of all the resource records of type of node . is the original TTL value of the records. is a 16 bit quantity, is a 32 bit quantity, is of variable length. When computing , records are represented in binary form in DNS packet without domain name compression. If there are multiple records of the same , they are sorted with dictionary order, comparing the first bytes first with unsigned arithmetic. When verifying the digest of received data in resolvers and name servers, TTL field of the records, which should be decreased already, should be replaced with (original TTL). When caching authenticated data, name servers and resolvers should confirm that the TTL in the answer packet does not exceed the value in RRD data. A node, in general, has multiple [RRD] record for each RR type the node has. But, it is impossible and unnecessary to cover s of [RRD] [NSIG] and [ZSIG]. Still, it is necessary to have [RRD] of such s as protection against denial service attacks, that is, to authenticate negative response of non existing RR types. An [RRD] record for [NSIG] or [ZSIG] RR has the field of length zero. To compute of [RRD] RR type itself, the field of the record itself is first considered to have zero length (including length field of the record) and later replaced with the actual digest length and value. From owner-dns-security Tue Nov 26 11:55:28 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA14378 for dns-security-outgoing; Tue, 26 Nov 1996 11:55:11 -0500 (EST) Date: Tue, 26 Nov 1996 11:57:57 -0500 (EST) From: Edward Lewis X-Sender: lewis@singsing.hq.tis.com To: Masataka Ohta cc: mohta@necom830.hpcl.titech.ac.jp, dee@cybercash.com, namedroppers@internic.net, dns-security@tis.com Subject: RE: ZL's (was Re: DNSSEC and split ...) In-Reply-To: <199611261605.BAA08436@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 On Wed, 27 Nov 1996, Masataka Ohta wrote: > While it possible, the result is boring. If you insist that I > should, could you please do it with NXT first? I would like to see the whole "boring" result, but fair enough, here is my version of the examples after running through a signer. NOTE: this is hand generated. I hope there are no typo-level mistakes. (Why didn't I use my signer app you ask. It's kinda stalled awaiting ironing out some issues with the algorithm.) Here's the example: $ORIGIN zone. $SIGNER zone. @ SOA (SOA stuff) NS (NS stuff) KEY (KEY stuff) d NS (NS stuff) MX (MX stuff) KEY (KEY stuff) b MX (MX stuff) c TXT (TXT stuff) MX (MX stuff) a A (A stuff) e A (A stuff) a A (A stuff) ; yes, twice b A (A stuff) ;end and $ORIGIN d.zone. $SIGNER d.zone. @ SOA (SOA stuff) NS (NS stuff) NS (NS stuff) KEY (KEY stuff) x TXT (TXT stuff) w A (A stuff) y A (A stuff) ;end Here's the result: $SIGNER zone. zone. SOA (SOA stuff) zone. SIG (SOA & stuff) zone. SIG (AXFR & stuff) zone. NS (NS stuff) zone. SIG (NS & stuff) zone. KEY (KEY stuff) zone. SIG (KEY & stuff) zone. NXT a.zone. SOA NS KEY SIG NXT zone. SIG (NXT & stuff) a.zone. A (A stuff) a.zone. A (A stuff) ; yes, twice a.zone. SIG (A & stuff) a.zone. NXT b.zone. A SIG NXT a.zone. SIG (NXT & stuff) b.zone. A (A stuff) b.zone. SIG (A & stuff) b.zone. MX (MX stuff) b.zone. SIG (MX & stuff) b.zone. NXT c.zone. A MX SIG NXT b.zone. SIG (NXT & stuff) c.zone. TXT (TXT stuff) c.zone. SIG (TXT & stuff) c.zone. MX (MX stuff) c.zone. SIG (MX & stuff) c.zone. NXT d.zone. MX TXT SIG NXT c.zone. SIG (NXT & stuff) d.zone. NS (NS stuff) d.zone. MX (MX stuff) ; misplaced d.zone. KEY (KEY stuff) d.zone. SIG (KEY & stuff) d.zone. NXT zone. NS MX KEY SIG NXT ; MX is debateable (*) d.zone. SIG (NXT & stuff) ; end and d.zone. SOA (SOA stuff) d.zone. SIG (SOA & stuff) d.zone. SIG (AXFR & stuff) d.zone. NS (NS stuff) d.zone. NS (NS stuff) d.zone. SIG (NS & stuff) d.zone. KEY (KEY stuff) d.zone. SIG (KEY & stuff) d.zone. NXT a.zone. SOA NS KEY SIG NXT d.zone. SIG (NXT & stuff) x.d.zone. TXT (TXT stuff) x.d.zone. SIG (TXT & stuff) x.d.zone. NXT y.d.zone. TXT SIG NXT x.d.zone. SIG (NXT & stuff) y.d.zone. A (A stuff) y.d.zone. SIG (A & stuff) y.d.zone. NXT z.d.zone. A SIG NXT y.d.zone. SIG (NXT & stuff) z.d.zone. A (A stuff) z.d.zone. SIG (A & stuff) z.d.zone. NXT d.zone. A SIG NXT z.d.zone. SIG (NXT & stuff) ; end (*) The only debateable item here is whether the MX record for d.zone. should be in the zone.'s NXT record. The spec says yes, I'm examining that for the case listed - i.e., the MX record only appears where it is glue, and not in the authoritative version. Note: the NXT record for d.zone. two versions, one in each zone. This was mentioned in my first response to this thread. I'd like to see the complete example using ZL's and RRD's and whatever else is proposed. I have trouble understanding your prose (yeah, a fault of mine), and would be able to gain a better understanding if I saw the example worked out to completion. (After all, if a simple case can't be worked out by hand, writing the code is going to be impossible!) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: 301-854-5794 Email: lewis@tis.com From owner-dns-security Tue Nov 26 14:30:52 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA14836 for dns-security-outgoing; Tue, 26 Nov 1996 14:30:32 -0500 (EST) Date: Tue, 26 Nov 1996 14:30:00 -0500 (EST) From: "Donald E. Eastlake 3rd" To: namedroppers@internic.net, dns-security@tis.com Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and In-Reply-To: <199611260447.NAA06809@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 On Tue, 26 Nov 1996, Masataka Ohta wrote: > Date: Tue, 26 Nov 96 13:47:27 JST > From: Masataka Ohta > To: "Donald E. Eastlake 3rd" > Cc: namedroppers@internic.net, dns-security@tis.com > Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and > > Donald; > > > > I'm afraid your attempt to persuade Donald will fail. > > > > > > Even if it had succeeded, there remains a problem that the > > > glue information makes the packet size exceed 512 bytes. > > > > Under what circumstances? Say you are using 768 bit keys (the draft > > recommends somewhat shorter ones) and retrieve NS from foo.com where the > > answers are ns1.foo.com and ns2.foo.com with glue A records. My real quick > > calculation of the answer size is 395 byte: 24 for the header, 32 each for > > the two NSs, and, as additional info, 23 for each of the two As, 121 for the > > zone KEY for the subzone and 140 for the SIG signing the KEY for the subzone. > > (I ignored name compression.) > > The problem is that the delegation packets are already full of > A and NS records. The rules are set up so that if the KEY/SIG don't fit in the additional info section, they are dropped and you can get them with a separate retrieval. They are given lower priority than the glue A records for inclusion as additional info. > But, it actually, is not a problem becasue we don't need any signature > in the delegation, which was the WG consensus. The working group consensus, which is embodied in the Proposed Standard, was to drop signatures on the NS and A records in the superzone. There is at least one case that absolutely requires signed information about the subzone in the superzone. Assume some subzone that is insecure and which not been modifed to include any security related info. There will clearly be many of these for some time to come. Obviously RRs from such zones can be forged, since they are not signed. If you depend on queries to the subzone to tell if it is secure, anyone can forge an insecure subzone even though the real subzone is secure. So this information that the subzone is insecure must be in the secure superzone. In the Proposed Standard, this is encoded into the KEY RR. > > > Cryptographically, glue informaiton in the parent zone gives > > > no protection. > > > > I don't quite know what your are saying in the above sentence but, > > indeed, the DNSSEC draft was modified from earlier versions to > > specifically prohibit SIGs on NS and glue A records in a superzone at cut > > points. > > What? SIGs? Draft-ietf-dnssec-secext-10.txt still insists that: Why are you saying "What?"? SIGs on NS and glue A RRs in the superzone are specifically prohibited in the Proposed Standard. SIGs on KEY and NXT are not affected by prohibiting them on NS and glue A RRs. > 2.3.4 Special Considerations at Delegation Points > > In general, there must be a zone KEY RR for the subzone in the > superzone and the copy signed in the superzone is controlling. > > which is wrong. The glue KEY RR is useless. See above. To securely permit the case of an insecure unmodified subzone, something that I think we have to allow for some time, the KEY RR in the superzone that securely states that the subzone is insecure is essential. > The following text of mine should be helpful to understand this > cryptographical issue: > > No NSIG records are provided for non-authoritative data for a zone > such as referral information. Thus, if a name server is > compromised or its IP address is used by an attacker, it is > possible to implant false referral information to a resolver. > > Still, as child zones have its own information, ZSIG (Zone > SIGnature) described later, to authenticate themselves, the > attacked resolver can detect that the referral information is > bogus. The result is no worse than a simple denial of service > attack by compromising name servers of the parent zone. That is, > it is not necessary nor meaningful to try to authenticate referral > NSes or glue A records for child zones. That's fine for NS and glue A. But the key information for a secure subzone must be signed by the superzone and the fact that an insecure subzone is insecure must be not only signed by the superzone but must also be present in the superzone, at least during the substantial transition period when there are many insecure umodified zones. > Masataka Ohta 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 From owner-dns-security Tue Nov 26 17:56:52 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA15256 for dns-security-outgoing; Tue, 26 Nov 1996 17:55:34 -0500 (EST) From: Masataka Ohta Message-Id: <199611262254.HAA09553@necom830.hpcl.titech.ac.jp> Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and To: dee@cybercash.com (Donald E. Eastlake 3rd) Date: Wed, 27 Nov 96 7:54:15 JST Cc: namedroppers@internic.net, dns-security@tis.com In-Reply-To: ; from "Donald E. Eastlake 3rd" at Nov 26, 96 2:30 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-dns-security@ex.tis.com Precedence: bulk Donald; > > The problem is that the delegation packets are already full of > > A and NS records. > > The rules are set up so that if the KEY/SIG don't fit in the additional info > section, they are dropped and you can get them with a separate retrieval. While you are wrong in several points, first of all, there is no such separate retrieval possible. Masataka Ohta From owner-dns-security Tue Nov 26 18:14:42 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA15292 for dns-security-outgoing; Tue, 26 Nov 1996 18:14:40 -0500 (EST) From: Masataka Ohta Message-Id: <199611262311.IAA09616@necom830.hpcl.titech.ac.jp> Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and To: lewis@tis.com (Edward Lewis) Date: Wed, 27 Nov 96 8:11:42 JST Cc: mohta@necom830.hpcl.titech.ac.jp, dee@cybercash.com, namedroppers@internic.net, dns-security@tis.com In-Reply-To: ; from "Edward Lewis" at Nov 26, 96 8:59 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-dns-security@ex.tis.com Precedence: bulk > > In general, there must be a zone KEY RR for the subzone in the > > superzone and the copy signed in the superzone is controlling. > > > > which is wrong. The glue KEY RR is useless. > > Not exactly useless - having information is never useless. Having informationless bunch of bytes is harmful. > > IMHO - and this is a very subtle point - is that the presence of the KEY > RR is not as security significant as the SIG RR that signs the KEY, which > is signed by the "superzone." Neither KEY nor SIG are necessary. > (What are NSIG's? SIGs over NS RRs?) Node SIGs. > Being able to avoid denial of service is not a reasonable expectation - being > able to detect and respond to them is. The resolver can become suspicious, > possibly resulting in an out of band call to the human running the zone > under attack... That's why neither KEY nor SIG are necessary. > > Still, as child zones have its own information, ZSIG (Zone > > SIGnature) described later, to authenticate themselves, the > > attacked resolver can detect that the referral information is > > bogus. The result is no worse than a simple denial of service > > attack by compromising name servers of the parent zone. That is, > > it is not necessary nor meaningful to try to authenticate referral > > NSes or glue A records for child zones. > > I'm sorry, I guess I don't understand your point. Are you arguing for or > against signing delegation point records? Against, of course. > You're last two paragraphs seem > to contradict each other. The forgery of glue is only as harmful as the no referral response. In both case, we can't reach the child zone. Masataka Ohta From owner-dns-security Tue Nov 26 18:41:17 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA15332 for dns-security-outgoing; Tue, 26 Nov 1996 18:41:05 -0500 (EST) From: Masataka Ohta Message-Id: <199611262342.IAA09749@necom830.hpcl.titech.ac.jp> Subject: RE: ZL's (was Re: DNSSEC and split ...) To: lewis@tis.com (Edward Lewis) Date: Wed, 27 Nov 96 8:41:47 JST Cc: mohta@necom830.hpcl.titech.ac.jp, dee@cybercash.com, namedroppers@internic.net, dns-security@tis.com In-Reply-To: ; from "Edward Lewis" at Nov 26, 96 11:57 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-dns-security@ex.tis.com Precedence: bulk > > While it possible, the result is boring. If you insist that I > > should, could you please do it with NXT first? I'm sorry but I found it impossible becasue your first example is invalid. > $ORIGIN zone. > $SIGNER zone. > @ SOA (SOA stuff) > NS (NS stuff) > KEY (KEY stuff) > d NS (NS stuff) > MX (MX stuff) > KEY (KEY stuff) The referral point "d", can not have MX. > (*) The only debateable item here is whether the MX record > for d.zone. should be in the zone.'s NXT record. There is no debatable item. Your example is simply wrong. The second one is: $ORIGIN d.zone. @ SOA (SOA stuff) NS (NS stuff) NS (NS stuff) x TXT (TXT stuff) w A (A stuff) y A (A stuff) $ORIGIN d.zone. @ SOA (SOA stuff) NS (NS stuff) NS (NS stuff) ZA (Zone Key) ZSIG(Signature by Parent) NSIG(Signature by d.zone.) RRD (SOA) RRD (NS) RRD (ZA) RRD (ZSIG) RRD (NSIG) RRD (RRD) ZL (ZL stuff) x TXT (TXT stuff) NSIG(Signature by d.zone.) RRD (TXT) RRD (RRD) w A (A stuff) NSIG(Signature by d.zone.) RRD (A) RRD (RRD) y A (A stuff) NSIG(Signature by d.zone.) RRD (A) RRD (RRD) Masataka Ohta From owner-dns-security Tue Nov 26 19:03:10 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA15366 for dns-security-outgoing; Tue, 26 Nov 1996 19:02:35 -0500 (EST) Date: Tue, 26 Nov 1996 19:05:44 -0500 (EST) From: Edward Lewis X-Sender: lewis@singsing.hq.tis.com To: Masataka Ohta cc: mohta@necom830.hpcl.titech.ac.jp, dee@cybercash.com, namedroppers@internic.net, dns-security@tis.com Subject: RE: ZL's (was Re: DNSSEC and split ...) In-Reply-To: <199611262342.IAA09749@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 On Wed, 27 Nov 1996, Masataka Ohta wrote: > > > While it possible, the result is boring. If you insist that I > > > should, could you please do it with NXT first? > > I'm sorry but I found it impossible becasue your first > example is invalid. > > > d NS (NS stuff) > > MX (MX stuff) > > KEY (KEY stuff) > > The referral point "d", can not have MX. Then omit the offending record and show me how your proposal works. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: 301-854-5794 Email: lewis@tis.com From owner-dns-security Wed Nov 27 07:32:05 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA16043 for dns-security-outgoing; Wed, 27 Nov 1996 07:30:57 -0500 (EST) Date: Wed, 27 Nov 1996 07:33:50 -0500 (EST) From: Edward Lewis X-Sender: lewis@singsing.hq.tis.com To: Masataka Ohta cc: mohta@necom830.hpcl.titech.ac.jp, dee@cybercash.com, namedroppers@internic.net, dns-security@tis.com Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and In-Reply-To: <199611262311.IAA09616@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 On Wed, 27 Nov 1996, Masataka Ohta wrote: > Having informationless bunch of bytes is harmful. Please go on. I don't think the correct A record for a/the nameserver of a delegation point is neither information-less, nor is having correct information harmful. > Neither KEY nor SIG are necessary. ... > That's why neither KEY nor SIG are necessary. Please explain. > In both case, we can't reach the child zone. How do you propose to fix this? The problem of lame delegations is a problem for all of DNS. DNSSEC cannot solve this problem, this is a problem larger than the scope of the DNS work. There are five threats to DNS operations even with DNSSEC. (I'm considering the concept here, not any implementation - bugs in which would probably cause more vulerabilities.) 1) the signature of the zone adminisitrator is forged This is not a problem for DNSSEC to solve. This is a problem for the crypto algorithm and the site policies on handling the keys. 2) the data entered by the zone admins up to the root is incorrect Human error cannot be completely removed, although it can be lessened through sanity checks. 3) the out-of-band coordination is not secured The passing of the unsigned zone key between zone administrators is an operations policy issue. Delegations themselves should only occur between consenting administrators. 4) the name servers are compromised via non-DNS means This is host security, and is addressed by at least one other draft (DNS server requirements). 5) data is retired prior to the expiration of the last TTL This is in the nature of DNS. DNSSEC could require all TTLs be set to 0, but that is unacceptable for performance reasons. Adding an expiration time to older RR's would end backwards compatibility. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: 301-854-5794 Email: lewis@tis.com From owner-dns-security Wed Nov 27 08:52:39 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA16552 for dns-security-outgoing; Wed, 27 Nov 1996 08:51:56 -0500 (EST) Date: Wed, 27 Nov 1996 08:54:55 -0500 (EST) From: Edward Lewis X-Sender: lewis@singsing.hq.tis.com To: Masataka Ohta cc: mohta@necom830.hpcl.titech.ac.jp, dee@cybercash.com, namedroppers@internic.net, dns-security@tis.com Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and In-Reply-To: <199611271328.WAA12110@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 I'm terribly confused. Are you typing "adding security to DNS is useless?" based on the lame delegation dilemma? Or are you saying that only a simple appraoch to DNSSEC should be persued? If that is so, why are you participating in this list? Why do you have an "alternative" proposal? (Which I still don't understand - the [completed] example will be a big help to me.) On the contrary... If you believe that adding security to DNS is useful, then how do you propose to signify a delegation of signing authority? Make it implicit in the delegation NS record? If so, are you implying that there shall be just one signer for each zone? Please help me understand your position. I know that there is some personal conflict here and my asking questions may seem like an arguement, but I am merely curious about your proposal. I appologize for having difficulty understanding your writing. It is unfortunate that I have not learned Japanese. On Wed, 27 Nov 1996, Masataka Ohta wrote: > Edward; > > The problem of denial of service attack related to lame delegation > is unsolvable. > > That is, it's wrong to to make secure DNS complex, trying to solve > the problem. > Masataka Ohta -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: 301-854-5794 Email: lewis@tis.com From owner-dns-security Wed Nov 27 09:01:24 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA16635 for dns-security-outgoing; Wed, 27 Nov 1996 09:01:23 -0500 (EST) From: Masataka Ohta Message-Id: <199611271328.WAA12110@necom830.hpcl.titech.ac.jp> Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and To: lewis@tis.com (Edward Lewis) Date: Wed, 27 Nov 96 22:28:04 JST Cc: mohta@necom830.hpcl.titech.ac.jp, dee@cybercash.com, namedroppers@internic.net, dns-security@tis.com In-Reply-To: ; X-Mailer: ELM [version 2.3 PL11] Sender: owner-dns-security@ex.tis.com Precedence: bulk Edward; > The problem of lame delegations is a problem for all of DNS. > DNSSEC cannot solve this problem, this is a problem larger > than the scope of the DNS work. The problem of denial of service attack related to lame delegation is unsolvable. That is, it's wrong to to make secure DNS complex, trying to solve the problem. > > That's why neither KEY nor SIG are necessary. > > Please explain. See above. You explained by yourself. Masataka Ohta From owner-dns-security Wed Nov 27 09:05:37 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA16661 for dns-security-outgoing; Wed, 27 Nov 1996 09:05:35 -0500 (EST) From: Masataka Ohta Message-Id: <199611271406.XAA12222@necom830.hpcl.titech.ac.jp> Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and To: lewis@tis.com (Edward Lewis) Date: Wed, 27 Nov 96 23:05:56 JST Cc: mohta@necom830.hpcl.titech.ac.jp, dee@cybercash.com, namedroppers@internic.net, dns-security@tis.com In-Reply-To: ; from "Edward Lewis" at Nov 27, 96 8:54 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-dns-security@ex.tis.com Precedence: bulk Edward; > I'm terribly confused. You are. > Are you typing "adding security > to DNS is useless?" No. I typed: That is, it's wrong to to make secure DNS complex, trying to solve the problem. > Or are you saying that only a simple appraoch to DNSSEC > should be persued? As you can see. > Why do you have an "alternative" proposal? The title of my ID is "Simple Secure DNS". > If you believe that adding security to DNS is useful, then > how do you propose to signify a delegation of signing > authority? Hint: I never tried to solve the lame delegation dilemma. But, actually, I have already shown you the answer with ZA RR in child zone. So, why do you think you need additional boring example? Masataka Ohta From owner-dns-security Wed Nov 27 09:24:14 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA16714 for dns-security-outgoing; Wed, 27 Nov 1996 09:24:12 -0500 (EST) Date: Wed, 27 Nov 1996 09:27:01 -0500 (EST) From: Edward Lewis X-Sender: lewis@singsing.hq.tis.com To: Masataka Ohta cc: mohta@necom830.hpcl.titech.ac.jp, dee@cybercash.com, namedroppers@internic.net, dns-security@tis.com Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and In-Reply-To: <199611271406.XAA12222@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 On Wed, 27 Nov 1996, Masataka Ohta wrote: > > I'm terribly confused. > You are. If you understand that, then enlighten me. Insults get me nowhere. > As you can see. As I can see what? I am having trouble with your writing, I am verifying your comments so that I don't misinterpret you as I did when comparing your ZL to NXT's. > > Why do you have an "alternative" proposal? > The title of my ID is "Simple Secure DNS". I asked "why" not "what." And remember, I am new to this. I cannot find this ID. You've not given me any evidence that your approach is better or significantly different from the current approach. > Hint: I never tried to solve the lame delegation dilemma. > > But, actually, I have already shown you the answer with ZA RR > in child zone. There was no lame delegation in the example, just a loose MX record. Is that what you mean by a lame delegation? I interpret "lame delegation" as being an incorrect NS record. If your approach doesn't handle lame delgations, why did you critisize DNSSEC for not handling it? > So, why do you think you need additional boring example? I would like to see the whole answer so I can judge for myself. I would like to see how you handle the delegation point and the multiple RR's in a set. Besides, I took the time to show my completed response. Please be fair. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: 301-854-5794 Email: lewis@tis.com