From owner-namedroppers@ops.ietf.org Thu Apr 6 14:53:33 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12862 for ; Thu, 6 Apr 2000 14:53:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12dEeM-0009T1-00 for namedroppers-data@psg.com; Thu, 06 Apr 2000 08:56:54 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12dEeM-0009Sv-00 for namedroppers@ops.ietf.org; Thu, 06 Apr 2000 08:56:54 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12dEeL-0008wN-00 for namedroppers@ops.ietf.org; Thu, 06 Apr 2000 08:56:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200004061549.IAA24847@sh.lh.vix.com> To: Roy Arends cc: DNSEXT WG Mailing list Subject: Re: dnssec: super/subzone NULL keys In-reply-to: Your message of "Thu, 06 Apr 2000 14:28:57 +0200." Date: Thu, 06 Apr 2000 08:49:57 -0700 From: Jerry Scharf Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In the latest rev of secure DNS, the the delegation logic was changed such that the parent is no longer reqiured to keep the key for the child if the child is secure. So if you find a parent zone running secure and no null key, you have to go to the child's NS list and ask for the keys if they don't come in the authority section of a query. There were strong operational drives to get the live keys out of the parent zone. Since the null key is an explicit statement that the zone is not secured, your solution seems to create a level of ambiguiry. I would fear that could cause too many implementation depenent actions. jerry to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Apr 6 14:53:35 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12879 for ; Thu, 6 Apr 2000 14:53:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12dEE7-0009Cd-00 for namedroppers-data@psg.com; Thu, 06 Apr 2000 08:29:47 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12dEE6-0009CX-00 for namedroppers@ops.ietf.org; Thu, 06 Apr 2000 08:29:46 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12dEE6-0008oR-00 for namedroppers@ops.ietf.org; Thu, 06 Apr 2000 08:29:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Roy Arends Cc: DNSEXT WG Mailing list Subject: Re: dnssec: super/subzone NULL keys In-Reply-To: Your message of "Thu, 06 Apr 2000 14:28:57 +0200." Date: Fri, 07 Apr 2000 01:27:55 +1000 Message-Id: <7610.955034875@munnari.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Thu, 6 Apr 2000 14:28:57 +0200 (CEST) From: Roy Arends Message-ID: | a null-key for allmost every single delegation (at first, most delegated | zones will not be secure), a wild-card null key (* KEY 49408 3 3) can be | added, making the zone less redundant. No it can't, wildcards don't work like that. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Apr 6 15:41:07 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13787 for ; Thu, 6 Apr 2000 15:41:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12dHWC-000BOt-00 for namedroppers-data@psg.com; Thu, 06 Apr 2000 12:00:40 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12dHWC-000BOn-00 for namedroppers@ops.ietf.org; Thu, 06 Apr 2000 12:00:40 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12dHWC-0009vv-00 for namedroppers@ops.ietf.org; Thu, 06 Apr 2000 12:00:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: Date: Thu, 6 Apr 2000 15:00:44 -0400 To: Roy Arends From: Edward Lewis Subject: Re: dnssec: super/subzone NULL keys Cc: DNSEXT WG Mailing list Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 8:28 AM -0400 4/6/00, Roy Arends wrote: >in its parent. Is there any problem for this superzone to keep the null >key in its zone ? Robert is right, wildcards don't work that way. Jerry's point ("a level of ambiguity") is good too - the first thing I want in security is to make sure I am not "confused" by the data. Also, see and please comment on this draft: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-zone-status-00.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "Trying is the first step to failure." - Homer Simpson "No! Try not. Do... or do not. There is no try." - Yoda "It takes years of training to know when to do nothing" - Dogbert 1/21/00 Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Apr 7 21:20:50 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22236 for ; Fri, 7 Apr 2000 21:20:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12djEH-000NqO-00 for namedroppers-data@psg.com; Fri, 07 Apr 2000 17:36:01 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.12 #1) id 12djEG-000NqI-00 for namedroppers@ops.ietf.org; Fri, 07 Apr 2000 17:36:01 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12djEE-0000eU-00 for namedroppers@ops.ietf.org; Fri, 07 Apr 2000 17:35:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38EE60D9.7C77A4C2@ehsco.com> Date: Fri, 07 Apr 2000 15:27:37 -0700 From: "Eric A. Hall" To: namedroppers Subject: chapter and verse: unknown type Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I'm looking for an explicit chapter and verse citation on the standard behavior for the proper handling of an unknown resource record. IE, if a client issues a query for some newly-defined type code 99, what is the exact specific behavior that a server which is unaware of this code should exhibit? Since there is probably a formatting rule associated with the type, it can't just try to process it. Similarly, if a client receives a response message with an unknown code 99, what is it supposed to do? Simply discarding the unknown code could be dangerous since it may have some relevant impact on some other piece of data. I've looked through the various RFCs, but I may have missed it. If anybody knows the relevant citation section off the top of their heads I'd appreciate a clue. Thanks -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Apr 8 10:47:02 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11121 for ; Sat, 8 Apr 2000 10:47:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12dvxy-00038y-00 for namedroppers-data@psg.com; Sat, 08 Apr 2000 07:12:02 -0700 Received: from [206.163.43.51] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.12 #1) id 12dvxw-00038s-00 for namedroppers@ops.ietf.org; Sat, 08 Apr 2000 07:12:00 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12dvy2-0000jH-00 for namedroppers@ops.ietf.org; Sat, 08 Apr 2000 07:12:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: "Eric A. Hall" Cc: namedroppers Subject: Re: chapter and verse: unknown type In-Reply-To: Your message of "Fri, 07 Apr 2000 15:27:37 MST." <38EE60D9.7C77A4C2@ehsco.com> Date: Sat, 08 Apr 2000 18:38:14 +1000 Message-Id: <20478.955183094@munnari.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Fri, 07 Apr 2000 15:27:37 -0700 From: "Eric A. Hall" Message-ID: <38EE60D9.7C77A4C2@ehsco.com> | IE, if a | client issues a query for some newly-defined type code 99, what is the | exact specific behavior that a server which is unaware of this code | should exhibit? It depends what role the server plays. For an authoritative server for the domain queried, it should just return a NXDOMAIN or "no error no data" response, depending upon whether the name exists or not. By definition, if an authoritatve server for a domain has neevr heard of a RR type, there cannot be any data of that type associated with the record. A caching (non-authoritative) server should just forward the query to an authoritative server, and then forward the answer it obtains back to the client. In theory it ought be able to also cache the answer, and then return it again in response to later queries, but as there has been a tendancy to do domain name compaction in newly defined RRs that turns out to be a dangerous thing to do. Probably now, assuming that the server knows all the current record types, it could almost cache the result, as we (the people who invent new RR types) have mostly come to understand that compressed domain names cannot be used, or not without explicit confirmation from the client (or cache) that it understands the type and can handle compression. | Since there is probably a formatting rule associated | with the type, it can't just try to process it. For an authoritative server, which is all where that would be relevant, this makes little sense - if the server has been told that data exists for the type, it must also have been told how to represent the data. If a server were to receive a DNS update packet containing an unknown type, it should probably just store the data as it received it, though I would also expect that local server policy might have a switch to specify whether or not certain record types can be updated, and "unknown types" should be one of those (so servers that aren't expecting to get new types will just refuse to accept any nonsense clients might be tempted to send). | Similarly, if a client receives a response message with an unknown code | 99, what is it supposed to do? Ignore it. Clearly the client didn't ask for the unknown type (or it could hardly be called unknown). | Simply discarding the unknown code could | be dangerous since it may have some relevant impact on some other piece | of data. If we ever define new RR types in such a way that older RR types can have their meaning altered in any way by the new one, then we will have totally failed the community. That would be a ludicrous thing to do. Similarly a client which implemented one RR type, but not another, where it was already defined that the other might have some impact on the first, is simply broken, and deserves to suffer whatever danger comes its way. An example of that wold be a client that didn't bother to understand CNAME records - when requesting an A record, it might get a CNAME returned, and an A record for the canonical name. If it fails to understand CNAME, it is going to break badly - but it deserves to. A common example of just this happening (not badly defined RR types, or badly designed clients, I mean RR types unknown to the client being returned) is SIG records. We expect that as DNSSEC is deployed amongst servers, and more and more zones are signed, than clients will start receiving answers with accompanying SIG records attached - we expect that clients that don't understand DNSSEC (all of them I think at the minute) will simply ignore the SIG record. If we could not count upon that, we would never be able to deploy any new RR type that could ever be returned without being explicitly requested. | I've looked through the various RFCs, but I may have missed it. If | anybody knows the relevant citation section off the top of their heads | I'd appreciate a clue. I didn't go looking, but I don't recall anything which explicitly states any of this, most of it is just sort of obvious... kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Apr 8 10:51:04 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11136 for ; Sat, 8 Apr 2000 10:51:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12dvu9-00036i-00 for namedroppers-data@psg.com; Sat, 08 Apr 2000 07:08:05 -0700 Received: from [206.163.43.51] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.12 #1) id 12dvu7-00036c-00 for namedroppers@ops.ietf.org; Sat, 08 Apr 2000 07:08:04 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12dvuC-0000iz-00 for namedroppers@ops.ietf.org; Sat, 08 Apr 2000 07:08:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200004080536.PAA25915@bsdi.dv.isc.org> To: "Eric A. Hall" Cc: namedroppers From: Mark.Andrews@nominum.com Subject: Re: chapter and verse: unknown type In-reply-to: Your message of "Fri, 07 Apr 2000 15:27:37 MST." <38EE60D9.7C77A4C2@ehsco.com> Date: Sat, 08 Apr 2000 15:36:40 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit You treat it as opaque data. This is one of the reasons why new RRs are not allowed to use compression pointers so that the servers that don't know the contents don't need to look inside the RR data to cache and retransmit it. DNSSEC has made this a little bit harder in that you need to originally transmit the RR with domain names within the RR data downcased so that you can verify the signatures. If we had been thinking correctly when DNSSEC was written we should have been only case folded domain names in the well known RR types as servers are supposed to preserve the case of domain names if possible. The only reason for case changing today is as the result of using compression pointers and as new RR types don't have compression pointers it is easy to preserve case in the data sections. In fact you have to go out of your way to change it. I can't remember if this was discussed in the early DNSSEC discussions or not but *not* downcasing domains in the data sections of *new* RR types when signing would solve some existing issues. Mark > I'm looking for an explicit chapter and verse citation on the standard > behavior for the proper handling of an unknown resource record. IE, if a > client issues a query for some newly-defined type code 99, what is the > exact specific behavior that a server which is unaware of this code > should exhibit? Since there is probably a formatting rule associated > with the type, it can't just try to process it. > > Similarly, if a client receives a response message with an unknown code > 99, what is it supposed to do? Simply discarding the unknown code could > be dangerous since it may have some relevant impact on some other piece > of data. > > I've looked through the various RFCs, but I may have missed it. If > anybody knows the relevant citation section off the top of their heads > I'd appreciate a clue. > > Thanks > > -- > Eric A. Hall ehall@ehsco.com > +1-650-685-0557 http://www.ehsco.com > > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. -- Mark Andrews, Nominum Inc. / Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Apr 8 23:15:47 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22269 for ; Sat, 8 Apr 2000 23:15:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12e7Oy-000G6o-00 for namedroppers-data@psg.com; Sat, 08 Apr 2000 19:24:40 -0700 Received: from [206.163.43.51] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.12 #1) id 12e7Ox-000G6f-00 for namedroppers@ops.ietf.org; Sat, 08 Apr 2000 19:24:40 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12e7P9-0000n8-00 for namedroppers@ops.ietf.org; Sat, 08 Apr 2000 19:24:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38EF99C7.D7B178C0@ehsco.com> Date: Sat, 08 Apr 2000 13:42:48 -0700 From: "Eric A. Hall" To: namedroppers Subject: Re: chapter and verse: unknown type References: <20478.955183094@munnari.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Thanks for the comprehensive responses. > I didn't go looking, but I don't recall anything which explicitly > states any of this, most of it is just sort of obvious... Most of the protocols that use options or codes explicitly state that unknown types must be ingored, or prescribe some other form of behavior like returning an explicit error. There doesn't appear to be a definitive statement on the behavior for DNS, which is what I was looking for, although the detailed responses are also appreciated. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 10 00:27:05 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19465 for ; Mon, 10 Apr 2000 00:27:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12eUpq-00098F-00 for namedroppers-data@psg.com; Sun, 09 Apr 2000 20:25:58 -0700 Received: from roam.psg.com ([147.28.0.38]) by psg.com with esmtp (Exim 3.12 #1) id 12eUpp-000989-00 for namedroppers@ops.ietf.org; Sun, 09 Apr 2000 20:25:57 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12eUpq-0000sI-00 for namedroppers@ops.ietf.org; Sun, 09 Apr 2000 20:25:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200004092120.RAA01630@torque.pothole.com> To: Olafur Gudmundsson cc: DNSEXT WG Mailing list Subject: Re: DNSEXT WGLC Summary: TKEY-01 In-reply-to: Your message of "Wed, 22 Mar 2000 10:25:58 EST." <4.1.20000322100521.00a68b70@sentry.gw.tislabs.com> Date: Sun, 09 Apr 2000 17:20:23 -0400 From: "Donald E. Eastlake 3rd" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I've updated the draft and submitted it to internet-drafts. The announcement should be out in a few days. Thanks, Donald From: Olafur Gudmundsson Message-Id: <4.1.20000322100521.00a68b70@sentry.gw.tislabs.com> Date: Wed, 22 Mar 2000 10:25:58 -0500 To: DNSEXT WG Mailing list >The WGLC period has concluded: >Two issues where raised in the last call: >1. Unspecified error case, >2. The Sporadic Server assignment can be restricted to Delete only. > >The Sporadic Server inclusion of new key was included for GSS-API key >exchange but the implementors of that algorithm stated that there is no >need for this. > >Donald please update document to reflect the WG consensuses. > >It is the sense of the WG that the document is ready for advancement >and will be forwarded to IESG after update as a standards track document. > >There will be an opportunity to address the WG last call of this >document in Working Group meeting in Adelaide. > > >> This is a last call on this document, TKEY defines a DNS protocol >> mechanism to allow two DNS entities to create a shared secret to be >> used by TSIG for message authentication. >> The document defines two mandatory modes to implement and few optional >> ones. >> This is a WG last call ending March 20'th 2000. >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tkey-01.txt to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 10 01:31:14 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23406 for ; Mon, 10 Apr 2000 01:31:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12eW3u-00008c-00 for namedroppers-data@psg.com; Sun, 09 Apr 2000 21:44:34 -0700 Received: from roam.psg.com ([147.28.0.38]) by psg.com with esmtp (Exim 3.12 #1) id 12eUpp-000989-00 for namedroppers@ops.ietf.org; Sun, 09 Apr 2000 20:25:57 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12eUpq-0000sI-00 for namedroppers@ops.ietf.org; Sun, 09 Apr 2000 20:25:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200004092120.RAA01630@torque.pothole.com> To: Olafur Gudmundsson cc: DNSEXT WG Mailing list Subject: Re: DNSEXT WGLC Summary: TKEY-01 In-reply-to: Your message of "Wed, 22 Mar 2000 10:25:58 EST." <4.1.20000322100521.00a68b70@sentry.gw.tislabs.com> Date: Sun, 09 Apr 2000 17:20:23 -0400 From: "Donald E. Eastlake 3rd" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I've updated the draft and submitted it to internet-drafts. The announcement should be out in a few days. Thanks, Donald From: Olafur Gudmundsson Message-Id: <4.1.20000322100521.00a68b70@sentry.gw.tislabs.com> Date: Wed, 22 Mar 2000 10:25:58 -0500 To: DNSEXT WG Mailing list >The WGLC period has concluded: >Two issues where raised in the last call: >1. Unspecified error case, >2. The Sporadic Server assignment can be restricted to Delete only. > >The Sporadic Server inclusion of new key was included for GSS-API key >exchange but the implementors of that algorithm stated that there is no >need for this. > >Donald please update document to reflect the WG consensuses. > >It is the sense of the WG that the document is ready for advancement >and will be forwarded to IESG after update as a standards track document. > >There will be an opportunity to address the WG last call of this >document in Working Group meeting in Adelaide. > > >> This is a last call on this document, TKEY defines a DNS protocol >> mechanism to allow two DNS entities to create a shared secret to be >> used by TSIG for message authentication. >> The document defines two mandatory modes to implement and few optional >> ones. >> This is a WG last call ending March 20'th 2000. >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tkey-01.txt to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 10 11:49:08 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19298 for ; Mon, 10 Apr 2000 11:49:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12efaa-0004UT-00 for namedroppers-data@psg.com; Mon, 10 Apr 2000 07:54:56 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12efaZ-0004UN-00 for namedroppers@ops.ietf.org; Mon, 10 Apr 2000 07:54:55 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12efaZ-000AgT-00 for namedroppers@ops.ietf.org; Mon, 10 Apr 2000 07:54:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: Date: Mon, 10 Apr 2000 10:48:55 -0400 To: DNSEXT WG Mailing list From: Edward Lewis Subject: Zone security status draft Cc: lewis@tislabs.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Comments on the slides Olafur used in Adelaide, and the reported discussion that followed: 0) My email is lewis@, not elewis@... 1) The term "privately secure" was not my choice either. I had preferred "partially secure" but was coerced out of it when the draft was internally discussed. The issue here is terminology. In defining the stages at which a zone admin can set up their zone, a zone could be configured to be as secure as can be, as secure as the admin wants it, or unsecured. Keep in mind that security of a zone is really in the eye of the resolver. Still, I want to define a guidance for server admins, so I chose terms assuming the "canonical secure resolver," i.e., one that uses the DNS tree as an authorization-to-sign tree and isn't very liberal in trust. Fully secure is meant to define a zone that is pristine in the ways of security and interoperability, going as far as using just the mandatory-to-implement crypto algorithms. At the other extreme end of the scale is unsecured, meaning that the admin is essentially running DNS as it is now. In between is a significant situation in which an admin applies all the rules, but uses a crypto algorithm that is not mandatory to implmement in the spec (e.g., RSA/MD5) or uses a non-parent signer to back the zone. The term in the draft is "private," but I prefer "partial" as the zone is seen as secure by a partial audience - only those understanding the protocol or authorizing the non-parent signer to back the key's validity. So, the issue before the group - given that "private" isn't a good term to use in this context? I am open to suggestions. 2) The draft talks terminology and also introduces a new way to signify the status of a child zone. Should this draft be split into two? There is time pressure due to BIND 9's release in the near future to have this solid soon, leaving the two issues together might drag this out. On the other hand, the two issues are interrelated, and there would be an editing delay in trying to split the document. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "Trying is the first step to failure." - Homer Simpson "No! Try not. Do... or do not. There is no try." - Yoda "It takes years of training to know when to do nothing" - Dogbert 1/21/00 Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 10 12:26:34 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22601 for ; Mon, 10 Apr 2000 12:26:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12eg31-0004oi-00 for namedroppers-data@psg.com; Mon, 10 Apr 2000 08:24:19 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12eg31-0004oc-00 for namedroppers@ops.ietf.org; Mon, 10 Apr 2000 08:24:19 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12eg30-000AqB-00 for namedroppers@ops.ietf.org; Mon, 10 Apr 2000 08:24:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200004101522.LAA03106@torque.pothole.com> To: Olafur Gudmundsson cc: DNSEXT WG Mailing list Subject: Re: DNSEXT WGLC Summary: SIG(0) In-reply-to: Your message of "Wed, 22 Mar 2000 10:35:26 EST." <4.1.20000322095037.06aab310@sentry.gw.tislabs.com> Date: Mon, 10 Apr 2000 11:22:49 -0400 From: "Donald E. Eastlake 3rd" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I've edited and submitted the document as per WG consensus so it should be announced in a few days. However, I did have one techncial comment below... From: Olafur Gudmundsson Message-Id: <4.1.20000322095037.06aab310@sentry.gw.tislabs.com> Date: Wed, 22 Mar 2000 10:35:26 -0500 To: DNSEXT WG Mailing list >The last call period on this document has concluded. > >Only one issue was raised during the WGLC period. Currently the draft >allows multiple SIG(0)'s to be attached to a message. There where calls >to restrict this to one SIG(0) per message. The consensus of the >Working group is that SIG(0) MUST be restricted to one. >The arguments against this restriction where: >1. The client does not know what algorithm the server supports >2. Allow Multiple Inheritance of capabilities to a key generated in a >TKEY exchange. > >The working group rejects the first one as the client can query the server >for its appropriate key set and use that to select one of clients key to >sign message. I don't see how that would work. The question is what algorithms are actually supported by the DNS server code at the server. This does not have any necessary relation to any TKEY RRset anywhere. Zones can be signed with any variety of algorithms even if none of the DNS servers for that zone are security aware. KEY RRs that specify the DNS or ANY protocol stored under a server name probably reflect algorithms supported by that server but there could easily be no such KEYs. And how can you find all of the names for a server? Even if you had all of its IP addresses, you would have to do an inverse lookup throughout the entire DNS for those addresses to find all the domain names for a server... However, I think that implementation of and configuration of private keys for more than two or occasionally three algorithms will be very unusual so it is practical for the client to just try the few algorithm possibilities successively. And in many cases there will be some relationship between the client and server such that the client can be configured to use the "right" protocol... >About the second argument there was some discussion on if this is a good >idea but because the rules governing how inheritance of capabilities is >NOT defined yet, the working group consensus is that this is better >to not address at this time but this issue can be revisited later in >a separate document. > >No other substantial comments where received during the last call. > >Donald please update document to reflect the WG consensus. > >It is the sense of the WG that the document is ready for advancement >and will be forwarded to IESG after update. > >There will be an opportunity to address the WG last call of this >document in Working Group meeting in Adelaide. > >Olafur > > >>This is a last call on this document, SIG(0) updates RFC2535 in >>the definition of transaction signatures. The changes are mostly >>to make SIG(0) more like TSIG in implementation and result of >>implementation experience. >>SIG(0) is required for TKEY exchange when no existing shared secret >>between two DNS entities exist. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 10 12:29:50 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22833 for ; Mon, 10 Apr 2000 12:29:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12egF1-0004yL-00 for namedroppers-data@psg.com; Mon, 10 Apr 2000 08:36:43 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12egF1-0004yF-00 for namedroppers@ops.ietf.org; Mon, 10 Apr 2000 08:36:43 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12egF0-000AuB-00 for namedroppers@ops.ietf.org; Mon, 10 Apr 2000 08:36:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200004101536.LAA03119@torque.pothole.com> To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WG Last Call: SIG(0) In-reply-to: Your message of "Wed, 08 Mar 2000 09:31:29 PST." <38C68E71.C94A1A90@whistle.com> Date: Mon, 10 Apr 2000 11:36:10 -0400 From: "Donald E. Eastlake 3rd" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit From: Terry Lambert Message-ID: <38C68E71.C94A1A90@whistle.com> Date: Wed, 08 Mar 2000 09:31:29 -0800 To: Brian Wellington CC: "Donald E. Eastlake 3rd" , Olafur Gudmundsson , namedroppers@ops.ietf.org References: >Brian Wellington wrote: >> On Tue, 7 Mar 2000, Donald E. Eastlake 3rd wrote: >> >> > Actually, although multiple different authorization was the only >> > reason I mentioned when we last talked about this, there is another. >> >> OK. My primary concern is that situations involving multiple >> authorizations don't arise. Restricting it in SIG(0) seesed like the >> logical choice, but maybe not. > > >I think the key jitter argument is specious; I personally >use SecurID, from Security Dynamics, to get behind an IBM >firewall. This works by generating pseudo-random numbers, >and providing a window for "jitter" to deal with the clock >synchronization issue for the pseudo-random number (e.g., >the number is valid for ~3x the window, and the back end is >synchronized ("recentered") on the middle of the window for >a valid number. I also have a SecurID, although in my case it is for getting behind a Motorola firewall. However, that has nothing to do with the SIG(0) key rollover case. SecurIDs display a keyed function of time and do not do any key rollover. In the case of real key rollover, you either have to try multiple private keys at the signer or be able to try multiple public keys at the verifier. And, in fact, multiple public keys can be configured and multiple private keys can be tried successively, even when multiple signatures are not allowed in one message. >This argument is specious for automatic systems, since >there are no automatic systems that implement this (the >SecurID system is to permit people with keychain fobs >and an account and PIN to login from outside, not one >machine with magic client hardware to talk to another >with magic server hardware; I also think that permitting >the implementation of a "standards conforming" system >that is nevertheless non-interoperable with other >instances of "standards conforming" systems is an extreme >error, and points up an obvious flaw in the standards >document, if it is even theoretically possible to create >such an implementation). We are talking about configuration here. In IETF security protocols, the norm is to have mandatory to implement algorithms which will allow parties to interoperate if those algorithms are enabled, proper keys are configured, etc. But it is entirely permissable to implement optional algorithms from the standard or proprietary algorithms and it is permissable to operate with the mandatory to implement algorithms disabled or with no interoperable keys configured for them, etc. For example, in TKEY, you can have Diffie-Hellman (DH), the mandatory algorithm, implemented and enabled at both ends and DH keys configured at both ends but if they are not compatible (same modulus, etc.), then you can't use them to negotiate a shared secret key. But forcing everyone to use compatible keys makes that modulus a much more tempting target for attackers and if it were broken you would lose all security... Requiring all parties to not just implement but also enable and configure interoperably keys for the one or occasionally two mandatory algorithms has been viewed as unrealistic and insecure by causing excessive reliance on and great difficulty in changing from the mandatory algorithm. >It seems to me that the "jitter" argument is an attempt to >dodge the key distribution problem, which I believe has >already been adequately resolved elsewhere (e.g. "Racoon" >for IPv6), and we can look elsewhere for a model. DNSSEC is a key distribution system. All systems with real key rollover potentially have this problem. If you are, for eample, X.509 certificate based, you have questions about time synchronization, verifying old signatures, how many keys are valid at any one time, etc. These are all soluble, for X.509 certs as well as for DNSSEC, by generally having only one private key you are signing with at any particular time but being able to verify signatures by the current and previous and/or future key (s). In DNSSEC this can be accomplished by having multiple KEY RRs if you are near a rollover. >For the non-"jitter" argument of multiple algorithms, I >think that if a client has an unsupported algorithm, then >it should attempt it, and if the server does not accept >it, then the client MUST fall back to a supported (e.g. a >"mandatory to implement") algorithm. > >I use the word "MUST" intentionally, in its RFC sense. We are talking about signatures (SIG(0) RRs) by one party to be verified by the other. The signing party can only sign with private keys it has configured. If those include multiple algorithms and it wants to maximize the chance of success, it should have some policy for trying them one at a time. If no private key is available for a mandatory algorithm, it can't use it. The IETF certainly has the power to make its protocols such that interoperability is possible/easy/prefered. But if people don't want to interoperate, I don't think "orders" from the IETF are going to make them configure their systems interoperably. >Right now, we are beset with attempts to control the >client, the server, or both sides of the implementation >of supposedly standard security protocols, sometimes in >the face of white papers by the authors of the standards >specifically stating the intended use of "optional" fields, >such as we are talking about in this specific case. What optional fields in SIG(0)? What white papers about SIG(0) use? I am not aware of any... >What is to stop a vendor from implementing a signature >security algorithm that is proprietary and/or patented, >and then setting up their servers to require the use of >their signatures, thus leveraging a near monopoly in >clients to force the use of their servers? The US Departmet of Justice? :-) >Or vice-versa, what is to stop someone from implementing >a server which understands such an algorithm, and treats >clients which only implement the "mandatory to implement" >algorithms as second class citizens in "their" network? The Internet only works because people find it to their advantage to be able to interoperate. If, say, NSA want to use some proprietary algorithm to secure their DNS zones and not sign them with mandatory algorithms, that's their decision. Most of the Internet, which does not have this hypothetcial NSA proprietary algorithm implemented, will treat their zones as Insecure and crackers will be able to spoof their DNS data. It would be their choice. >It is not strong enough to permit optional algorithms, >we MUST ensure that the "mandatory to implement" ones >are universal, and that implementations which _only_ >support these CAN NOT be treated as second class network >citizens as a result of a vendor whim. > >The RFC SHOULD NOT be issued until interoperability >guarantees have been addressed in the protocol definition. Your position does not appear to me or, apparently, to the chair to be the working group consensus and it is inconsistent with what the IETF has done in IPSEC and other security areas. >-- Terry Lambert >-- Whistle Communications, Inc., an I.B.M. Company >-- terry@whistle.com >------------------------------------------------------------------- >This is formal notice under California Assembly Bill 1629, enacted >9/26/98 that any UCE sent to my email address will be billed $50 >per incident to the legally allowed maximum of $25,000. Donald =================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 65 Shindegan Hill Rd, RR#1 lde008@dma.isg.mot.com Carmel, NY 10512 USA +1 914-276-2668(h) +1 508-261-5434(w) to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 10 16:50:55 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04028 for ; Mon, 10 Apr 2000 16:50:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12ekUl-0007gC-00 for namedroppers-data@psg.com; Mon, 10 Apr 2000 13:09:15 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12ekUl-0007g6-00 for namedroppers@ops.ietf.org; Mon, 10 Apr 2000 13:09:15 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12ekUl-000ChA-00 for namedroppers@ops.ietf.org; Mon, 10 Apr 2000 13:09:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: Date: Mon, 10 Apr 2000 16:04:39 -0400 To: DNSEXT WG Mailing list From: Edward Lewis Subject: Zone secure bit Cc: lewis@tislabs.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I am rewriting a draft on zone's security status and have a question for which I'd like some feedback. Without going into gory details and special cases, which is preferred: 1) A proposal to use the KEY RR bit in a delegation points upper NXT to signify a signed child zone key and to do away with the use NULL keys altogher. E.g., if the child's zone key has been signed by the parent, the bit is on, the child's key is optionally held by the parent (recommendation is not to). If there is no signed zone key for the the child, the bit is zero, and neither the parent nor child holds a signed NULL key. In this case, the KEY RR bit in the upper NXT signifies whether or not the zone is secured. 2) The previous proposal plus the option that the parent may choose to hold and sign a NULL key for an unsigned child. In this case, the KEY RR bit in the upper NXT signifies that "there is a key for the child somewhere." 3) No changes to 2535. Case #1 is cleaner than case #2, but case #2 offers backwards compatibility to the early DNSSEC software. Case #3 is offered to those who don't agree with any of this. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "Trying is the first step to failure." - Homer Simpson "No! Try not. Do... or do not. There is no try." - Yoda "It takes years of training to know when to do nothing" - Dogbert 1/21/00 Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 10 18:02:05 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05607 for ; Mon, 10 Apr 2000 18:02:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12elfQ-0008fZ-00 for namedroppers-data@psg.com; Mon, 10 Apr 2000 14:24:20 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12elfP-0008fS-00 for namedroppers@ops.ietf.org; Mon, 10 Apr 2000 14:24:19 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12elfP-0000Jz-00 for namedroppers@ops.ietf.org; Mon, 10 Apr 2000 14:24:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 10 Apr 2000 17:19:42 -0400 (EDT) From: Brian Wellington To: Edward Lewis cc: DNSEXT WG Mailing list Subject: Re: Zone secure bit In-Reply-To: Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 10 Apr 2000, Edward Lewis wrote: > I am rewriting a draft on zone's security status and have a question for > which I'd like some feedback. Without going into gory details and special > cases, which is preferred: > > 1) A proposal to use the KEY RR bit in a delegation points upper NXT to > signify a signed child zone key and to do away with the use NULL keys > altogher. E.g., if the child's zone key has been signed by the parent, the > bit is on, the child's key is optionally held by the parent (recommendation > is not to). If there is no signed zone key for the the child, the bit is > zero, and neither the parent nor child holds a signed NULL key. In this > case, the KEY RR bit in the upper NXT signifies whether or not the zone is > secured. > > 2) The previous proposal plus the option that the parent may choose to hold > and sign a NULL key for an unsigned child. In this case, the KEY RR bit in > the upper NXT signifies that "there is a key for the child somewhere." I agree with #2, with a small modification - the KEY RR bit signifies that the parent has signed a KEY set for the child. There's no reason for the parent to insert a NULL key for an unsigned child, since if a resolver obtains (and verifies) the child's KEY set, it can easily notice if there is no zone key present and determine that the zone is not signed. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Apr 11 12:06:58 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10787 for ; Tue, 11 Apr 2000 12:06:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12f2M3-000H5o-00 for namedroppers-data@psg.com; Tue, 11 Apr 2000 08:13:27 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12f2M3-000H5i-00 for namedroppers@ops.ietf.org; Tue, 11 Apr 2000 08:13:27 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12f2M2-0005Hl-00 for namedroppers@ops.ietf.org; Tue, 11 Apr 2000 08:13:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.1.2.20000411083909.10cc7ee0@dokka.kvatro.no> Date: Tue, 11 Apr 2000 08:43:31 +0200 To: Edward Lewis , DNSEXT WG Mailing list From: Harald Tveit Alvestrand Subject: Re: Zone secure bit Cc: lewis@tislabs.com In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit One of my fundamental gripes with NXT is the fact that we've now enshrined a situation where there are 2 records that say "name NXT bitmap name", where BOTH are "valid", they are NOT part of the same RR set, and they live on different servers, but the caches aren't smart enough to know which to cache, so you have to do special gymnosophistry to get the "right" one. Having the security status interpretation depend on this ugliness seems to me to be a considerably less elegant "solution" than the NULL KEY record. My vote for #3. Harald -- Harald Tveit Alvestrand, EDB Maxware, Norway Harald.Alvestrand@edb.maxware.no to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Apr 11 12:11:46 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10949 for ; Tue, 11 Apr 2000 12:11:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12f2YS-000HDH-00 for namedroppers-data@psg.com; Tue, 11 Apr 2000 08:26:16 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12f2YR-000HDB-00 for namedroppers@ops.ietf.org; Tue, 11 Apr 2000 08:26:15 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12f2YR-0005Lp-00 for namedroppers@ops.ietf.org; Tue, 11 Apr 2000 08:26:15 -0700 Message-Id: <200004111051.GAA27753@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-tkey-02.txt Date: Tue, 11 Apr 2000 06:51:33 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Secret Key Establishment for DNS (TKEY RR) Author(s) : D. Eastlake 3rd Filename : draft-ietf-dnsext-tkey-02.txt Pages : 17 Date : 10-Apr-00 [draft-ietf-dnsext-tsig-*.txt] provides a means of authenticating Domain Name System (DNS) queries and responses using shared secret keys via the TSIG resource record (RR). However, it provides no mechanism for setting up such keys other than manual exchange. This document describes a TKEY RR that can be used in a number of different modes to establish shared secret keys between a DNS resolver and server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tkey-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-tkey-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-tkey-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000410121811.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-tkey-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-tkey-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000410121811.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Apr 11 12:22:55 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11401 for ; Tue, 11 Apr 2000 12:22:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12f2YI-000HCo-00 for namedroppers-data@psg.com; Tue, 11 Apr 2000 08:26:06 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12f2YI-000HCi-00 for namedroppers@ops.ietf.org; Tue, 11 Apr 2000 08:26:06 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12f2YH-0005Lk-00 for namedroppers@ops.ietf.org; Tue, 11 Apr 2000 08:26:05 -0700 Message-Id: <200004111051.GAA27741@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-sig-zero-01.txt Date: Tue, 11 Apr 2000 06:51:24 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNS Request and Transaction Signatures ( SIG(0)s ) Author(s) : D. Eastlake Filename : draft-ietf-dnsext-sig-zero-01.txt Pages : 9 Date : 10-Apr-00 Extensions to the Domain Name System (DNS) are described in [RFC 2535] that can provide data origin and transaction integrity and authentication to security aware resolvers and applications through the use of cryptographic digital signatures. Implementation experience has indicated the need for minor but non- interoperable changes in Request and Transaction signature resource records ( SIG(0)s ). These changes are documented herein. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-sig-zero-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-sig-zero-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-sig-zero-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000410121754.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-sig-zero-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-sig-zero-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000410121754.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Apr 11 12:27:52 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11567 for ; Tue, 11 Apr 2000 12:27:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12f2rX-000HSp-00 for namedroppers-data@psg.com; Tue, 11 Apr 2000 08:45:59 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12f2rW-000HSj-00 for namedroppers@ops.ietf.org; Tue, 11 Apr 2000 08:45:58 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12f2rW-0005T2-00 for namedroppers@ops.ietf.org; Tue, 11 Apr 2000 08:45:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <4.3.1.2.20000411083909.10cc7ee0@dokka.kvatro.no> References: Date: Tue, 11 Apr 2000 09:09:28 -0400 To: Harald Tveit Alvestrand From: Edward Lewis Subject: Re: Zone secure bit Cc: Edward Lewis , DNSEXT WG Mailing list Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 2:43 AM -0400 4/11/00, Harald Tveit Alvestrand wrote: >My vote for #3. Here's a comparison of option 1 & 2 and 3. Options 1 and 2 complicate the processing of NXT's, which are already a dicey proposal. (More on that later.) The complication is: 1) The setting of the bit (in the parent zone) depends on the previous setting, not on types currently present. Mitigating this is that at a delegation point, there should only ever be a few types - NS and the DNSSSEC types, KEY, SIG, and NXT. 'Course future types could be here. So, we're talking a difference of either "NS KEY SIG NXT" or "NS SIG NXT" at the delegation point. 2) Having two NXT sets at a domain name is a problem, one that is independent of this change. (More later.) 3) These options request a change in the dynamic update rule against changing NXT's. When a key is validated for a child, the parent zone needs to be updated to reflect this. Dynamic update is a convienent mechanism for this. However, options 1 & 2: 1) Eliminate the need for the parent to ever have a key set for the child. Currently, for an unsecurable child (which will be the majority of zones at least in the near future), a delegation point is: name NS NS KEY SIG KEY NXT SIG NXT Making use of the bit makes this: name NS NS NXT SIG NXT The big motivation has been to reduce the status of a zone to a binary question (secured/unsecured), which can be represented in a bit. A signed NULL KEY could be on the order of a 100 bytes (estimate). Such a savings is significant to the upper zones - which are crucial to the roll out of DNSSEC. Now, on the evil of NXT's. Many folks don't like them, but no one has been able to find an improvement. Here are approaches to the problem: 1 - The NXT, which shows the requester the two names and data at one surrounding the request, in order to "prove" that the data doesn't exist. This provides fine grained security, but easily exposes the zone's (public) data. 1a - Substitute hashes for the real names in the NXT's. (Hashing everything would help with I18N too. ;)) I've forgotten the reasons why this idea faded away. 2 - Signing a unique reply to a request would put a onerous load on the server. In light of recent DDOS attacks, this would be a bad idea. An attacker could issue a stream of missing data requests, locking the server into signing replies. 3 - Signing an SOA-like record, repeating it for each absent data result. This is subject to a replay attack. 4 - Leave absent data unprotected. What else am I missing? Summary: 1 - "Here's what I got, do you see what you want?" 2 - "What you want (name,data) I ain't got." 3 - "I ain't got whatever you want." 4 - No change from current. Is there a "philosophical" approach missing? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "Trying is the first step to failure." - Homer Simpson "No! Try not. Do... or do not. There is no try." - Yoda "It takes years of training to know when to do nothing" - Dogbert 1/21/00 Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Apr 11 12:38:54 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12120 for ; Tue, 11 Apr 2000 12:38:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12f32x-000Hfa-00 for namedroppers-data@psg.com; Tue, 11 Apr 2000 08:57:47 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12f32w-000HfU-00 for namedroppers@ops.ietf.org; Tue, 11 Apr 2000 08:57:46 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12f32w-0005XQ-00 for namedroppers@ops.ietf.org; Tue, 11 Apr 2000 08:57:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 11 Apr 2000 16:50:54 +0200 (CEST) From: Roy Arends To: Edward Lewis cc: DNSEXT WG Mailing list Subject: Re: Zone secure bit Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 10 Apr 2000, Edward Lewis wrote: > I am rewriting a draft on zone's security status and have a question for > which I'd like some feedback. Without going into gory details and special > cases, which is preferred: > > 1) A proposal to use the KEY RR bit in a delegation points upper NXT to > signify a signed child zone key and to do away with the use NULL keys > altogher. E.g., if the child's zone key has been signed by the parent, the > bit is on, the child's key is optionally held by the parent (recommendation > is not to). Thusfar this is an improvement. > If there is no signed zone key for the the child, the bit is > zero, and neither the parent nor child holds a signed NULL key. Ofcourse, the child could also be "privatly secure", having a signed KEY set, signed by some other party. Was your intention with the KEY RR bit to indicate that the child has a signed key-set, or, that the child has a key-set signed by this parent ? > In this > case, the KEY RR bit in the upper NXT signifies whether or not the zone is > secured. If the answer to the above question is that the KEY RR bit indicates that a KEY set was signed by the parent, the statement would not be true for a 'privatly secured' child. Else this would lead to a new interaction between the parent and the child which could be administarivly undesirable. > 2) The previous proposal plus the option that the parent may choose to hold > and sign a NULL key for an unsigned child. In this case, the KEY RR bit in > the upper NXT signifies that "there is a key for the child somewhere." IMHO there's no specific need to have backward compatibility. Secure zones can be counted on one hand. And there is still no final implementation that fully supports RFC2535. Regards, Roy Arends If there is no God, who pops up the next Kleenex? -- Art Hoppe -- roy@nlnetlabs.nl NLnetLabs tel +31208884551 Kruislaan 419 |\ || _ _|_ | _ |_ _ 1098 VA Amsterdam | \||__| )(-|_ |__(_||_)_) The Netherlands to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Apr 11 13:15:50 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13525 for ; Tue, 11 Apr 2000 13:15:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12f3ZG-000II3-00 for namedroppers-data@psg.com; Tue, 11 Apr 2000 09:31:10 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12f3ZF-000IHx-00 for namedroppers@ops.ietf.org; Tue, 11 Apr 2000 09:31:09 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12f3ZF-0005iE-00 for namedroppers@ops.ietf.org; Tue, 11 Apr 2000 09:31:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: Date: Tue, 11 Apr 2000 12:13:34 -0400 To: Roy Arends From: Edward Lewis Subject: Re: Zone secure bit Cc: Edward Lewis , DNSEXT WG Mailing list Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 10:50 AM -0400 4/11/00, Roy Arends wrote: >Ofcourse, the child could also be "privatly secure", having a signed KEY >set, signed by some other party. Was your intention with the KEY RR bit to >indicate that the child has a signed key-set, or, that the child has a >key-set signed by this parent ? Good question. Initially I thought the signifying whether the parent has validated the child's keys is what is needed, rather than if anyone has. The reason is that the time in which this bit is most important is in the case in which a resolver is following the DNS tree down from a secure root to the zone in question. As each zone is decended, a hint about the next zone's security is needed. If the validation goes off tree, then it is hard for the resolver to know if the zone is validated. So perhaps there is a desire to have the parent signify the child being validated by someone else. But consider this example (which isn't directly related to the bit setting, but is related to off-tree validation): test / \ mycom certifier Assume mycom and certifier are both properly validated by test. If off-tree validation happens, "certifier.test." could hijack "mycom.test." by creating a second keyset for mycom and signing it itself. certifier could then claim that mycom is validated by certifier, which is validated by test. Any resolver configuring the test key would trust the hijacked chain. (As far as label count, sub.mycom.test. could be hijacked by certifier.test., so that's no help.) IMHO, if an off-tree signer is used, then this needs to be signified via a record that is validated on-tree. So, good question... >If the answer to the above question is that the KEY RR bit indicates that >a KEY set was signed by the parent, the statement would not be true for a >'privatly secured' child. Else this would lead to a new interaction >between the parent and the child which could be administarivly >undesirable. I don't want to create more interactions across delegations. >> 2) The previous proposal plus the option that the parent may choose to hold >> and sign a NULL key for an unsigned child. In this case, the KEY RR bit in >> the upper NXT signifies that "there is a key for the child somewhere." > >IMHO there's no specific need to have backward compatibility. Secure zones >can be counted on one hand. And there is still no final implementation >that fully supports RFC2535. Beside backward compat, after doing a rewrite based on Brian's comments, the second choice is a bit cleaner. However, given the off-tree validation problem above, this may be muddled too. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "Trying is the first step to failure." - Homer Simpson "No! Try not. Do... or do not. There is no try." - Yoda "It takes years of training to know when to do nothing" - Dogbert 1/21/00 Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Apr 11 17:35:25 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22224 for ; Tue, 11 Apr 2000 17:35:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12f7i2-000LGP-00 for namedroppers-data@psg.com; Tue, 11 Apr 2000 13:56:30 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12f7i1-000LGI-00 for namedroppers@ops.ietf.org; Tue, 11 Apr 2000 13:56:29 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12f7hx-00077T-00 for namedroppers@ops.ietf.org; Tue, 11 Apr 2000 13:56:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38F37934.CFBD91AC@whistle.com> Date: Tue, 11 Apr 2000 12:12:52 -0700 From: Terry Lambert To: "Donald E. Eastlake 3rd" CC: namedroppers@ops.ietf.org Subject: Re: DNSEXT WG Last Call: SIG(0) References: <200004101536.LAA03119@torque.pothole.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Donald E. Eastlake 3rd wrote: > I also have a SecurID, although in my case it is for getting behind a > Motorola firewall. However, that has nothing to do with the SIG(0) > key rollover case. SecurIDs display a keyed function of time and do > not do any key rollover. In the case of real key rollover, you either > have to try multiple private keys at the signer or be able to try > multiple public keys at the verifier. And, in fact, multiple public > keys can be configured and multiple private keys can be tried > successively, even when multiple signatures are not allowed in one > message. DHCP leases work around this problem by requesting renewal at 50% of the renewal interval. It seems to me that you could avoid the multiple signature need in the key rollover case by ensuring valid overlapping certificates were used, and making the validation asymmetric, at the verifier, if it were really an issue. I'd like to avoid the extra traffic, and the possibility of political abuse of multiple signatures. > Requiring all parties to not just implement but also > enable and configure interoperably keys for the one or > occasionally two mandatory algorithms has been viewed > as unrealistic and insecure by causing excessive > reliance on and great difficulty in changing from the > mandatory algorithm. Perhaps a distinction between public and private algorithms, and a requirement that at least one public algorithm of the vendors choice be mandatory to implement. We would then at least have nodding possibility o0f interoperability. > The IETF certainly has the power to make its protocols > such that interoperability is possible/easy/prefered. > But if people don't want to interoperate, I don't think > "orders" from the IETF are going to make them configure > their systems interoperably. Let me not mince words, then. A vendor has implemented a non-interoperable version of Kerberos that requires their Kerberos servers in order to operate. Effectively, this means that an realm authentication server from any other manufactures, which can not accept and act on their private interpretation of the optional use field can not, in fact, participate as a peer in their network. The implications of this are that there is a leverage of a virtual client monopoly in order to ensure that their servers are used instead of servers from other parties, so long as those parties do not explicitly license code from the original vendor. It seems to me that the looseness around the SIG(0) ability to have multiple signatures simultaneously aids and abets this type of practice, and that it could therefore be easily extended to encourage/require the use of that vendors DNS servers, as well, through a similarly proprietary implementation. > What optional fields in SIG(0)? What white papers about SIG(0) use? > I am not aware of any... The optional inclusion of multiple signatures, such that a third party client that does not understand the proprietary signature can still achieve some minimum interoperability, as can the vendors clients, but for which third party servers result in broken vendor clients. I would argue that a single signature requirement will prevent this: require that servers use a single signing methodology when sending packets to particular hosts. Allow multiple signatures only in the case where all signatures are done using public algorithms. Make it painful to balkanize the server space by way of algorithm. > >What is to stop a vendor from implementing a signature > >security algorithm that is proprietary and/or patented, > >and then setting up their servers to require the use of > >their signatures, thus leveraging a near monopoly in > >clients to force the use of their servers? > > The US Departmet of Justice? :-) That hasn't worked with Kerberos realm authentication. It hasn't worked with RC4-based realm authentication. > The Internet only works because people find it to their > advantage to be able to interoperate. If, say, NSA want > to use some proprietary algorithm to secure their DNS > zones and not sign them with mandatory algorithms, that's > their decision. Most of the Internet, which does not > have this hypothetcial NSA proprietary algorithm implemented, > will treat their zones as Insecure and crackers will be able > to spoof their DNS data. It would be their choice. What if, instead, the NSA included their proprietary signature, and then _also_ included a mandatory algorithm signature? Then the NSA could treat all zones not signed by their proprietary algorithm as insecure, but everyone else would treat the NSA's zones as secure. The NSA could then refuse to engage in peering relationships with servers not using their algorithm. Now say they license the use of their algorithm. Now say that, through incompetance (e.g. key escrow), their algorithm is found to be insufficiently secure. Now say that there are unignorable business reasons that you have to implement their algorithm; for the NSA, this might be that your DNS packets can't transit US borders, unless you implement their algorithm. > >The RFC SHOULD NOT be issued until interoperability > >guarantees have been addressed in the protocol definition. > > Your position does not appear to me or, apparently, to the > chair to be the working group consensus and it is inconsistent > with what the IETF has done in IPSEC and other security areas. Protocol RFCs have traditionally not been issued without proof of interoperability between two independently developed implementations. Interoperability is clearly a goal of the IETF; permitting non-interoperability by design is a bad precedent, the proof being that this precedent has already been abused once. -- Terry Lambert -- Whistle Communications, Inc., an I.B.M. Company -- terry@whistle.com ------------------------------------------------------------------- This is formal notice under California Assembly Bill 1629, enacted 9/26/98 that any UCE sent to my email address will be billed $50 per incident to the legally allowed maximum of $25,000. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Apr 11 17:38:03 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22296 for ; Tue, 11 Apr 2000 17:38:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12f7pa-000LLB-00 for namedroppers-data@psg.com; Tue, 11 Apr 2000 14:04:18 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12f7pa-000LL5-00 for namedroppers@ops.ietf.org; Tue, 11 Apr 2000 14:04:18 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12f7pa-0007AC-00 for namedroppers@ops.ietf.org; Tue, 11 Apr 2000 14:04:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.1.20000411164251.00aba220@localhost> Date: Tue, 11 Apr 2000 16:44:43 -0400 To: "Donald E. Eastlake 3rd" , Olafur Gudmundsson From: Olafur Gudmundsson Subject: Re: DNSEXT WGLC Summary: SIG(0) Cc: DNSEXT WG Mailing list In-Reply-To: <200004101522.LAA03106@torque.pothole.com> References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 11:22 AM 4/10/00 , Donald E. Eastlake 3rd wrote: >I've edited and submitted the document as per WG consensus so it >should be announced in a few days. However, I did have one techncial >comment below... > >From: Olafur Gudmundsson >Message-Id: <4.1.20000322095037.06aab310@sentry.gw.tislabs.com> >Date: Wed, 22 Mar 2000 10:35:26 -0500 >To: DNSEXT WG Mailing list > >>The last call period on this document has concluded. >> >>Only one issue was raised during the WGLC period. Currently the draft >>allows multiple SIG(0)'s to be attached to a message. There where calls >>to restrict this to one SIG(0) per message. The consensus of the >>Working group is that SIG(0) MUST be restricted to one. >>The arguments against this restriction where: >>1. The client does not know what algorithm the server supports >>2. Allow Multiple Inheritance of capabilities to a key generated in a >>TKEY exchange. >> >>The working group rejects the first one as the client can query the server >>for its appropriate key set and use that to select one of clients key to >>sign message. > >I don't see how that would work. The question is what algorithms are >actually supported by the DNS server code at the server. This does >not have any necessary relation to any TKEY RRset anywhere. Zones can >be signed with any variety of algorithms even if none of the DNS >servers for that zone are security aware. KEY RRs that specify the >DNS or ANY protocol stored under a server name probably reflect >algorithms supported by that server but there could easily be no such >KEYs. And how can you find all of the names for a server? Even if >you had all of its IP addresses, you would have to do an inverse >lookup throughout the entire DNS for those addresses to find all the >domain names for a server... But we are looking for the host keys for the SERVER not zone keys. thus we can look this up as no host should list no-null keys for algorithm it can not use. Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Apr 11 18:20:35 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23138 for ; Tue, 11 Apr 2000 18:20:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12f8RX-000LqX-00 for namedroppers-data@psg.com; Tue, 11 Apr 2000 14:43:31 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12f8RW-000LqR-00 for namedroppers@ops.ietf.org; Tue, 11 Apr 2000 14:43:30 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12f8RW-0007PD-00 for namedroppers@ops.ietf.org; Tue, 11 Apr 2000 14:43:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38F398F1.B5D30A5@ehsco.com> Date: Tue, 11 Apr 2000 14:28:17 -0700 From: "Eric A. Hall" To: namedroppers Subject: SRV clients Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Are there any known clients which have implemented SRV support? Web browsers? NOS clients? Anything? -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Apr 11 18:44:09 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23463 for ; Tue, 11 Apr 2000 18:44:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12f8xe-000MIZ-00 for namedroppers-data@psg.com; Tue, 11 Apr 2000 15:16:42 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12f8xe-000MIT-00 for namedroppers@ops.ietf.org; Tue, 11 Apr 2000 15:16:42 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12f8xe-0007dj-00 for namedroppers@ops.ietf.org; Tue, 11 Apr 2000 15:16:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 11 Apr 2000 17:56:18 EDT From: Jeffrey Altman To: "Eric A. Hall" Cc: namedroppers Subject: Re: SRV clients In-Reply-To: Your message of Tue, 11 Apr 2000 14:28:17 -0700 Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Are there any known clients which have implemented SRV support? Web > browsers? NOS clients? Anything? Kerberos 5 is actively using SRV records to locate various Kerberos related services for a specified realm. Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Apr 11 19:14:34 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23813 for ; Tue, 11 Apr 2000 19:14:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12f9RE-000Mle-00 for namedroppers-data@psg.com; Tue, 11 Apr 2000 15:47:16 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12f9RE-000MlT-00 for namedroppers@ops.ietf.org; Tue, 11 Apr 2000 15:47:16 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12f9RE-0008yg-00 for namedroppers@ops.ietf.org; Tue, 11 Apr 2000 15:47:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19398D273324D3118A2B0008C7E9A5690BBB3B3D@SIT.platinum.corp.microsoft.com> From: James Gilroy To: "Eric A. Hall" , namedroppers Subject: RE: SRV clients Date: Tue, 11 Apr 2000 15:28:09 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Are there any known clients which have implemented SRV support? Web > browsers? NOS clients? Anything? Windows2000 uses SRV records to locate the directory (LDAP server). Records are registered with dynamic update under _ldap._tcp.. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Apr 12 03:11:45 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13151 for ; Wed, 12 Apr 2000 03:11:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12fGnH-0000vW-00 for namedroppers-data@psg.com; Tue, 11 Apr 2000 23:38:31 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12fGnH-0000vQ-00 for namedroppers@ops.ietf.org; Tue, 11 Apr 2000 23:38:31 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12fGnG-000BNs-00 for namedroppers@ops.ietf.org; Tue, 11 Apr 2000 23:38:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.1.2.20000412082123.02de4ef8@dokka.kvatro.no> Date: Wed, 12 Apr 2000 08:22:04 +0200 To: Terry Lambert , "Donald E. Eastlake 3rd" From: Harald Tveit Alvestrand Subject: Re: DNSEXT WG Last Call: SIG(0) Cc: namedroppers@ops.ietf.org In-Reply-To: <38F37934.CFBD91AC@whistle.com> References: <200004101536.LAA03119@torque.pothole.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 12:12 11.04.2000 -0700, Terry Lambert wrote: >Protocol RFCs have traditionally not been issued without >proof of interoperability between two independently >developed implementations. small correction: issued AS DRAFT STANDARD. Proposed Standard docs are normally issued without proof of interoperability. Harald -- Harald Tveit Alvestrand, EDB Maxware, Norway Harald.Alvestrand@edb.maxware.no to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Apr 12 03:17:51 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13179 for ; Wed, 12 Apr 2000 03:17:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12fGnR-0000ve-00 for namedroppers-data@psg.com; Tue, 11 Apr 2000 23:38:41 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12fGnR-0000vY-00 for namedroppers@ops.ietf.org; Tue, 11 Apr 2000 23:38:41 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12fGnQ-000BO0-00 for namedroppers@ops.ietf.org; Tue, 11 Apr 2000 23:38:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.1.2.20000411152800.094dbbb0@dokka.kvatro.no> Date: Wed, 12 Apr 2000 08:36:21 +0200 To: Edward Lewis From: Harald Tveit Alvestrand Subject: Wild, raving NXT lunacy (Re: Zone secure bit) Cc: Edward Lewis , DNSEXT WG Mailing list In-Reply-To: References: <4.3.1.2.20000411083909.10cc7ee0@dokka.kvatro.no> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 09:09 11.04.2000 -0400, Edward Lewis wrote: >Now, on the evil of NXT's. Many folks don't like them, but no one has been >able to find an improvement. well..... >Is there a "philosophical" approach missing? possibly. The ability of people to generate ideas is aw{ful,esome}. Wild, looney rave: - NXT performs 3 jobs, none of them well. One is "what RR sets are present for this name". Another is "how big is this hole", where the "other side" of the hole may be at any naming level, but is forced to be in the same delegation level. A third one is something vaguely related to delegation (Section 5.5 of RFC 2535, the "handwaving" section). - NS records do 2 jobs: Delegation point and zone info. It's possible to have the same NS in parent and child, but it is not enforced. (Query: Should it be?) Answer: Take out the knives, and carve. - The RRSETFLAG RR is the NXT minus the name. It is a DATA indicator, not a ZONE indicator. A parent zone WILL NOT hold its own RRSETFLAG RR, because what it's supposed to hold is supposed to be a subset (?) of the data held by the child zone. - The NEXT RR is the NXT minus the bitmap. It ALWAYS points to the next name ON THE SAME LEVEL OF DELEGATION. There is no special magic to what it does at a zone delegation point; the question of whether a next-name exists or not is not affected by the zone boundary. - The FIRSTCHILD RR is the NXT for the domain start, and indicates what goes on at the level BELOW. - (Do we need to do something to the SOA/NS workaholic at the same time?) Thus, if example.com and foo.example.com exist, with some junk, we have: - example.com RRSETFLAG - example.com NEXT example2.com (of interest to the parent zone only) (replacing the parent zone NXT) - example.com FIRSTCHILD foo.example2.com (replacing the child zone NXT) - foo.example.com NEXT If you need to signal the presence of a.b.c.d.example.com, you need to add: example.com FIRSTCHILD d.example.com d.example.com FIRSTCHILD c.d.example.com b.c.d.example.com FIRSTCHILD a.b.c.d.example.com which is a bit more than adding example.com NXT a.b.c.d.example.com but it's all automagically generated anyway..... We can now replace NEXT and FIRSTCHILD with a hash mechanism without affecting RRSETFLAG. Separation of concerns achieved. None of the records are different in the parent than in the child. You ask for other proposals, you get other proposals :-) The point of the exercise: If you keep the current NULL KEY mechanism, or at minimum don't involve the NXT record in signalling the parent's opinion of the child's security, none of this is relevant to zone security status. I don't want the zone secure bit in the NXT record. Harald -- Harald Tveit Alvestrand, EDB Maxware, Norway Harald.Alvestrand@edb.maxware.no to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Apr 12 09:57:37 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20608 for ; Wed, 12 Apr 2000 09:57:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12fN4P-0003zl-00 for namedroppers-data@psg.com; Wed, 12 Apr 2000 06:20:37 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12fN4O-0003zf-00 for namedroppers@ops.ietf.org; Wed, 12 Apr 2000 06:20:36 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12fN4O-000DUV-00 for namedroppers@ops.ietf.org; Wed, 12 Apr 2000 06:20:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <4.3.1.2.20000411152800.094dbbb0@dokka.kvatro.no> References: <4.3.1.2.20000411083909.10cc7ee0@dokka.kvatro.no> Date: Wed, 12 Apr 2000 09:18:28 -0400 To: Harald Tveit Alvestrand From: Edward Lewis Subject: Re: Wild, raving NXT lunacy (Re: Zone secure bit) Cc: Edward Lewis , DNSEXT WG Mailing list Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 2:36 AM -0400 4/12/00, Harald Tveit Alvestrand wrote: >You ask for other proposals, you get other proposals :-) Seriously, I like to see them. I'm not religious about the NXT, I'm just resigned to it. The problem I see with breaking the NXT into multiple records is the increase of SIG records to cover the new sets (hence the size of the zone). >- NS records do 2 jobs: Delegation point and zone info. > It's possible to have the same NS in parent and child, but it is not > enforced. (Query: Should it be?) What does this mean? PS - from http://www.ietf.org/internet-drafts/draft-iab-ntwlyrws-over-02.txt: > >3.5 Recommendations on DNS > > ...It is > therefore recommended to the IETF that, except for those changes > that are already in progress and will support easier renumbering of > networks and improved security, no fundamental changes or additions > to the DNS be made for the foreseeable future. > Does this mean we are stuck with the NXT for the time being? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "Trying is the first step to failure." - Homer Simpson "No! Try not. Do... or do not. There is no try." - Yoda "It takes years of training to know when to do nothing" - Dogbert 1/21/00 Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Apr 12 10:58:18 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23345 for ; Wed, 12 Apr 2000 10:58:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12fO6O-0004X3-00 for namedroppers-data@psg.com; Wed, 12 Apr 2000 07:26:44 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12fO6N-0004Wx-00 for namedroppers@ops.ietf.org; Wed, 12 Apr 2000 07:26:43 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12fO6N-000Dpb-00 for namedroppers@ops.ietf.org; Wed, 12 Apr 2000 07:26:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Edward Lewis Cc: DNSEXT WG Mailing list Subject: Re: Wild, raving NXT lunacy (Re: Zone secure bit) References: <4.3.1.2.20000411083909.10cc7ee0@dokka.kvatro.no> Message-Id: Date: Wed, 12 Apr 2000 07:25:47 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > PS - from http://www.ietf.org/internet-drafts/draft-iab-ntwlyrws-over-02.txt: >> >> 3.5 Recommendations on DNS >> >> ...It is >> therefore recommended to the IETF that, except for those changes >> that are already in progress and will support easier renumbering of >> networks and improved security, no fundamental changes or additions >> to the DNS be made for the foreseeable future. >> > Does this mean we are stuck with the NXT for the time being? this is the minute of a workshop, not a formal iesg position. even if it was, imiho (as an individual non-contributor) simplifying dnssec so that folk could actually understand it well enough to feel comfortable would seem to fit right under "improved security." randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Apr 12 13:48:04 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29480 for ; Wed, 12 Apr 2000 13:48:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12fQaY-0005tk-00 for namedroppers-data@psg.com; Wed, 12 Apr 2000 10:06:02 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12fQaY-0005te-00 for namedroppers@ops.ietf.org; Wed, 12 Apr 2000 10:06:02 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12fQaX-000Euc-00 for namedroppers@ops.ietf.org; Wed, 12 Apr 2000 10:06:01 -0700 Message-Id: <200004121701.KAA04074@sh.lh.vix.com> To: Harald Tveit Alvestrand cc: Edward Lewis , DNSEXT WG Mailing list Subject: Re: Wild, raving NXT lunacy (Re: Zone secure bit) In-reply-to: Your message of "Wed, 12 Apr 2000 08:36:21 +0200." <4.3.1.2.20000411152800.094dbbb0@dokka.kvatro.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 12 Apr 2000 10:01:39 -0700 From: Jerry Scharf Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Harald, I like this proposal on the whole. I see the impacts for the zones as small: for the parent, it's a wash or minor gain, replace NXT with NEXT. Same zone size, similar number/size of responses. for the child, replace NXT with RRSETFLAG and FIRSTCHILD flags associated with the SOA. Adds one SIG record to the child. Could hurt the 100,000 zone master servers. Doesn't change number/size of responses much (you can only get one of the two for any query.) The difference in zone file creation effort is a small improvement in logic and sometimes creating one more SIG, but it mostly a wash. I would like to find a better name for the RRSETFLAG, but that's minor. I think the resolver code becomes simpler, but the server code becomes more complex to handle backwards compatibility. while you have these open, we could add the capabilities of hash and name based FIRST/NEXT in if that's still desired. I liked it alot and don't remember why it got lost. Now for the sticky widget of backwards compatibility. There is no way currently to tell whether the resolver (or recursive server) expects old NXTs or the new proposal. We probably need to add something to the query (in EDNS0 space?) that says we can understand FIRST/NEXT/RRSETFLAG. If it's there, then the server can respond with those, and if not will need to synthesize the old NXTs. We can make other new DNSSEC functions tied to this, but I believe we will need to support the current DNSSEC specs for a long time. As for NSs, I think we have that sorted out and so we shouldn't "fix" it. It is very useful to not have forced coherence between parent and child on NS lists. Often times it has been very hard to get the parent to rapidly and correctly make changes to the NS list, and caching the child's "better" NS list has been an important way to help this. Now for the real issue to discuss, which is when to take this on. We have yet to deploy DNSSEC on any significant scale. Some would say it's better to fix it now, but I think we need to get it up and running in major production first and see what's going to work and not work, then take on changes like this. Given there is about to be a release of BIND with DNSSEC implemented as is and that is going to go into a significant number of O/S resolver distributions, we can't fix it before it gets out. I would recommend that the community learn more before embarking on the next round. No matter when we take this on, we need to sort out all the details of interoperability between this new scheme and the existing ones. jerry to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Apr 12 18:48:13 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04886 for ; Wed, 12 Apr 2000 18:48:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12fVBS-00094N-00 for namedroppers-data@psg.com; Wed, 12 Apr 2000 15:00:26 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12fVBR-00094G-00 for namedroppers@ops.ietf.org; Wed, 12 Apr 2000 15:00:25 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12fVBQ-000JrE-00 for namedroppers@ops.ietf.org; Wed, 12 Apr 2000 15:00:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.1.2.20000412214950.023a51b8@dokka.kvatro.no> Date: Wed, 12 Apr 2000 21:56:28 +0200 To: Jerry Scharf From: Harald Tveit Alvestrand Subject: Re: Wild, raving NXT lunacy (Re: Zone secure bit) Cc: Edward Lewis , DNSEXT WG Mailing list In-Reply-To: <200004121701.KAA04074@sh.lh.vix.com> References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 10:01 12.04.2000 -0700, Jerry Scharf wrote: >Now for the sticky widget of backwards compatibility. There is no way >currently to tell whether the resolver (or recursive server) expects old NXTs >or the new proposal. We probably need to add something to the query (in EDNS0 >space?) that says we can understand FIRST/NEXT/RRSETFLAG. If it's there, then >the server can respond with those, and if not will need to synthesize the old >NXTs. We can make other new DNSSEC functions tied to this, but I believe we >will need to support the current DNSSEC specs for a long time. If NXT is really fatally flawed, we should recommend that people stop sending it ASAP. I think backwards compatibility can then be limited to: - Clients must be able to ignore it - Servers must be able to not crash when asked for it A scheme that generated signed NXT records on the fly would: - Require on-line, real-time signatures - Provide all the complexity of the new stuff, all the complexity of the old stuff, AND the complexity of the mapping function That seems an awful lot of work to go thorugh to support the existing client applications that use the NXT record sensibly. Harald -- Harald Tveit Alvestrand, EDB Maxware, Norway Harald.Alvestrand@edb.maxware.no to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Apr 12 20:04:43 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05531 for ; Wed, 12 Apr 2000 20:04:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12fWZt-000A8j-00 for namedroppers-data@psg.com; Wed, 12 Apr 2000 16:29:45 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12fWZt-000A8d-00 for namedroppers@ops.ietf.org; Wed, 12 Apr 2000 16:29:45 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12fWZt-000KPd-00 for namedroppers@ops.ietf.org; Wed, 12 Apr 2000 16:29:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200004122322.QAA17278@sh.lh.vix.com> To: Harald Tveit Alvestrand cc: Jerry Scharf , Edward Lewis , DNSEXT WG Mailing list Subject: Re: Wild, raving NXT lunacy (Re: Zone secure bit) In-reply-to: Your message of "Wed, 12 Apr 2000 21:56:28 +0200." <4.3.1.2.20000412214950.023a51b8@dokka.kvatro.no> Date: Wed, 12 Apr 2000 16:22:01 -0700 From: Jerry Scharf Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > If NXT is really fatally flawed, we should recommend that people stop > sending it ASAP. > I think backwards compatibility can then be limited to: > > - Clients must be able to ignore it > - Servers must be able to not crash when asked for it If a current DNSSEC aware resolver sets CD and the result is a NXDOM or NXRR without a NXT record, what does current spec/code do? If it can accept the record as valid, then we are OK. If not and it tosses the response, then we may have a problem. Could people with current DNSSEC resolvers comment? > > A scheme that generated signed NXT records on the fly would: > > - Require on-line, real-time signatures Actually I misrepresented this. You would have both FIRST/NEXT/RRSETFLAGs and NXTs generated at zone signing time, and send out one or the other. > - Provide all the complexity of the new stuff, all the complexity of the > old stuff, AND the complexity of the mapping function yup. The mapping function happens at zone signing time, so that's at least separable. > > That seems an awful lot of work to go thorugh to support the existing > client applications that use the NXT record sensibly. Violating backwards compatability is a big deal to me, so I wanted the discussion of this aspect out in the open. If it is decided that tossing it is the right thing to do, and people getting ready to deploy secure resolvers don't pitch a fit, then it should be done that way. > > Harald > > -- > Harald Tveit Alvestrand, EDB Maxware, Norway > Harald.Alvestrand@edb.maxware.no > to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Apr 12 21:33:47 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06454 for ; Wed, 12 Apr 2000 21:33:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12fY12-000BPd-00 for namedroppers-data@psg.com; Wed, 12 Apr 2000 18:01:52 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12fY12-000BPX-00 for namedroppers@ops.ietf.org; Wed, 12 Apr 2000 18:01:52 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12fY12-000KvD-00 for namedroppers@ops.ietf.org; Wed, 12 Apr 2000 18:01:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <6B57F36F4FF9D111B30A0008C7F4133701040AB4@exdal1.ons.octel.com> From: "Sherer, Jeffrey A (Jeff)" To: "'Eric A. Hall'" , namedroppers Subject: RE: SRV clients Date: Wed, 12 Apr 2000 19:57:16 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit We are using SRV records to find subscriber directory servers in our networked voice messaging systems. Jeff Sherer DMTS Communications Applications Group - NCE Lucent Technologies email: jsherer@lucent.com ph: 972-733-2724 -----Original Message----- From: Eric A. Hall [mailto:ehall@ehsco.com] Sent: Tuesday, April 11, 2000 4:28 PM To: namedroppers Subject: SRV clients Are there any known clients which have implemented SRV support? Web browsers? NOS clients? Anything? to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Apr 12 23:09:15 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09325 for ; Wed, 12 Apr 2000 23:09:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12fZTk-000CCA-00 for namedroppers-data@psg.com; Wed, 12 Apr 2000 19:35:36 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12fZTj-000CC4-00 for namedroppers@ops.ietf.org; Wed, 12 Apr 2000 19:35:35 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12fZTj-000LPR-00 for namedroppers@ops.ietf.org; Wed, 12 Apr 2000 19:35:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <4.3.1.2.20000412214950.023a51b8@dokka.kvatro.no> References: <200004121701.KAA04074@sh.lh.vix.com> Date: Wed, 12 Apr 2000 21:51:32 -0400 To: Harald Tveit Alvestrand From: Edward Lewis Subject: Re: Wild, raving NXT lunacy (Re: Zone secure bit) Cc: Jerry Scharf , Edward Lewis , DNSEXT WG Mailing list Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 3:56 PM -0400 4/12/00, Harald Tveit Alvestrand wrote: > If NXT is really fatally flawed, we should recommend that people stop > sending it ASAP. The NXT is hardly "fatally flawed." There are some folks unhappy with it, but it does not cause serious problems. That there are two distinct RRsets at a delegation point is a nuisance that has been properly handled in at least two implementations. That the NXT makes "walking" the zone easy, it is not exposing data that would not otherwise be available. (What's worse, my requesting your zone NXT's or repeatedly banging your server for all possible label names to get the same information, or possibly quessing at names to confirm/deny hunches?) The NXT's requirement that a zone be sorted is a bear. However, no other alternative has removed this need without replacing it with an even greater performance problem. I'm not about to support tinkering further with the NXT (beyone the zone sec status bit) unless the result is a major gain. This is why I keep an eye on the "philosophical underpinnings" of the problem - maybe there's some law of physics that is being overlooked. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "Trying is the first step to failure." - Homer Simpson "No! Try not. Do... or do not. There is no try." - Yoda "It takes years of training to know when to do nothing" - Dogbert 1/21/00 Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Apr 13 11:31:35 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04778 for ; Thu, 13 Apr 2000 11:31:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12fk6v-000HLe-00 for namedroppers-data@psg.com; Thu, 13 Apr 2000 06:56:45 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12fk6v-000HLY-00 for namedroppers@ops.ietf.org; Thu, 13 Apr 2000 06:56:45 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12fk6u-000P09-00 for namedroppers@ops.ietf.org; Thu, 13 Apr 2000 06:56:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.1.2.20000413081125.06314fd0@dokka.kvatro.no> Date: Thu, 13 Apr 2000 08:20:06 +0200 To: Edward Lewis From: Harald Tveit Alvestrand Subject: Re: Wild, raving NXT lunacy (Re: Zone secure bit) Cc: Jerry Scharf , Edward Lewis , DNSEXT WG Mailing list In-Reply-To: References: <4.3.1.2.20000412214950.023a51b8@dokka.kvatro.no> <200004121701.KAA04074@sh.lh.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 21:51 12.04.2000 -0400, Edward Lewis wrote: >At 3:56 PM -0400 4/12/00, Harald Tveit Alvestrand wrote: > > If NXT is really fatally flawed, we should recommend that people stop > > sending it ASAP. > >The NXT is hardly "fatally flawed." There are some folks unhappy with it, >but it does not cause serious problems. Yet. Our current bogeyman example of deploying a complex specification is SNMP version 2. > That there are two distinct RRsets >at a delegation point is a nuisance that has been properly handled in at >least two implementations. and a violation of the DNS architectural model, IMHO, since it enshrines the idea of 2 different, valid RRsets for the same name and RR type. > That the NXT makes "walking" the zone easy, it >is not exposing data that would not otherwise be available. (What's worse, >my requesting your zone NXT's or repeatedly banging your server for all >possible label names to get the same information, or possibly quessing at >names to confirm/deny hunches?) > >The NXT's requirement that a zone be sorted is a bear. However, no other >alternative has removed this need without replacing it with an even greater >performance problem. The fact that the sort specified is more than a little strange, and does not extend naturally to non-ASCII, doesn't help much either. >I'm not about to support tinkering further with the NXT (beyone the zone >sec status bit) unless the result is a major gain. This is why I keep an >eye on the "philosophical underpinnings" of the problem - maybe there's >some law of physics that is being overlooked. I agree about not tinkering with it now. It's the only choice we have where we've worked out its good and bad sides. But I don't agree about adding the zone sec status bit, since a) that is a change, and b) it makes the zone security function dependent on NXT. I think we're going to replace it later (that is - invent a new mechanism, run both in parallel for a while, and then deprecate NXT); we should make sure doing so doesn't hurt more than it has to. Harald -- Harald Tveit Alvestrand, EDB Maxware, Norway Harald.Alvestrand@edb.maxware.no to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Apr 13 11:49:16 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05118 for ; Thu, 13 Apr 2000 11:49:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12fkjt-000Hm5-00 for namedroppers-data@psg.com; Thu, 13 Apr 2000 07:37:01 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12fkjt-000Hlz-00 for namedroppers@ops.ietf.org; Thu, 13 Apr 2000 07:37:01 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12fkjt-000PCU-00 for namedroppers@ops.ietf.org; Thu, 13 Apr 2000 07:37:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <4.3.1.2.20000413081125.06314fd0@dokka.kvatro.no> References: <4.3.1.2.20000412214950.023a51b8@dokka.kvatro.no> <200004121701.KAA04074@sh.lh.vix.com> Date: Thu, 13 Apr 2000 09:01:31 -0400 To: Harald Tveit Alvestrand From: Edward Lewis Subject: Re: Wild, raving NXT lunacy (Re: Zone secure bit) Cc: Edward Lewis , Jerry Scharf , DNSEXT WG Mailing list Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 2:20 AM -0400 4/13/00, Harald Tveit Alvestrand wrote: >I agree about not tinkering with it now. >It's the only choice we have where we've worked out its good and bad sides. >But I don't agree about adding the zone sec status bit, since a) that is a >change, and b) it makes the zone security function dependent on NXT. The reason for adding the bit is that this change will cause a significant shrinkage of the data processed at widely delegated zones. Assuming that there will be a lot of unsecured zones for the time to come, a zone like ".com" (the usual whipping child it seems) would fill up on signed NULL KEY RR records. Given that a delegation might have 2 NS RR's (unsigned), an signed NXT RR regardless of whether we make the proposed change, it looks like adding the change would save on the order of 40% in memory requirements for these zones. I think that such a significant savings would speed the adoption of the protocol - so we can then justify mucking with it sooner. The downside of the change pales in comparison. In terms of implementation, the information that is needed to set the bit appropriately is also needed to know whether or not to insert a NULL KEY RR in the master file. Hence, there is no new information flow causing an increase in complexity. As far as the issue that the bit is misleading, here's what might happen. A delegation point in .test might be: zubsone NS ns1.zubsone.test. NS ns1.zubsone.test. NXT zuppersone NS KEY SIG NXT SIG NXT .... Now, when a resolver asks for the KEY set one of two things could happen. The server returns the NXT set because there is no KEY set at the server (assuming the zones are not sharing the server). The resolver would see that it got a negative answer, but the answer says the data is available. The resolver would then have to know to go get the KEY from the authoritative source. On the other hand, the server could see in the NXT that the KEY set exists. The server could either respond by treating this as a recursive operation (is recursion is allowed) or respond with a referral answer to the resolver. I'd prefer the latter, this would be nicer to older resolvers. Opinions from the server implementers? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "Trying is the first step to failure." - Homer Simpson "No! Try not. Do... or do not. There is no try." - Yoda "It takes years of training to know when to do nothing" - Dogbert 1/21/00 Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Apr 13 11:50:31 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05136 for ; Thu, 13 Apr 2000 11:50:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12fkq8-000Hqv-00 for namedroppers-data@psg.com; Thu, 13 Apr 2000 07:43:28 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12fkq8-000Hqo-00 for namedroppers@ops.ietf.org; Thu, 13 Apr 2000 07:43:28 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12fkq7-000PEm-00 for namedroppers@ops.ietf.org; Thu, 13 Apr 2000 07:43:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.1.2.20000413151852.043eb048@dokka.kvatro.no> Date: Thu, 13 Apr 2000 15:39:55 +0200 To: Edward Lewis From: Harald Tveit Alvestrand Subject: Re: Wild, raving NXT lunacy (Re: Zone secure bit) Cc: Edward Lewis , Jerry Scharf , DNSEXT WG Mailing list In-Reply-To: References: <4.3.1.2.20000413081125.06314fd0@dokka.kvatro.no> <4.3.1.2.20000412214950.023a51b8@dokka.kvatro.no> <200004121701.KAA04074@sh.lh.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 09:01 13.04.2000 -0400, Edward Lewis wrote: >The reason for adding the bit is that this change will cause a significant >shrinkage of the data processed at widely delegated zones. Assuming that >there will be a lot of unsecured zones for the time to come, a zone like >".com" (the usual whipping child it seems) would fill up on signed NULL KEY >RR records. Let's do numbers; I dislike terms like "fill up". Current size of .com: 12 million records. Assumed typical entry in master zone: - 2 NS records, each of 20 bytes - 2 A records, each of 10 bytes (assuming full glue) total 60 bytes. Total for .com zone: 720 Mbytes. Added for security: - 1 NXT record, approx. 20 bytes - 3 SIG records, approx 50 bytes each (with DSA and keysize T=1) total 170 bytes. Total for .com zone: 2 Gbytes. Added to support NULL KEY: - 1 NULL KEY record, approx 20 bytes - 1 SIG record, approx 50 bytes total 70 bytes. Total for .com zone: 840 Mbytes. We quadruple(???) the memory footprint instead of "just" tripling it. So NULL KEY adds about 30% to the hardware cost of going DNSSEC, compared to the KEY bit. Might be more expensive if it flips over architectural limits in the server host machines. Numbers are nice. They are also probably wrong. But better than no numbers. Harald -- Harald Tveit Alvestrand, EDB Maxware, Norway Harald.Alvestrand@edb.maxware.no to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Apr 13 11:56:00 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05239 for ; Thu, 13 Apr 2000 11:55:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12fktE-000Htp-00 for namedroppers-data@psg.com; Thu, 13 Apr 2000 07:46:40 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12fktE-000Htj-00 for namedroppers@ops.ietf.org; Thu, 13 Apr 2000 07:46:40 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12fktE-000PFw-00 for namedroppers@ops.ietf.org; Thu, 13 Apr 2000 07:46:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <4.3.1.2.20000413151852.043eb048@dokka.kvatro.no> References: <4.3.1.2.20000413081125.06314fd0@dokka.kvatro.no> <4.3.1.2.20000412214950.023a51b8@dokka.kvatro.no> <200004121701.KAA04074@sh.lh.vix.com> Date: Thu, 13 Apr 2000 10:27:20 -0400 To: Harald Tveit Alvestrand From: Edward Lewis Subject: Re: Wild, raving NXT lunacy (Re: Zone secure bit) Cc: Edward Lewis , Jerry Scharf , DNSEXT WG Mailing list Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Why do you have 3 SIG records (added for security)? The NS and glue sets are not signed in the parent - if that is two of the three SIGs you counted. But perhaps I'm missing something. If I'm right, we're looking at 70 bytes for NULL KEY divided by a total of 200 bytes [=60+70+70], which means removing the NULL KEY would save 35% (corresponding to my guess of 40%). If I'm wrong, the savings is 23%. (In other words, if I'm right, the cost of adding NULL keys is 53%, if I'm wrong, 30%.) BTW - The reason my guess was 40, and now calculated to be 35 is that I took into account that many delegations share name servers, hence reducing the amount of glue, making the NULL KEY a bigger hit than calculations here show. At 9:39 AM -0400 4/13/00, Harald Tveit Alvestrand wrote: >At 09:01 13.04.2000 -0400, Edward Lewis wrote: >>The reason for adding the bit is that this change will cause a significant >>shrinkage of the data processed at widely delegated zones. Assuming that >>there will be a lot of unsecured zones for the time to come, a zone like >>".com" (the usual whipping child it seems) would fill up on signed NULL KEY >>RR records. > >Let's do numbers; I dislike terms like "fill up". > >Current size of .com: 12 million records. > >Assumed typical entry in master zone: >- 2 NS records, each of 20 bytes >- 2 A records, each of 10 bytes (assuming full glue) >total 60 bytes. Total for .com zone: 720 Mbytes. > >Added for security: >- 1 NXT record, approx. 20 bytes >- 3 SIG records, approx 50 bytes each (with DSA and keysize T=1) >total 170 bytes. Total for .com zone: 2 Gbytes. > >Added to support NULL KEY: >- 1 NULL KEY record, approx 20 bytes >- 1 SIG record, approx 50 bytes >total 70 bytes. Total for .com zone: 840 Mbytes. > >We quadruple(???) the memory footprint instead of "just" tripling it. > >So NULL KEY adds about 30% to the hardware cost of going DNSSEC, compared >to the KEY bit. Might be more expensive if it flips over architectural >limits in the server host machines. > >Numbers are nice. They are also probably wrong. But better than no numbers. > > Harald > >-- >Harald Tveit Alvestrand, EDB Maxware, Norway >Harald.Alvestrand@edb.maxware.no -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "Trying is the first step to failure." - Homer Simpson "No! Try not. Do... or do not. There is no try." - Yoda "It takes years of training to know when to do nothing" - Dogbert 1/21/00 Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Apr 13 13:00:09 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07840 for ; Thu, 13 Apr 2000 13:00:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12fmL1-000JPo-00 for namedroppers-data@psg.com; Thu, 13 Apr 2000 09:19:27 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12fmL1-000JPi-00 for namedroppers@ops.ietf.org; Thu, 13 Apr 2000 09:19:27 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12fmL1-000PnK-00 for namedroppers@ops.ietf.org; Thu, 13 Apr 2000 09:19:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Masataka Ohta Message-Id: <200004131606.BAA15091@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id BAA15091; Fri, 14 Apr 2000 01:06:32 +0900 Subject: Re: Wild, raving NXT lunacy (Re: Zone secure bit) To: lewis@tislabs.com (Edward Lewis) Date: Fri, 14 Apr 0 1:06:32 JST Cc: Harald@Alvestrand.no, lewis@tislabs.com, namedroppers@internic.net In-Reply-To: ; from "Edward Lewis" at Apr 12, 100 11:04 pm Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward; > >You ask for other proposals, you get other proposals :-) > > Seriously, I like to see them. I'm not religious about the NXT, I'm just > resigned to it. You have already seen the attached proposal. It is the original proposal, which was badly modified by Donald into unusable NXT. > The problem I see with breaking the NXT into multiple records is the > increase of SIG records to cover the new sets (hence the size of the zone). That is another silly proposal not worse commenting. Masataka Ohta --- >From mohta Thu Jul 15 17:06:46 1999 Subject: On secure DNS update and NXT To: dnsop@cafax.se Date: Thu, 15 Jul 99 17:06:46 JST X-Mailer: ELM [version 2.3 PL11] Status: OR Reading draft-ietf-dnsop-keyhand-00.txt, it is my pleasure to see people working on DNSSEC finally understand DNS issues. That is, it seems to be the time to revive: > INTERNET DRAFT M. Ohta > draft-ohta-simple-dns-01.txt Tokyo Institute of Technology > November 1994 > Simple Secure DNS Incorporation of some (all is better if you want to remove all the complex tricks to implement and operate DNSSEC, but I'm so humble) of it should not be too late. On the dynamic update issue, it said: In cases where frequent and/or automatic update of a zone is desired, it is necessary to make signature generation mechanism of the zone accessible on-line. Still, it is worthwhile to keep the secret information and secure time stamping mechanism of the zone off-line. To make it easier, the protocol is designed to let signed information have the consistent format about time stamping and signature generation. Then, after the security of the signature generation mechanism is restored, signatures using the same secret information become reliable again. In 1994 in DNSSEC WG, the need on frequent update was not recognized very well. On the NXT issue, it said: 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". ZL will have the following syntax. [ZL] ... where [ZL] is the RR name of ZL data, is the number of seconds appropriate for negative caching, is the number of domains covered by the record. The record contains all the domain names of the zone (including the top level nodes of child zones but excluding the zone name itself) after (or including) and before sorted with dictionary order. Cases of characters in , ... must be canonicalized to lower cases. and is merely a separator and should not be interpreted that such a node exists unless explicitly listed as . Comparison is performed first label by label. Top level labels are compared first and the leaf labels are compared last, which makes domain name compression work quite well. Within labels, comparison are by dictionary oder, that is, first bytes are compared first. For example, "a.b.c.", "a.c.b.", "a.c.", "ab.c.", "ac.b." and "c." are ordered as "ac.b.", "a.c.b.", "c.", "a.c.", "ab.c." and "a.b.c.". Thus, the name of the zone is ordered before all the other names in the domain. For the comparison purpose, when the name of the zone itself appears as , it is considered to be ordered after all the other names in the domain. For example, [ZL] 0 represents a zone consisting of only a single node. and are two byte integers. , , , ..., have the syntax of domain names. To make an authenticated response of non existent node resides within 512 byte UDP packet, it is recommeded that the length of a single [ZL] record be shorter than 400 bytes, after limited domain name compression (those information available within the record itself only, may be shared for compression). , and are the same as that of [NSIG] except that the signature covers the byte stream of the sequence of ... contained in the [ZL] record itself. In short, ZL is data belongs to the parent zone to authenticate the non existence of a node. Masataka Ohta to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Apr 13 13:21:09 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08574 for ; Thu, 13 Apr 2000 13:21:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12fmmh-000JnK-00 for namedroppers-data@psg.com; Thu, 13 Apr 2000 09:48:03 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12fmmh-000JnE-00 for namedroppers@ops.ietf.org; Thu, 13 Apr 2000 09:48:03 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12fmmg-000Pz8-00 for namedroppers@ops.ietf.org; Thu, 13 Apr 2000 09:48:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <200004131606.BAA15091@necom830.hpcl.titech.ac.jp> References: ; from "Edward Lewis" at Apr 12, 100 11:04 pm Date: Thu, 13 Apr 2000 12:46:11 -0400 To: Masataka Ohta From: Edward Lewis Subject: Re: Wild, raving NXT lunacy (Re: Zone secure bit) Cc: lewis@tislabs.com (Edward Lewis), Harald@Alvestrand.no, namedroppers@internic.net Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 12:06 PM -0400 4/13/00, Masataka Ohta wrote: > >You have already seen the attached proposal. It is the original >proposal, which was badly modified by Donald into unusable NXT. > ... >That is another silly proposal not worse commenting. Well said. Your "Zone List" solves none of the problems with the NXT. It makes walking the zone easier (fewer queries). It requires a sort (that is ASCII based in the definition). It does not cover absent data for a present name. Your proposal failed to gain acceptance in the early days of DNSSEC (prior my introduction to the problem, so I don't have a date) and again failed last year. Please bury this proposal once and for all. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "Trying is the first step to failure." - Homer Simpson "No! Try not. Do... or do not. There is no try." - Yoda "It takes years of training to know when to do nothing" - Dogbert 1/21/00 Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Apr 13 15:17:45 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11707 for ; Thu, 13 Apr 2000 15:17:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12foQF-000LKS-00 for namedroppers-data@psg.com; Thu, 13 Apr 2000 11:32:59 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12foQE-000LKL-00 for namedroppers@ops.ietf.org; Thu, 13 Apr 2000 11:32:58 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12foQE-0000eI-00 for namedroppers@ops.ietf.org; Thu, 13 Apr 2000 11:32:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38F6126E.FE7D5A00@nominum.com> Date: Thu, 13 Apr 2000 11:31:10 -0700 From: "David R. Conrad" To: Harald Tveit Alvestrand Cc: Edward Lewis , Jerry Scharf , DNSEXT WG Mailing list Subject: Re: Wild, raving NXT lunacy (Re: Zone secure bit) References: <4.3.1.2.20000413081125.06314fd0@dokka.kvatro.no> <4.3.1.2.20000412214950.023a51b8@dokka.kvatro.no> <200004121701.KAA04074@sh.lh.vix.com> <4.3.1.2.20000413151852.043eb048@dokka.kvatro.no> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Let's do numbers; Umph. From http://www.centr.org/meetings/dnssec-20000328.html ... There were many rumours of DNSSEC not scaling for large zones, but there seemed to be a lack of empirical evidence upon which to base these judgements. Zone files supposedly took weeks to generate and inflated zone files by a factor of ten. NLnet Labs had conducted their own tests, and found that zone files typically only grew by a factor of two or three. Even in the worst case scenario, they could not get the zone file to grow by more than a factor of five. Furthermore, a zone file with 10,000 records and 1024-bit DSA keys could be generated in under five minutes using a 500 MHz Athlon-based PC. This meant that the .de zone file (approximately two million records) could be generated in around sixteen hours, and this would only need to be done once. Subsequent updates would be incremental. ... [Kudos to the folks at NLNet Labs and CENTR for actually taking the time to do empirical tests with the freely available tools] Can we perhaps hold off a bit on radically revising DNSSEC until we actually get a bit of field experience with a full implementation? (I find it distressing this would even need be asked). Rgds, -drc to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Apr 13 17:46:01 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14717 for ; Thu, 13 Apr 2000 17:46:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12fqnG-000NYs-00 for namedroppers-data@psg.com; Thu, 13 Apr 2000 14:04:54 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12fqnG-000NYm-00 for namedroppers@ops.ietf.org; Thu, 13 Apr 2000 14:04:54 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12fqnG-0001Y4-00 for namedroppers@ops.ietf.org; Thu, 13 Apr 2000 14:04:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.1.2.20000413213205.026361c0@dokka.kvatro.no> Date: Thu, 13 Apr 2000 23:00:43 +0200 To: Edward Lewis From: Harald Tveit Alvestrand Subject: Re: Wild, raving NXT lunacy (Re: Zone secure bit) Cc: Edward Lewis , Jerry Scharf , DNSEXT WG Mailing list In-Reply-To: References: <4.3.1.2.20000413151852.043eb048@dokka.kvatro.no> <4.3.1.2.20000413081125.06314fd0@dokka.kvatro.no> <4.3.1.2.20000412214950.023a51b8@dokka.kvatro.no> <200004121701.KAA04074@sh.lh.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 10:27 13.04.2000 -0400, Edward Lewis wrote: >Why do you have 3 SIG records (added for security)? The NS and glue sets >are not signed in the parent - if that is two of the three SIGs you >counted. But perhaps I'm missing something. Why shouldn't they be signed by the parent, if the child is not going to sign them? Or - why should I, as superzone provider, leave the children open to an attack that I can stop by signing them? but I admit to still thinking of the relationship between data in a superzone and data for the same name in a subzone as an area where the magic of the DNS is of a darker shade than usual; if you say that the superzone shouldn't sign them, I'll believe you. BTW, I think my subject line fits the discussion quite well....we should remember that what the base discussion we're having is a small change to the NXT record to be implemented (or not) in BIND 9 (I suppose), not deploying the alternative to NXT. Harald -- Harald Tveit Alvestrand, EDB Maxware, Norway Harald.Alvestrand@edb.maxware.no to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Apr 13 20:34:12 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16449 for ; Thu, 13 Apr 2000 20:34:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12ftZH-000Q0I-00 for namedroppers-data@psg.com; Thu, 13 Apr 2000 17:02:39 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12ftZG-000Q0C-00 for namedroppers@ops.ietf.org; Thu, 13 Apr 2000 17:02:38 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12ftZG-0002Wm-00 for namedroppers@ops.ietf.org; Thu, 13 Apr 2000 17:02:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <4.3.1.2.20000413213205.026361c0@dokka.kvatro.no> References: <4.3.1.2.20000413151852.043eb048@dokka.kvatro.no> <4.3.1.2.20000413081125.06314fd0@dokka.kvatro.no> <4.3.1.2.20000412214950.023a51b8@dokka.kvatro.no> <200004121701.KAA04074@sh.lh.vix.com> Date: Thu, 13 Apr 2000 18:04:59 -0400 To: Harald Tveit Alvestrand From: Edward Lewis Subject: Re: Wild, raving NXT lunacy (Re: Zone secure bit) Cc: Edward Lewis , Jerry Scharf , DNSEXT WG Mailing list Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 5:00 PM -0400 4/13/00, Harald Tveit Alvestrand wrote: >magic of the DNS is of a darker shade than usual; if you say that the >superzone shouldn't sign them, I'll believe you. "Should"/"Should not" I don't know, but the specification calls for the superzone not to sign the NS and glue. I haven't personally questioned this, as I agree with it on the surface. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "Trying is the first step to failure." - Homer Simpson "No! Try not. Do... or do not. There is no try." - Yoda "It takes years of training to know when to do nothing" - Dogbert 1/21/00 Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Apr 13 20:34:13 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16450 for ; Thu, 13 Apr 2000 20:34:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12ftai-00002Y-00 for namedroppers-data@psg.com; Thu, 13 Apr 2000 17:04:08 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12ftah-00002S-00 for namedroppers@ops.ietf.org; Thu, 13 Apr 2000 17:04:07 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12ftah-0002XJ-00 for namedroppers@ops.ietf.org; Thu, 13 Apr 2000 17:04:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <2F3EC696EAEED311BB2D009027C3F4F408EA7D@vhqpostal.verisign.com> From: Philip Hallam-Baker To: "'David R. Conrad'" , Harald Tveit Alvestrand Cc: Edward Lewis , Jerry Scharf , DNSEXT WG Mailing list Subject: RE: Wild, raving NXT lunacy (Re: Zone secure bit) Date: Thu, 13 Apr 2000 15:10:41 -0700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >Can we perhaps hold off a bit on radically revising DNSSEC until we actually >get a bit of field experience with a full implementation? (I find it >distressing this would even need be asked). I would second this (but this is IETF so no votes). The world is already set to deploy PKI infrastructure requiring far more signatures per day than DNS without undue concern. There is plenty of very fast crypto hardware arround. However great the number of DNS names, I'll wager that the number of transactions occuring between the names will be significantly larger. Systems like Identrus envisage using a lot of signatures to support the likes of OCSP. If the worst comes to the worst we can lash together a couple of thousand inmos transputers and have that do zone signing. Extrapolating from the Athalon figures that would allow us to sign a .com zone for 6 billion people in about one week - enough for one name each on the basis of a decade old technology. Modern crypto processors plugging into a PC via a USB hub could probably do the job quicker and for less and bring a FIPS rating into the bargain. Furthermore I think that a clear distinction needs to be drawn between optimization (using the least bits) and preventing catastrophic failure (death of the Internet, news at 11). The demand for DNS names is growing exponentially, ergo if preventing catastrophic failure depends on design tolerances of 30% or even 100% we have big trouble. We need headroom of an order of magnitude at least. Thus the threshold for claiming an issue to be one of catastrophic failure rather than an optimization needs to be quite high. Phill to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Apr 13 21:29:41 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16941 for ; Thu, 13 Apr 2000 21:29:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12fuYM-000164-00 for namedroppers-data@psg.com; Thu, 13 Apr 2000 18:05:46 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12fuYL-00015y-00 for namedroppers@ops.ietf.org; Thu, 13 Apr 2000 18:05:45 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12fuYL-0002su-00 for namedroppers@ops.ietf.org; Thu, 13 Apr 2000 18:05:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38F66C77.238856A7@ehsco.com> Date: Thu, 13 Apr 2000 17:55:19 -0700 From: "Eric A. Hall" Organization: EHS Company To: namedroppers Subject: Can TXT have multiple fields? Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Can TXT have multiple fields in its answer data? 1035 is the source of my question: 3.3.14. TXT RDATA format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / TXT-DATA / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: TXT-DATA One or more s. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ That means that a single TXT RR can have multiple as its answer data. is defined as: 3.3. Standard RRs is a single length octet followed by that number of characters. So a TXT RR can have multiple with each of them having a separate length byte. EG, each TXT RR can have a variable number of fields, not just a single variable-length field. BIND doesn't seem to support this usage, although maybe I'm trying to delineate the test data wrong. Using: test-txt 86400 IN TXT ("answer data" "more data") is rejected when the zone loads. What say you all? -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Apr 14 01:27:27 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24248 for ; Fri, 14 Apr 2000 01:27:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12fy3y-0004L8-00 for namedroppers-data@psg.com; Thu, 13 Apr 2000 21:50:38 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12fy3x-0004L2-00 for namedroppers@ops.ietf.org; Thu, 13 Apr 2000 21:50:37 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12fy3x-00047I-00 for namedroppers@ops.ietf.org; Thu, 13 Apr 2000 21:50:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38F69488.141DDEDB@ehsco.com> Date: Thu, 13 Apr 2000 20:46:17 -0700 From: "Eric A. Hall" To: namedroppers Subject: Re: Can TXT have multiple fields? References: <38F66C77.238856A7@ehsco.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Can TXT have multiple fields in its answer data? Yes, tested on another server, xfer to other test servers succeeds. Pardon the noise. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Apr 14 01:27:32 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24282 for ; Fri, 14 Apr 2000 01:27:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12fy5r-0004MZ-00 for namedroppers-data@psg.com; Thu, 13 Apr 2000 21:52:35 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12fy5r-0004MT-00 for namedroppers@ops.ietf.org; Thu, 13 Apr 2000 21:52:35 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12fy5r-000480-00 for namedroppers@ops.ietf.org; Thu, 13 Apr 2000 21:52:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200004140407.VAA51772@redpaul.mibh.net> To: namedroppers Subject: Re: Can TXT have multiple fields? In-reply-to: Your message of "Thu, 13 Apr 2000 17:55:19 PDT." <38F66C77.238856A7@ehsco.com> Date: Thu, 13 Apr 2000 21:07:41 -0700 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Can TXT have multiple fields in its answer data? yes. > So a TXT RR can have multiple with each of them > having a separate length byte. EG, each TXT RR can have a variable > number of fields, not just a single variable-length field. yes. > BIND doesn't seem to support this usage, although maybe I'm trying to > delineate the test data wrong. Using: > > test-txt 86400 IN TXT ("answer data" "more data") > > is rejected when the zone loads. BIND4 and BIND8 do the wrong thing with parenthesis. do this: test-txt 96400 IN TXT "answer data" "more data" to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Apr 14 01:30:57 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24801 for ; Fri, 14 Apr 2000 01:30:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12fy4J-0004La-00 for namedroppers-data@psg.com; Thu, 13 Apr 2000 21:50:59 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12fy4J-0004LU-00 for namedroppers@ops.ietf.org; Thu, 13 Apr 2000 21:50:59 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12fy4I-00047V-00 for namedroppers@ops.ietf.org; Thu, 13 Apr 2000 21:50:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200004140349.NAA12791@bsdi.dv.isc.org> To: "Eric A. Hall" Cc: namedroppers From: Mark.Andrews@nominum.com Subject: Re: Can TXT have multiple fields? In-reply-to: Your message of "Thu, 13 Apr 2000 17:55:19 MST." <38F66C77.238856A7@ehsco.com> Date: Fri, 14 Apr 2000 13:49:06 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Can TXT have multiple fields in its answer data? > > 1035 is the source of my question: > > 3.3.14. TXT RDATA format > > +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > > / TXT-DATA / > > +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > > > > where: > > > > TXT-DATA One or more s. > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > That means that a single TXT RR can have multiple as > its answer data. > > is defined as: > > 3.3. Standard RRs > > > is a single length octet followed by > that number of characters. > > So a TXT RR can have multiple with each of them > having a separate length byte. EG, each TXT RR can have a variable > number of fields, not just a single variable-length field. > > BIND doesn't seem to support this usage, although maybe I'm trying to > delineate the test data wrong. Using: > > test-txt 86400 IN TXT ("answer data" "more data") > > is rejected when the zone loads. > > What say you all? Well the question would have been better directed at bind-users@isc.org than namedroppers. BIND supports multiple txt strings in a single txt record. The following works: test-txt 86400 IN TXT "answer data" "more data" BIND 4/8 does not have generalised ( ) support which is why the example failed. BIND 9 has generalised ( ) support Mark > > -- > Eric A. Hall ehall@ehsco.com > +1-650-685-0557 http://www.ehsco.com > > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. -- Mark Andrews, Nominum Inc. / Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Apr 14 07:12:39 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05656 for ; Fri, 14 Apr 2000 07:12:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12g3OR-0007jQ-00 for namedroppers-data@psg.com; Fri, 14 Apr 2000 03:32:07 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12g3OQ-0007jK-00 for namedroppers@ops.ietf.org; Fri, 14 Apr 2000 03:32:06 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12g3OQ-0005ua-00 for namedroppers@ops.ietf.org; Fri, 14 Apr 2000 03:32:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Can TXT have multiple fields? In-Reply-To: Message from "Eric A. Hall" dated "Thu, 13 Apr 2000 21:13:54 EDT" <38F66C77.238856A7@ehsco.com> References: <38F66C77.238856A7@ehsco.com> From: Rob Austein Message-Id: <20000414054638Z23469-228+37@thrintun.hactrn.net> Date: Fri, 14 Apr 2000 01:46:34 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk To: namedroppers-data@psg.com Content-Transfer-Encoding: 7bit Date: Thu, 13 Apr 2000 21:13:54 -0400 From: "Eric A. Hall" Can TXT have multiple fields in its answer data? Yes. BIND doesn't seem to support this usage Old versions of BIND handled TXT strangely when parsing the master file: they supported only a single string in the zone file, but broke it up into 255 octet chunks to comply with the wire format. This was fixed about four years ago. Modern versions should be ok with: mumble.example.com. TXT "fee" "fie" "foe" "fum" to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Apr 14 07:30:56 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05854 for ; Fri, 14 Apr 2000 07:30:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12g3jn-0007wO-00 for namedroppers-data@psg.com; Fri, 14 Apr 2000 03:54:11 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12g3jm-0007wI-00 for namedroppers@ops.ietf.org; Fri, 14 Apr 2000 03:54:10 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12g3jm-00063c-00 for namedroppers@ops.ietf.org; Fri, 14 Apr 2000 03:54:10 -0700 Message-Id: <200004141039.GAA05292@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-zone-status-01.txt Date: Fri, 14 Apr 2000 06:39:55 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNS Security Extension Clarification on Zone Status Author(s) : E. Lewis Filename : draft-ietf-dnsext-zone-status-01.txt Pages : 11 Date : 13-Apr-00 The definition of a secured zone is presented, updating RFC 2535. The new definition has consequences which alter the interpretation of the NXT record, obsolete NULL keys, and the designation of 'experimentally secure.' A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-zone-status-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-zone-status-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-zone-status-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000413134821.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-zone-status-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-zone-status-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000413134821.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From vixie@mibh.net Fri Apr 14 14:12:56 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12212 for ; Fri, 14 Apr 2000 14:12:55 -0400 (EDT) Received: from isrv3.isc.org ([204.152.184.87]) by psg.com with esmtp (Exim 3.13 #1) id 12g9qp-000Bde-00 for namedroppers-data@psg.com; Fri, 14 Apr 2000 10:25:51 -0700 Received: from redpaul.mibh.net (redpaul.mibh.net [204.152.187.70]) by isrv3.isc.org (8.9.1/8.9.1) via ESMTP id KAA13875 for ; Fri, 14 Apr 2000 10:25:20 -0700 (PDT) env-from (vixie@mibh.net) Received: from redpaul.mibh.net (localhost [127.0.0.1]) by redpaul.mibh.net (8.9.3/8.9.1) via ESMTP id KAA53713 for ; Fri, 14 Apr 2000 10:25:20 -0700 (PDT) env-from (vixie@mibh.net) Message-Id: <200004141725.KAA53713@redpaul.mibh.net> To: namedroppers-data@psg.com Subject: Re: Can TXT have multiple fields? In-reply-to: Your message of "Fri, 14 Apr 2000 01:46:34 EDT." <20000414054638Z23469-228+37@thrintun.hactrn.net> Date: Fri, 14 Apr 2000 10:25:20 -0700 From: Paul A Vixie > Old versions of BIND handled TXT strangely when parsing the master > file: they supported only a single string in the zone file, but broke > it up into 255 octet chunks to comply with the wire format. This was > fixed about four years ago. Modern versions should be ok with: > > mumble.example.com. TXT "fee" "fie" "foe" "fum" the quotes aren't necessary, according to the rfc or to the bind parser, unless you're trying to make a single text string. that means, according to the rfc and to modern bind: mumble.example.com. TXT "fee" "fie" "foe" "fum" ; four strings mumble.example.com. TXT fee fie foe fum ; four strings mumble.example.com. TXT "fee fie foe fum" ; one string From owner-namedroppers@ops.ietf.org Tue Apr 18 13:06:56 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08288 for ; Tue, 18 Apr 2000 13:06:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12haLS-0003uf-00 for namedroppers-data@psg.com; Tue, 18 Apr 2000 08:55:22 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12haLR-0003uZ-00 for namedroppers@ops.ietf.org; Tue, 18 Apr 2000 08:55:21 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12haLR-000KnK-00 for namedroppers@ops.ietf.org; Tue, 18 Apr 2000 08:55:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 18 Apr 2000 17:40:47 +0200 (CEST) From: Roy Arends To: dnsop@cafax.se, namedroppers@ops.ietf.org Subject: DNSSEC: Signing the German TLD zone. Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This report was just sent to the DNSSEC-WG at CENTR. ---------- Forwarded message ---------- Date: Tue, 18 Apr 2000 17:05:44 +0200 (CEST) From: Roy Arends To: dnssec-wg@lists.centr.org Subject: Signing the German TLD zone. (fwd) Signing the German TLD zone. 1. The original .de zone Structure. German domain holders can either have their zone delegated (with a maximum of 5 NS records) or have 5 (A/MX) RR records in de .de zone itself. MX RR labels may have wildcards. CNAME RR's are not allowed. 1.2 Statistics. SOA RR : 1 NS RR : 2685819 MX RR : 1403093 (682539 are wildcards) A RR : 1365582 Domains: 1976902 Size : 232 MByte 1.3 Preparing for the signing session. Due to the size and the expected growth of the zone during the signing session, the test-machine had to be reconfigured. The limit of datasize segments was set to 2G and swap space was increased to 4G. 1.4 Signing the zone. To sign the zone, we used the signer that came with the distribution of BIND V9.0.0-b2. We changed to the source-code to get time-stamps after N signatures. We used a 512 bit DSA key, generated with the keygen tool, also from the distribution of BIND V9.0.0-b2. The test-machine is an average off-the shelf pc with an athlon 500 MHz processor running FreeBSD 3.4 . 1.5 Results We measured the usage of the signing process on the processor plus the system time. The time used was 47601 sec (13h13m21s). The following was done: 1 SOA RRset was signed 1 NS RRset was signed 1336944 MX RRsets were signed 1348946 A RRsets were signed 3333218 NXT RR's were created 3323726 NXT RR's were signed 6009618 SIG RR's were created The size of the zone file increased about a factor of 4.4, from 232 MByte to 1 GByte. 2. Converting the .de zone to a delegation-only zone. 2.1 We removed all the non-NS records from subzones, and inserted delegations (2 NS records) instead. The total number of domains stayed the same. 2.2 Statistics. SOA RR : 1 NS RR : 4060729 A RR : 10301 Domains: 1976902 Size : 117 MByte 2.3 Signing the converted zone. (See part 1.4) 2.4 Results The time the signer needed was 16493 sec (4h18m13s). The following was done: 1 SOA RRsets was signed 1 NS RRsets was signed 9 A RRsets were signed 1966642 NXT RR's were created 1950988 NXT RR's were signed 1950999 SIG RR's were created The size of the zone file increased with about a factor of 3.2, from 117 MByte to 380 MByte. Regards, Roy Arends. -- roy@nlnetlabs.nl NLnetLabs tel +31208884551 Kruislaan 419 |\ || _ _|_ | _ |_ _ 1098 VA Amsterdam | \||__| )(-|_ |__(_||_)_) The Netherlands to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Apr 27 10:48:43 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01458 for ; Thu, 27 Apr 2000 10:48:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12koX2-000539-00 for namedroppers-data@psg.com; Thu, 27 Apr 2000 06:40:40 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12koX1-000533-00 for namedroppers@ops.ietf.org; Thu, 27 Apr 2000 06:40:39 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12koX0-000K5J-00 for namedroppers@ops.ietf.org; Thu, 27 Apr 2000 06:40:38 -0700 Date: Thu, 27 Apr 2000 13:30:16 +0200 (CEST) From: Roy Arends To: dnsop@cafax.se, namedroppers@ops.ietf.org Subject: Signing .de zone, different keysizes. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This was just sent to the DNSSEC-WG at CENTR. ---------- Forwarded message ---------- Date: Thu, 27 Apr 2000 13:28:25 +0200 (CEST) From: Roy Arends To: dnssec-wg@lists.centr.org Subject: [centr-dnssec-wg]Signing .de zone, different keysizes. Hello, Some more statistics on signing the .de zone. KEYsize USR+SYS (HMS) TimeFactor Filesize GrowthFactor DSA-512 15493 ( 4h18m13s) 1 399275361 (380Mb) 3.24 DSA-768 23712 ( 6h35m12s) 1.53 399275361 (380Mb) 3.24 RSA-512 22645 ( 6h17m25s) 1.46 462208257 (440Mb) 3.76 RSA-768 53874 (14h57m54s) 3.48 544807683 (519Mb) 4.43 The labels: KEYsize : The type and size of the key. USR+SYS : The USR+SYS time the signer process consumed in seconds. (HMS) : Usage and System time in Hours, Minutes, Seconds. TimeFactor : Time compared to a DSA-512 key Signing time. Filesize : File size of the signed file. GrowthFactor: Filesize compared to the unsigned filesize (123068233). The zone we've signed was converted to a delegation-only-zone (See previous mail). We used the signer that came with the distribution of BIND V9.0.0-b2. We generated keys with the keygen tool, also from the distribution of BIND V9.0.0-b2. The test-machine is an average off-the shelf pc with an athlon 500 MHz processor running FreeBSD 3.4 . Regards, Roy Arends Never hit a man with glasses. Hit him with a baseball bat. -- roy@nlnetlabs.nl NLnetLabs tel +31208884551 Kruislaan 419 |\ || _ _|_ | _ |_ _ 1098 VA Amsterdam | \||__| )(-|_ |__(_||_)_) The Netherlands to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body.