Received: from relay.tis.com by neptune.TIS.COM id aa25062; 4 Dec 95 1:04 EST Received: from callandor.cybercash.com(204.178.186.70) by relay.tis.com via smap (g3.0.1) id xma008877; Mon, 4 Dec 95 00:38:49 -0500 Received: by callandor.cybercash.com; id BAA17027; Mon, 4 Dec 1995 01:07:39 -0500 Received: from cybercash.com(204.254.34.52) by callandor.cybercash.com via smap (g3.0.3) id xma017021; Mon, 4 Dec 95 01:07:19 -0500 Received: by cybercash.com.cybercash.com (4.1/SMI-4.1) id AA18646; Mon, 4 Dec 95 01:03:44 EST Date: Mon, 4 Dec 1995 01:03:43 -0500 (EST) From: "Donald E. Eastlake 3rd" To: dns-security@TIS.COM Subject: minor edit Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I've done a new draft-ietf-dnssec-secext-07.txt. It just has some minor editorial changes, may of which have been mentioned on the list already (such as mentioning that the possible inclusion of SIG and/or NXT RRs in the authority section is a chnage from the previous standard). This was done too late for the draft cut off but is available from ~ftp.cybercash.com/pub/draft-ietf-dnssec-secext-07.txt. Donald ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)   Received: from relay.tis.com by neptune.TIS.COM id aa03842; 22 Dec 95 12:49 EST Received: by relay.tis.com; id HAA21949; Fri, 22 Dec 1995 07:57:01 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (g3.0.3) id xma021907; Fri, 22 Dec 95 07:56:44 -0500 Received: from sol.tis.com by tis.com (4.1/SUN-5.64) id AA00836; Fri, 22 Dec 95 12:49:07 EST Message-Id: <9512221749.AA00836@tis.com> To: dns-security@TIS.COM Subject: Foo Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <826.819654544.1@tis.com> Date: Fri, 22 Dec 1995 12:49:06 -0500 From: "David M. Balenson" Foo Regards, -DB --------------------------------------------------------------------------- David M. Balenson Trusted Information Systems, 3060 Washington Rd., Glenwood, MD 21738 USA balenson@tis.com; tel 301.854.5358; fax 301.854.5363   Received: from relay.tis.com by neptune.TIS.COM id aa19095; 28 Dec 95 10:25 EST Received: by relay.tis.com; id FAA09701; Thu, 28 Dec 1995 05:33:40 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (g3.0.3) id xma009673; Thu, 28 Dec 95 05:33:11 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02726; Thu, 28 Dec 95 10:25:27 EST Received: by relay.tis.com; id FAA09644; Thu, 28 Dec 1995 05:33:07 -0500 Received: from unknown(132.151.1.35) by relay.tis.com via smap (g3.0.3) id xma009632; Thu, 28 Dec 95 05:32:49 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09279; 28 Dec 95 10:07 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Cc: dns-security@TIS.COM From: Internet-Drafts@cnri.reston.va.us Reply-To: Internet-Drafts@cnri.reston.va.us Subject: I-D ACTION:draft-ietf-dnssec-as-map-03.txt Date: Thu, 28 Dec 95 10:07:30 -0500 Sender: cclark@cnri.reston.va.us Message-Id: <9512281007.aa09279@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Security Working Group of the IETF. Title : Mapping Autonomous Systems Number into the Domain Name System Author(s) : D. Eastlake Filename : draft-ietf-dnssec-as-map-03.txt Pages : 8 Date : 12/27/1995 One requirement of secure routing is that independent routing entities, such as those identified by Internet Autonomous System Numbers, be able to authenticate messages to each other. Modifications currently being developed (see draft-ietf-dnssec-secext-*.txt) to the Domain Name System will enable it to be used for authenticated public key distribution. This draft maps all Autonomous System numbers into DNS Domain Names so that the DNS can be used to distribute their public keys. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnssec-as-map-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-as-map-03.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dnssec-as-map-03.txt". NOTE: The mail server at ds.internic.net 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. For questions, please mail to Internet-Drafts@cnri.reston.va.us. 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@ds.internic.net" Content-Type: text/plain Content-ID: <19951227095836.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-as-map-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-as-map-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951227095836.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart--   Received: from relay.tis.com by neptune.TIS.COM id aa19055; 28 Dec 95 10:25 EST Received: by relay.tis.com; id FAA09703; Thu, 28 Dec 1995 05:33:40 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (g3.0.3) id xma009684; Thu, 28 Dec 95 05:33:13 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02729; Thu, 28 Dec 95 10:25:28 EST Received: by relay.tis.com; id FAA09645; Thu, 28 Dec 1995 05:33:08 -0500 Received: from unknown(132.151.1.35) by relay.tis.com via smap (g3.0.3) id xmaa09632; Thu, 28 Dec 95 05:32:50 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09293; 28 Dec 95 10:07 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Cc: dns-security@TIS.COM From: Internet-Drafts@cnri.reston.va.us Reply-To: Internet-Drafts@cnri.reston.va.us Subject: I-D ACTION:draft-ietf-dnssec-secext-07.txt Date: Thu, 28 Dec 95 10:07:38 -0500 Sender: cclark@cnri.reston.va.us Message-Id: <9512281007.aa09293@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Security Working Group of the IETF. Title : Domain Name System Security Extensions Author(s) : D. Eastlake, C. Kaufman Filename : draft-ietf-dnssec-secext-07.txt Pages : 45 Date : 12/27/1995 The Domain Name System (DNS) has become a critical operational part of the Internet infrastructure yet it has no strong security mechanisms to assure data integrity or authentication. Extensions to the DNS are described that provide these services to security aware resolvers or applications through the use of cryptographic digital signatures. These digital signatures are included in secured zones as resource records. Security can still be provided even through non-security aware DNS servers in many cases. The extensions also provide for the storage of authenticated public keys in the DNS. This storage of keys can support general public key distribution service as well as DNS security. The stored keys enable security aware resolvers to learn the authenticating key of zones in addition to those for which they are initially configured. Keys associated with DNS names can be retrieved to support other protocols. Provision is made for a variety of key types and algorithms. In addition, the security extensions provide for the optional authentication of DNS protocol transactions. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnssec-secext-07.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-secext-07.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dnssec-secext-07.txt". NOTE: The mail server at ds.internic.net 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. For questions, please mail to Internet-Drafts@cnri.reston.va.us. 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@ds.internic.net" Content-Type: text/plain Content-ID: <19951227100639.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-secext-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-secext-07.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951227100639.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart--   Received: from relay.tis.com by neptune.TIS.COM id aa19776; 28 Dec 95 11:12 EST Received: by relay.tis.com; id GAA10482; Thu, 28 Dec 1995 06:20:46 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (g3.0.3) id xma010479; Thu, 28 Dec 95 06:20:18 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA05559; Thu, 28 Dec 95 11:12:36 EST Received: by relay.tis.com; id GAA10476; Thu, 28 Dec 1995 06:20:16 -0500 Received: from callandor.cybercash.com(204.178.186.70) by relay.tis.com via smap (g3.0.3) id xma010474; Thu, 28 Dec 95 06:20:12 -0500 Received: by callandor.cybercash.com; id LAA04690; Thu, 28 Dec 1995 11:15:55 -0500 Received: from cybercash.com(204.254.34.52) by callandor.cybercash.com via smap (g3.0.3) id xma004687; Thu, 28 Dec 95 11:15:52 -0500 Received: by cybercash.com.cybercash.com (4.1/SMI-4.1) id AA24910; Thu, 28 Dec 95 11:12:04 EST Date: Thu, 28 Dec 1995 11:12:04 -0500 (EST) From: "Donald E. Eastlake 3rd" To: dns-security@TIS.COM Subject: Latest drafts Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII New draft-ietf-dnssec-secext and draft-ietf-dnssec-as-map drafts are out. There are minor editorial changes and clarifications in them both. The secext document now refers to algorithm 253 and the "expiration date" algorithm as it is normally expected to be used only in connection with dynamic update expiration date stamping. It also now states that a secure zone MUST have a KEY RR at every delegation point, even if it is just one with the no-key bit on to certify that the subzone is insecure. Since DNSSEC can also be used for general KEY distribution, I am considering allocating a bit in e KEY RR flags field as the "confidentiality" bit. The draft would say that a key retrieved from the DNS "MUST NOT" be used for information confidentiality unless this bit is on. This would have no effect on DNSSEC itself which provides authentication only. Possibly the current "no-key" bit could also be relabeled the "authentication" bit. This is in keeping with the general trend to provide means to distinguish authentication keys for confidentiality keys. Comments? Donald ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)   Received: from relay.tis.com by neptune.TIS.COM id aa23964; 3 Jan 96 12:18 EST Received: by relay.tis.com; id HAA09492; Wed, 3 Jan 1996 07:26:27 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (g3.0.3) id xma009483; Wed, 3 Jan 96 07:25:58 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA29079; Wed, 3 Jan 96 12:18:11 EST Received: by relay.tis.com; id HAA09480; Wed, 3 Jan 1996 07:25:57 -0500 Received: from callandor.cybercash.com(204.178.186.70) by relay.tis.com via smap (g3.0.3) id xma009478; Wed, 3 Jan 96 07:25:35 -0500 Received: by callandor.cybercash.com; id MAA17930; Wed, 3 Jan 1996 12:21:48 -0500 Received: from cybercash.com(204.254.34.52) by callandor.cybercash.com via smap (g3.0.3) id xma017902; Wed, 3 Jan 96 12:21:19 -0500 Received: by cybercash.com.cybercash.com (4.1/SMI-4.1) id AA07594; Wed, 3 Jan 96 12:16:53 EST Date: Wed, 3 Jan 1996 12:16:53 -0500 (EST) From: "Donald E. Eastlake 3rd" To: dns-security@TIS.COM Subject: Latest Draft Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Since there were no objections, I have submitted a new draft whose only substantive change is to reserve bit 2 of the KEY RR flags field as the "confidentiality" bit. Text is below. Donald .ti +5 Bit 2 is the "confidentiality" bit. The key retrieved via this RR must not be used for purposes of confidentiality in other protocols unless this bit is a one. It has no effect on DNS security as DNS security provides authentication only. ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)   Received: from relay.tis.com by neptune.TIS.COM id aa27761; 3 Jan 96 16:17 EST Received: by relay.tis.com; id LAA14111; Wed, 3 Jan 1996 11:25:28 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (g3.0.3) id xma014094; Wed, 3 Jan 96 11:25:01 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA20886; Wed, 3 Jan 96 16:17:12 EST Received: by relay.tis.com; id LAA14090; Wed, 3 Jan 1996 11:24:58 -0500 Received: from moe.iris.com(199.29.160.22) by relay.tis.com via smap (g3.0.3) id xma014087; Wed, 3 Jan 96 11:24:43 -0500 Received: by moe.iris.com (IBM OS/2 SENDMAIL VERSION 1.3.2)/1.0) id AA1757; Wed, 03 Jan 96 16:19:00 -0800 Message-Id: <9601040019.AA1757@moe.iris.com> Received: from InterNotes with "Lotus Notes Mail Gateway for SMTP" id FEC96B6C005CF441852562A60071B32A; Wed, 3 Jan 96 16:17:37 To: dee Cc: dns-security From: Charlie Kaufman/Iris Date: 3 Jan 96 16:00:02 EDT Subject: Re: Latest drafts Mime-Version: 1.0 Content-Type: Text/Plain This comment is late, and should be ignorred if it would hold up advancement of the spec. I think the "sense" of the key bit that says "this key may be used for confidentiality" is wrong. I can imagine several kinds of systems out there: some with a single key used for confidentiality and integrity, some that are incapable of confidentiality protection, and some with separate keys for the two purposes (I can imagine several reasons for this: export might demand a shorter key for confidentiality, export controls or employer policy might require that the confidentiality key be escrowed, or the user might back up the confidentiality key in a way that makes it easier to recover after loss but more subject to theft.) In the case where there are two keys, it's important that someone who compromises the confidentiality key not be able to use it to falsely authenticate (otherwise why bother with two keys). For that reason, it's really important that there be a bit associated with a key saying "this key good only for confidentiality". It is less important that the integrity key not be used for confidentiality - if someone does that, the transaction will fail because the owner's software may refuse to decrypt the data - but this is failure in the "safe" direction. Ideally, I'd like to see two bits associated with the key: (good for integrity, good for confidentiality) with three states (good for nothing is not useful). If we have to settle for one bit, it ought to be "confidentiality-only". The only use I can imagine for securely marking a key as "not-for-confidentiality" is to securely tell the other party in a communication that confidentiality is not supported. This doesn't belong as a bit on the key, though, since a two key system would be capable of confidentiality even though one of its keys would be so marked. --Charlie (charlie_kaufman@iris.com)   Received: from relay.tis.com by neptune.TIS.COM id aa28635; 3 Jan 96 17:11 EST Received: by relay.tis.com; id MAA15508; Wed, 3 Jan 1996 12:19:29 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (g3.0.3) id xma015500; Wed, 3 Jan 96 12:19:00 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA25556; Wed, 3 Jan 96 17:11:13 EST Received: by relay.tis.com; id MAA15495; Wed, 3 Jan 1996 12:18:59 -0500 Received: from callandor.cybercash.com(204.178.186.70) by relay.tis.com via smap (g3.0.3) id xma015486; Wed, 3 Jan 96 12:18:36 -0500 Received: by callandor.cybercash.com; id RAA22498; Wed, 3 Jan 1996 17:14:50 -0500 Received: from cybercash.com(204.254.34.52) by callandor.cybercash.com via smap (g3.0.3) id xma022496; Wed, 3 Jan 96 17:14:44 -0500 Received: by cybercash.com.cybercash.com (4.1/SMI-4.1) id AA10865; Wed, 3 Jan 96 17:10:17 EST Date: Wed, 3 Jan 1996 17:10:16 -0500 (EST) From: "Donald E. Eastlake 3rd" To: Charlie Kaufman/Iris Cc: dns-security Subject: Re: Latest drafts In-Reply-To: <9601040017.AA1753@moe.iris.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I agree that a two bit field would be better. My first though was to move the experimetnal bit to bit 2 and make bits 0 and 1 a two bit field with bit 0 meaning use for authentication prohibited and bit 1 meaning use for confidentiality prohibited. 11 would be meaningful and mean "no key" so it is slightly compatible with current use where bit zero on means "no key". 10 would be confidentiality only, 01 would be authentication only, and 00 would mean it could be used for both. The reason I didn't propose this was that it seemed a bigger change. But there really isn't much "deployed base" right now and probably even fewer that are actually using the "experimental bit" so maybe we should just go ahead with this change. Donald On 3 Jan 1996, Charlie Kaufman/Iris wrote: > This comment is late, and should be ignorred if it would hold up advancement of > the spec. > > I think the "sense" of the key bit that says "this key may be used for > confidentiality" is wrong. I can imagine several kinds of systems out there: > some with a single key used for confidentiality and integrity, some that are > incapable of confidentiality protection, and some with separate keys for the > two purposes (I can imagine several reasons for this: export might demand a > shorter key for confidentiality, export controls or employer policy might > require that the confidentiality key be escrowed, or the user might back up the > confidentiality key in a way that makes it easier to recover after loss but > more subject to theft.) > > In the case where there are two keys, it's important that someone who > compromises the confidentiality key not be able to use it to falsely > authenticate (otherwise why bother with two keys). For that reason, it's really > important that there be a bit associated with a key saying "this key good only > for confidentiality". It is less important that the integrity key not be used > for confidentiality - if someone does that, the transaction will fail because > the owner's software may refuse to decrypt the data - but this is failure in > the "safe" direction. > > Ideally, I'd like to see two bits associated with the key: (good for integrity, > good for confidentiality) with three states (good for nothing is not useful). > If we have to settle for one bit, it ought to be "confidentiality-only". The > only use I can imagine for securely marking a key as "not-for-confidentiality" > is to securely tell the other party in a communication that confidentiality is > not supported. This doesn't belong as a bit on the key, though, since a two key > system would be capable of confidentiality even though one of its keys would be > so marked. > > --Charlie > (charlie_kaufman@iris.com) > > ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)   Received: from relay.tis.com by neptune.TIS.COM id aa11494; 4 Jan 96 10:32 EST Received: by relay.tis.com; id FAA23995; Thu, 4 Jan 1996 05:40:33 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (g3.0.3) id xma023989; Thu, 4 Jan 96 05:40:27 -0500 Received: from polar.tis.com by tis.com (4.1/SUN-5.64) id AA01618; Thu, 4 Jan 96 10:32:39 EST Message-Id: <9601041532.AA01618@tis.com> To: "Donald E. Eastlake 3rd" , Charlie Kaufman/Iris MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM Cc: dns-security Subject: Re: Latest drafts In-Reply-To: Your message of "Wed, 03 Jan 1996 17:10:16 EST." Date: Thu, 04 Jan 1996 10:32:37 -0500 From: Olafur Gudmundsson "Donald E. Eastlake 3rd" writes: > I agree that a two bit field would be better. My first though was to move > the experimetnal bit to bit 2 and make bits 0 and 1 a two bit field with bit > 0 meaning use for authentication prohibited and bit 1 meaning use for > confidentiality prohibited. 11 would be meaningful and mean "no key" so it > is slightly compatible with current use where bit zero on means "no key". 1 >>0 > would be confidentiality only, 01 would be authentication only, and 00 would > mean it could be used for both. The reason I didn't propose this was that i >>t > seemed a bigger change. But there really isn't much "deployed base" right > now and probably even fewer that are actually using the "experimental bit" s >>o > maybe we should just go ahead with this change. > > Donald > Donald, and Charlie, We are running out of bits, there will now be 3 bits unassinged. Do we at this point want to a) extend the flags field b) put in an extensions mechanism, by reserving an extension bit. c) declare this is it. I strongly discourage option b. Olafur   Received: from relay.tis.com by neptune.TIS.COM id aa12540; 4 Jan 96 11:39 EST Received: by relay.tis.com; id GAA25435; Thu, 4 Jan 1996 06:47:33 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (g3.0.3) id xma025431; Thu, 4 Jan 96 06:47:05 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA06157; Thu, 4 Jan 96 11:39:17 EST Received: by relay.tis.com; id GAA25422; Thu, 4 Jan 1996 06:47:03 -0500 Received: from callandor.cybercash.com(204.178.186.70) by relay.tis.com via smap (g3.0.3) id xma025414; Thu, 4 Jan 96 06:46:57 -0500 Received: by callandor.cybercash.com; id LAA03634; Thu, 4 Jan 1996 11:41:57 -0500 Received: from cybercash.com(204.254.34.52) by callandor.cybercash.com via smap (g3.0.3) id xma003630; Thu, 4 Jan 96 11:41:29 -0500 Received: by cybercash.com.cybercash.com (4.1/SMI-4.1) id AA17853; Thu, 4 Jan 96 11:36:54 EST Date: Thu, 4 Jan 1996 11:36:54 -0500 (EST) From: "Donald E. Eastlake 3rd" To: Olafur Gudmundsson Cc: Charlie Kaufman/Iris , dns-security , "Donald E. Eastlake" Subject: Re: Latest drafts In-Reply-To: <9601041532.AA01618@tis.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Actually, I think there are four bits left: 3-4 & 10-11 although bits 8 and 9 are not really used, just reserved. My inclination is to say this is it. Donald On Thu, 4 Jan 1996, Olafur Gudmundsson wrote: > > "Donald E. Eastlake 3rd" writes: > > I agree that a two bit field would be better. My first though was to move > > the experimetnal bit to bit 2 and make bits 0 and 1 a two bit field with bit > > 0 meaning use for authentication prohibited and bit 1 meaning use for > > confidentiality prohibited. 11 would be meaningful and mean "no key" so it > > is slightly compatible with current use where bit zero on means "no key". 1 > >>0 > > would be confidentiality only, 01 would be authentication only, and 00 would > > mean it could be used for both. The reason I didn't propose this was that i > >>t > > seemed a bigger change. But there really isn't much "deployed base" right > > now and probably even fewer that are actually using the "experimental bit" s > >>o > > maybe we should just go ahead with this change. > > > > Donald > > > Donald, and Charlie, > We are running out of bits, there will now be 3 bits unassinged. > Do we at this point want to > a) extend the flags field > b) put in an extensions mechanism, by reserving an extension bit. > c) declare this is it. > > I strongly discourage option b. > > Olafur > ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)   Received: from relay.tis.com by neptune.TIS.COM id aa05213; 5 Jan 96 15:27 EST Received: by relay.tis.com; id KAA02191; Fri, 5 Jan 1996 10:35:45 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (g3.0.3) id xma002180; Fri, 5 Jan 96 10:35:22 -0500 Received: from antares.tis.com by tis.com (4.1/SUN-5.64) id AA06621; Fri, 5 Jan 96 15:27:33 EST Message-Id: <9601052027.AA06621@tis.com> Reply-To: James M Galvin To: dns-security@TIS.COM Subject: the *last* DNSSEC draft Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <11996.820873745.1@tis.com> Date: Fri, 05 Jan 1996 15:29:06 -0500 From: James M Galvin Eastlake/Kaufman have submitted the *last* draft of the DNSSEC specification to internet-drafts. I expect it will be announced by tuesday or wednesday of next week. As Chair I'm "banging the gavel". As soon as this document is announced you will have 24 hours to identify any new, fatal technical flaws/errors. Twenty-four hours is more than enough time since this document has been in working group last call since the last IETF meeting. If you have a problem with this contact me directly immediately. After that the document will be "officially" remanded to the security area director to be published as a Proposed Standard. Thanks for all your hard work. Time to move on to dynamic update issues. Jim   Received: from relay.tis.com by neptune.TIS.COM id aa16102; 11 Jan 96 11:04 EST Received: by relay.tis.com; id GAA10818; Thu, 11 Jan 1996 06:12:19 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (g3.0.3) id xma010812; Thu, 11 Jan 96 06:11:57 -0500 Received: from sol.tis.com by tis.com (4.1/SUN-5.64) id AA23659; Thu, 11 Jan 96 11:04:03 EST Message-Id: <9601111604.AA23659@tis.com> To: dns-security@TIS.COM Subject: Program Announcement - ISOC 1996 Symp. Netw. & Distr. Sys. Security Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <23645.821376239.1@tis.com> Date: Thu, 11 Jan 1996 11:04:01 -0500 From: "David M. Balenson" ------------------------------------------------------------------------------ THE INTERNET SOCIETY 1996 SYMPOSIUM ON NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS '96) 22-23 FEBRUARY 1996 SAN DIEGO PRINCESS RESORT, SAN DIEGO, CALIFORNIA The symposium will bring together people who are building software and/or hardware to provide network and distributed system security services. The symposium is intended for those interested in the more practical aspects of network and distributed system security, focusing on actual system design and implementation, rather than in theory. We hope to foster the exchange of technical information that will encourage and enable the Internet community to apply, deploy and advance the state of the available security technology. ------------------------------------------------------------------------------ P R E L I M I N A R Y P R O G R A M WEDNESDAY, FEBRUARY 21 6:00 P.M. - 8:00 P.M. RECEPTION - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - THURSDAY, FEBRUARY 22 7:30 A.M. CONTINENTAL BREAKFAST 8:30 A.M. OPENING REMARKS 9:00 A.M. SESSION 1: ELECTRONIC MAIL SECURITY Chair: Stephen T. Kent (BBN Corporation, USA) Mixing E-mail with BABEL, Gene Tsudik and Ceki Gulcu (IBM Research Division, Zurich Research Laboratory, SWITZERLAND) An Integration of PGP and MIME, Kazuhiko Yamamoto (Nara Institute of Science and Technology, JAPAN) 10:00 A.M. BREAK 10:30 A.M. SESSION 2: DISTRIBUTED OBJECT SYSTEMS Chair: Dan Nessett (Sun Microsystems, USA) A Security Framework Supporting Domain Based Access Control in Distributed Systems, Nicholas Yialelis and Morris Sloman (Imperial College, London, UNITED KINGDOM) PANEL: Scalability of Security in Distributed Object Systems Chair: Dan Nessett (Sun Microsystems, USA) Panelists: Dan Nessett (Sun Microsystems, USA), Nicholas Yialelis (Imperial College, London, UNITED KINGDOM), and Bret Hartman (Odyssey Research Associates, USA) 12:00 NOON LUNCH 1:30 P.M. SESSION 3: DISTRIBUTED SYSTEM SECURITY Chair: Michael Roe (University of Cambridge, UNITED KINGDOM) A Flexible Distributed Authorization Protocol, Jonathan Trostle (CyberSAFE, USA) and B. Clifford Neuman (Information Sciences Institute, University of Southern California, USA) Preserving Integrity in Remote File Location and Retrieval, Trent Jaeger (University of Michigan, USA) and Aviel D. Rubin (Bellcore, USA) C-HTTP - The Development of a Secure, Closed HTTP-Based Network on the Internet, Takahiro Kiuchi (University of Tokyo, JAPAN) and Shigekoto Kaihara (University of Tokyo Hospital, JAPAN) 3:00 P.M. BREAK 3:30 P.M. SESSION 4: PANEL: INTELLECTUAL PROPERTY PROTECTION Chair: Peter Neumann (SRI International, USA) Panelists: David Bernstein (Electronic Publishing Resources, USA), Russ Housley (Spyrus, USA), and Dan Boneh (Princeton University, USA) 7:00 P.M. DINNER BANQUET - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - FRIDAY, FEBRUARY 23 7:30 A.M. CONTINENTAL BREAKFAST 8:30 A.M. SESSION 5: NETWORK SECURITY Chair: Matt Bishop (University of California at Davis, USA) Designing an Academic Firewall: Policy, Practice and Experience with SURF, Michael B. Greenwald, Sandeep K. Singhal, Jonathan R. Stone, and David R. Cheriton (Stanford University, USA) Digital Signature Protection of the OSPF Routing Protocol, Sandra Murphy and Madelyn Badger (Trusted Information Systems, USA) A Case Study of Secure ATM Switch Booting, Shaw-Cheng Chuang and Michael Roe (University of Cambridge, UNITED KINGDOM) 10:00 A.M. BREAK 10:30 A.M. SESSION 6: KEY MANAGEMENT Chair: Burt Kaliski (RSA Laboratories, USA) SKEME: A Versatile Secure Key Exchange Mechanism for Internet, Hugo Krawczyk (IBM T.J. Watson Research Center, USA) IDUP and SPKM: Developing Public-Key-Based APIs and Mechanisms for Communication Security Services, Carlisle Adams (Bell-Northern Research, CANADA) 11:30 A.M. LUNCH 1:00 P.M. SESSION 7: ENCRYPTION Chair: Paul Lambert (Oracle, USA) An Empirical Study of Secure MPEG Video Transmissions, Iskender Agi and Li Gong (SRI International, USA) Parallelized Network Security Protocols, Erich Nahum and David J. Yates (University of Massachusetts, USA), Sean O'Malley, Hilarie Orman and Richard Schroeppel (University of Arizona, USA) A "Bump in the Stack" Encryptor for MS-DOS Systems, David A. Wagner (University of California at Berkeley, USA) and Steven M. Bellovin (AT&T Bell Laboratories, USA) 2:30 P.M. BREAK 3:00 P.M. SESSION 8: PANEL: PUBLIC-KEY INFRASTRUCTURE Chair: Warwick Ford (Bell Northern Research, CANADA) Panelists: John Wankmueller (MasterCard International, USA), Taher ElGamal (Netscape Communications, USA), and Michael Baum (VeriSign, USA). ------------------------------------------------------------------------------ GENERAL CHAIR: Jim Ellis, CERT Coordination Center PROGRAM CHAIRS: David Balenson, Trusted Information Systems B. Clifford Neuman, USC Information Sciences Institute PROGRAM COMMITTEE: Tom Berson, Anagram Laboratories Matt Bishop, University of California at Davis Doug Engert, Argonne National Laboratory Warwick Ford, Bell Northern Research (Canada) Burt Kaliski, RSA Laboratories Steve Kent, BBN Corporation Paul Lambert, Oracle John Linn, OpenVision Technologies Teresa Lunt, Advanced Research Projects Agency Dan Nessett, Sun Microsystems Hilarie Orman, University of Arizona Michael Roe, Cambridge University (UK) Rob Rosenthal, U.S. National Institute of Standards and Technology Avi Rubin, Bellcore Jeff Schiller, Massachusetts Institute of Technology Rob Shirey, BBN Corporation Doug Tygar, Carnegie Mellon University Roberto Zamparo, Telia Research (Sweden) LOCAL ARRANGEMENTS CHAIR: Thomas Hutton, San Diego Supercomputer Center PUBLICATIONS CHAIR: Steve Welke, Institute for Defense Analyses REGISTRATIONS CHAIR: Donna Leggett, Internet Society STEERING GROUP Internet Research Task Force, Privacy and Security Research Group ------------------------------------------------------------------------------ BEAUTIFUL SAN DIEGO PRINCESS RESORT Location The Symposium venue is the San Diego Princess Resort, a tropical paradise on a forty-four acre island in Mission Bay, ten minutes from the international airport. Lush gardens landscaped with hundreds of species of tropical and subtropical plants are always ablaze with color and perfect for themed group events. Charming pathways wander among sparkling waterfalls, across quaint footbridges and sleepy lagoons filled with water lilies and waterfowl. A white sand beach curves around the island for over a mile, and the award-winning grounds encompass five swimming pools and six lighted tennis courts. Spouses and family members can catch a convenient Harbor Hopper for a quick trip to Sea World. After the Symposium, plan to spend the weekend visiting La Jolla, the world famous San Diego Zoo or Mexico, only 30 minutes by car or Trolley. Housing Information We have reserved a special block of sleeping rooms at the San Diego Princess Resort at the following rates: Lanai Patio & Garden View Rooms $ 81* Lanai Garden & Lagoon View Rooms $112 One Bedroom Suite $115 * This represents the Government Rate for San Diego. We have a limited number of rooms available at this rate. If you need a government rate, reserve your room early! You must present a valid government id upon check- in. Based on room type and space availability, these special group rates are applicable two days prior to and two days after the symposium. Current Room Tax is 10.5%. Check-in availability cannot be committed prior to 4:00 p.m. Check-out time is 12:00 noon. The San Diego Princess Resort will make every effort to accommodate any early arrivals, so make sure you give them your arrival time when you make your reservation. To make a reservation Contact the San Diego Princess Resort at 1-800-344-2626 (+1-619-274-4630 if outside the United States). To receive the special group rates, reservations must be made no later than January 20, 1996. CLIMATE February weather in San Diego is normally very pleasant. Early morning temperatures average 55 degrees while afternoon temperatures average 67 degrees. Generally, a light jacket or sweater is adequate during February; although, occasionally it rains. REGISTRATION FEES ISOC Non- Members Member Early registration (postmarked by Jan. 19) $295 $330 Late registration $365 $400 REGISTRATION INCLUDES - Attendance - Symposium Proceedings - Two luncheons - Reception - Banquet - Coffee Breaks FOR MORE INFORMATION on registration contact Donna Leggett by phone at 703-648-9888 or via e-mail to Ndss96reg@isoc.org. WEB PAGE - Additional information about the symposium and San Diego, as well as an on-line registration form, are available via the Web at: http://www.isoc.org/conferences/ndss96 ------------------------------------------------------------------------------ Internet Society Symposium on Network and Distributed System Security 22-23 February, 1996 San Diego, California, USA Registration Form --------------------------------------------------------------------------- Fill out this form and FAX it to NDSS'96 Registration (703) 648-9887, send it via electronic mail to Ndss96reg@isoc.org, or mail it to NDSS96, 12020 Sunrise Valley Drive, Suite 210, Reston, VA, 22091, USA --------------------------------------------------------------------------- Personal Information __Mr __Ms __Mrs __Dr __Prof __M __Prof Dr __Dip Ing __Ing __Miss __Mlle First Name: __________________________ Middle Name: _______________ Family Name: __________________________ __sr __jr __II __III __PhD Please enter your name as you would like it to appear on your conference name tag. Badge Name: _____________________________ Contact Information Your title: _____________________________ Your affiliation: _____________________________ Your address: _____________________________ _____________________________ City: _____________________________ State or Province: _____________________________ Postal Code: _____________ Country: _____________________________ Tel (work) Number: _____________________________ Tel (home) Number: _____________________________ Fax Number: _____________________________ EMail address: _____________________________ Special Needs? Do you have any special needs (vegetarian meals, wheelchair access, etc?): _________________________________________________________________________ _________________________________________________________________________ Appear on the Registrants List? ___ Please check here if you would NOT like your name included in the list of registrants. Payment Information All Payments must be in United States Dollars. Conference Charges If you are an Internet Society member, you are eligible for a reduced registration fee. Non-member symposium attendees will receive a one year Internet Society membership as part of the non-member registration fees. Check one: Before After January 19 January 19 ---------- ---------- ___Internet Society Member Conference Fee US$ 295.00 US$ 365.00 ___Non-Member Conference Fee US$ 330.00 US$ 400.00 Method of Payment 1. __ Check Make payable to the Internet Society. Checks must be postmarked before February 16, 1996 or you will not be registered. 2. __ Credit Card __ American Expres __ Mastercard __ Visa Name on Credit Card:__________________________ Credit Card Number:__________________________ Expiration Date:__________ 3. __ First Virtual First Virtual Account Number: _________________________ 4. __ Wire Transfer* Riggs Bank of Virginia Bank ABA number: 056001260 8315 Lee Highway Account number: Internet Society 148 387 10 Fairfax VA 22031 USA Wire Transfer Confirmation Number:____________________________ * Please process wire transfer before sending the registration form. 5. __ U.S. Government Purchase order* Please provide the P.O. Number: ___________________________ * Please fax or mail a copy of your purchase order along with your registration form. Cancellation Policy ------------------- Refunds will be issued for cancellations received before February 16, 1996. No refunds will be issued after February 16, 1996. ---------------------------------------------------------------------------   Received: from relay.tis.com by neptune.TIS.COM id aa17695; 11 Jan 96 13:06 EST Received: by relay.tis.com; id IAA01476; Thu, 11 Jan 1996 08:15:10 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (g3.0.3) id xma001462; Thu, 11 Jan 96 08:14:42 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA06795; Thu, 11 Jan 96 13:06:49 EST Received: by relay.tis.com; id IAA01457; Thu, 11 Jan 1996 08:14:40 -0500 Received: from ietf.cnri.reston.va.us(132.151.1.35) by relay.tis.com via smap (g3.0.3) id xma001450; Thu, 11 Jan 96 08:14:11 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10469; 11 Jan 96 10:37 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Cc: dns-security@TIS.COM From: Internet-Drafts@cnri.reston.va.us Reply-To: Internet-Drafts@cnri.reston.va.us Subject: I-D ACTION:draft-ietf-dnssec-secext-08.txt Date: Thu, 11 Jan 96 10:36:49 -0500 Sender: cclark@cnri.reston.va.us Message-Id: <9601111037.aa10469@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Security Working Group of the IETF. Title : Domain Name System Security Extensions Author(s) : D. Eastlake, C. Kaufman Filename : draft-ietf-dnssec-secext-08.txt Pages : 45 Date : 01/05/1996 The Domain Name System (DNS) has become a critical operational part of the Internet infrastructure yet it has no strong security mechanisms to assure data integrity or authentication. Extensions to the DNS are described that provide these services to security aware resolvers or applications through the use of cryptographic digital signatures. These digital signatures are included in secured zones as resource records. Security can still be provided even through non-security aware DNS servers in many cases. The extensions also provide for the storage of authenticated public keys in the DNS. This storage of keys can support general public key distribution service as well as DNS security. The stored keys enable security aware resolvers to learn the authenticating key of zones in addition to those for which they are initially configured. Keys associated with DNS names can be retrieved to support other protocols. Provision is made for a variety of key types and algorithms. In addition, the security extensions provide for the optional authentication of DNS protocol transactions. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnssec-secext-08.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-secext-08.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dnssec-secext-08.txt". NOTE: The mail server at ds.internic.net 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. For questions, please mail to Internet-Drafts@cnri.reston.va.us. 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@ds.internic.net" Content-Type: text/plain Content-ID: <19960105170813.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-secext-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-secext-08.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960105170813.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart--   Received: from relay.tis.com by neptune.TIS.COM id aa28079; 27 Jan 96 0:37 EST Received: by relay.tis.com; id AAA11348; Sat, 27 Jan 1996 00:38:32 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (g3.0.3) id xma011341; Sat, 27 Jan 96 00:38:03 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA22493; Sat, 27 Jan 96 00:37:09 EST Received: by relay.tis.com; id AAA11338; Sat, 27 Jan 1996 00:38:02 -0500 Received: from callandor.cybercash.com(204.178.186.70) by relay.tis.com via smap (g3.0.3) id xma011336; Sat, 27 Jan 96 00:37:44 -0500 Received: by callandor.cybercash.com; id AAA21276; Sat, 27 Jan 1996 00:42:56 -0500 Received: from cybercash.com(204.254.34.52) by callandor.cybercash.com via smap (g3.0.3) id xma021274; Sat, 27 Jan 96 00:42:35 -0500 Received: by cybercash.com.cybercash.com (4.1/SMI-4.1) id AA09142; Sat, 27 Jan 96 00:35:44 EST Date: Sat, 27 Jan 1996 00:35:44 -0500 (EST) From: "Donald E. Eastlake 3rd" To: dns-security@TIS.COM Subject: draft-ietf-dnssec-secext-09.txt Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I've posted a new version. Other than the date and file name, I believe that only section 4.1.3 has changed. This change was to clarify how the AXFR signature is calculated. The new version of 4.1.3 is below. Donald ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) "4.1.3 Zone Transfer (AXFR) SIG" The above SIG mechanisms assure the authentication of all zone signed RRs of a particular name, class and type. However, to efficiently assure the completeness of and secure zone transfers, a SIG RR owned by the zone name must be created with a type covered of AXFR that covers all RRs in the zone other than those signed by dynamic update keys and the SIG AXFR itself. The RRs are ordered and concatenated for hashing as described in Section 4.1.1. (See also ordering discussion in Section 5.1.) The AXFR SIG must be calculated last of all zone key signed SIGs in the zone. In effect, when signing the zone, you order, as described above, all RRs to be signed by the zone. You can then make one pass inserting all the zone SIGs. As you proceed you hash RRs into both an RRset hash and the zone hash. When the name or type changes you calculate and insert the RRset SIG, clear the RRset hash, and hash that SIG into the zone hash. When you have finished processing all the starting RRs as described above, you can then use the cumulative zone hash RR to calculate and insert an AXFR SIG covering the zone. Of course any computational technique producing the same results as above is permitted. The AXFR SIG really belongs to the zone as a whole, not to the zone name. Although it should be correct for the zone name, the labels field of an AXFR SIG is otherwise meaningless. The AXFR SIG is only retrieved as part of a zone transfer. After validation of the AXFR SIG, the zone MAY be considered valid without verification of the internal zone signed SIGs in the zone; however, any SIGs signed by entity keys or the like must still be validated. The AXFR SIG SHOULD be transmitted first in a zone transfer so the receiver can tell immediately that they may be able to avoid verifying other zone signed SIGs. RRs which are authenticated by a dynamic update key and not by the zone key (see Section 3.2) are not included in the AXFR SIG. They may originate in the network and might not, in general, be migrated to the recommended off line zone signing procedure (see Section 7.2). Thus, such RRs are not directly signed by the zone, are not included in the AXFR SIG, and are protected against omission from zone transfers only to the extent that the server and communication can be trusted. +end+   Received: from relay.tis.com by neptune.TIS.COM id aa18639; 30 Jan 96 10:07 EST Received: by relay.tis.com; id KAA16863; Tue, 30 Jan 1996 10:08:34 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (g3.0.3) id xma016856; Tue, 30 Jan 96 10:08:05 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA16395; Tue, 30 Jan 96 10:07:09 EST Received: by relay.tis.com; id KAA16853; Tue, 30 Jan 1996 10:08:04 -0500 Received: from ietf.cnri.reston.va.us(132.151.1.35) by relay.tis.com via smap (g3.0.3) id xma016849; Tue, 30 Jan 96 10:07:46 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11036; 30 Jan 96 9:27 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Cc: dns-security@TIS.COM From: Internet-Drafts@cnri.reston.va.us Reply-To: Internet-Drafts@cnri.reston.va.us Subject: I-D ACTION:draft-ietf-dnssec-secext-09.txt Date: Tue, 30 Jan 96 09:27:22 -0500 Sender: cclark@cnri.reston.va.us Message-Id: <9601300927.aa11036@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Security Working Group of the IETF. Title : Domain Name System Security Extensions Author(s) : D. Eastlake, C. Kaufman Filename : draft-ietf-dnssec-secext-09.txt Pages : 45 Date : 01/29/1996 The Domain Name System (DNS) has become a critical operational part of the Internet infrastructure yet it has no strong security mechanisms to assure data integrity or authentication. Extensions to the DNS are described that provide these services to security aware resolvers or applications through the use of cryptographic digital signatures. These digital signatures are included in secured zones as resource records. Security can still be provided even through non-security aware DNS servers in many cases. The extensions also provide for the storage of authenticated public keys in the DNS. This storage of keys can support general public key distribution service as well as DNS security. The stored keys enable security aware resolvers to learn the authenticating key of zones in addition to those for which they are initially configured. Keys associated with DNS names can be retrieved to support other protocols. Provision is made for a variety of key types and algorithms. In addition, the security extensions provide for the optional authentication of DNS protocol transactions. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnssec-secext-09.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-secext-09.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dnssec-secext-09.txt". NOTE: The mail server at ds.internic.net 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. For questions, please mail to Internet-Drafts@cnri.reston.va.us. 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@ds.internic.net" Content-Type: text/plain Content-ID: <19960129133506.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-secext-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-secext-09.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960129133506.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart--   Received: from relay.tis.com by neptune.TIS.COM id aa01249; 7 Feb 96 16:51 EST Received: by relay.tis.com; id QAA18059; Wed, 7 Feb 1996 16:52:48 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma018038; Wed, 7 Feb 96 16:52:19 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA23832; Wed, 7 Feb 96 16:51:27 EST Received: by relay.tis.com; id QAA18024; Wed, 7 Feb 1996 16:52:17 -0500 Received: from eitech.eit.com(192.100.58.2) by relay.tis.com via smap (V3.1) id xma018011; Wed, 7 Feb 96 16:51:52 -0500 Received: from [153.37.6.30] (pool057.Max6.Washington.DC.DYNIP.ALTER.NET [153.37.6.57]) by eitech.eit.com (8.6.12/8.6.12) with SMTP id NAA12501 for ; Wed, 7 Feb 1996 13:52:50 -0800 X-Sender: galvin@pop.eit.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 7 Feb 1996 16:55:53 -0400 To: dns-security@TIS.COM From: galvin@eit.com MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM Subject: migrating to majordomo management This mailing list, dns-security, will soon be migrated to majordomo management. You will know the migration is complete when you receive a welcome message from majordomo. The message will include all the instructions you need for getting off (or on) the list, but you're probably already familiar with them anyway. Enjoy, Jim ---------------------------------------------------------------------------- James M. Galvin galvin@eit.com Verifone/EIT, PO Box 220, Glenwood, MD 21738 +1 410.795.6882   Received: from relay.tis.com by neptune.TIS.COM id aa07700; 8 Feb 96 1:24 EST Received: by relay.tis.com; id BAA24383; Thu, 8 Feb 1996 01:25:31 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma024381; Thu, 8 Feb 96 01:25:03 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA05526; Thu, 8 Feb 96 01:24:11 EST Received: by relay.tis.com; id BAA24376; Thu, 8 Feb 1996 01:25:01 -0500 Received: from sun1.ncu.edu.tw(140.115.1.31) by relay.tis.com via smap (V3.1) id xma024372; Thu, 8 Feb 96 01:24:53 -0500 Received: (from center6@localhost) by sun1.ncu.edu.tw (8.7.3/8.7.3) id OAA00322; Thu, 8 Feb 1996 14:23:36 +0800 (CST) Date: Thu, 8 Feb 1996 14:23:35 +0800 (CST) From: "Melissa C.M. Liu" To: dns-security@TIS.COM Subject: unsubscribe Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8BIT unsubscribe exit  Received: from relay.tis.com by neptune.TIS.COM id aa12025; 12 Feb 96 11:17 EST Received: by relay.tis.com; id LAA22841; Mon, 12 Feb 1996 11:19:20 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma022827; Mon, 12 Feb 96 11:18:52 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA28432; Mon, 12 Feb 96 11:17:56 EST Received: by relay.tis.com; id LAA22824; Mon, 12 Feb 1996 11:18:50 -0500 Received: from ietf.cnri.reston.va.us(132.151.1.35) by relay.tis.com via smap (V3.1) id xma022809; Mon, 12 Feb 96 11:18:30 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa14760; 12 Feb 96 9:49 EST To: IETF-Announce: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Cc: dns-security@TIS.COM From: The IESG Subject: Last Call: Domain Name System Security Extensions to Proposed Standard Date: Mon, 12 Feb 96 09:49:39 -0500 Message-Id: <9602120949.aa14760@IETF.CNRI.Reston.VA.US> Sender: dns-security-request@neptune.tis.com Precedence: bulk The IESG has received a request from the Domain Name System Security Working Group to consider the following two Internet-Drafts for the status of Proposed Standards: 1. Domain Name System Security Extensions 2. Mapping Automous Systems Number into the Domain Name System The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@cnri.reston.va.us or ietf@cnri.reston.va.us mailing lists by February 26, 1996. Received: from relay.tis.com by neptune.TIS.COM id aa24677; 13 Feb 96 1:04 EST Received: by relay.tis.com; id BAA04924; Tue, 13 Feb 1996 01:06:21 -0500 From: bmanning@isi.edu MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma004922; Tue, 13 Feb 96 01:05:53 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA05241; Tue, 13 Feb 96 01:04:57 EST Received: by relay.tis.com; id BAA04917; Tue, 13 Feb 1996 01:05:52 -0500 Received: from venera.isi.edu(128.9.0.32) by relay.tis.com via smap (V3.1) id xma004913; Tue, 13 Feb 96 01:05:47 -0500 Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 12 Feb 1996 22:06:53 -0800 Posted-Date: Mon, 12 Feb 1996 22:02:23 -0800 (PST) Message-Id: <199602130602.AA27964@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Mon, 12 Feb 1996 22:02:23 -0800 Subject: Re: Last Call: Domain Name System Security Extensions to Proposed To: The IESG Date: Mon, 12 Feb 1996 22:02:23 -0800 (PST) Cc: IETF-Announce: @CNRI.Reston.VA.US:;, CNRI.Reston.VA.US@TIS.COM, dns-security@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM In-Reply-To: <9602120949.aa14760@IETF.CNRI.Reston.VA.US> from "The IESG" at Feb 12, 96 09:49:39 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 177 Sender: dns-security-request@neptune.tis.com Precedence: bulk > > 2. Mapping Automous Systems Number into the Domain Name System > I think it is about time for this draft to be advanced. -- --bill Received: from relay.tis.com by neptune.TIS.COM id aa01705; 14 Feb 96 12:09 EST Received: by relay.tis.com; id MAA01258; Wed, 14 Feb 1996 12:11:23 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma001250; Wed, 14 Feb 96 12:10:55 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA26347; Wed, 14 Feb 96 12:09:58 EST Received: by relay.tis.com; id MAA01242; Wed, 14 Feb 1996 12:10:53 -0500 Received: from bart.bbn.com(128.89.1.226) by relay.tis.com via smap (V3.1) id xma001237; Wed, 14 Feb 96 12:10:30 -0500 Received: from GAAK.BBN.COM by BART.BBN.COM id aa29086; 14 Feb 96 12:08 EST Date: Wed, 14 Feb 1996 12:06:29 EST Message-Id: To: Namedroppers@internic.net Cc: DNS-security@TIS.COM Subject: Expires RR proposal From: "Michael A. Patton" Sender: dns-security-request@neptune.tis.com Precedence: bulk At the last IETF there was some discussion about an RR to achieve the expiration features of the DNSSEC draft, but without the appearance of any security (or the requirement for the security overhead). Many people put forward good reasons for having this as a separate thing. I've put together a draft of a spec for this (extremely drafty :-). It's attached to this message, and I'd appreciate any feedback (both of the open questions in the document, and discussion on the list as to whether this is the right approach). In the document, meta comments are set off with [[[triple brackets]]] to isolate them from the main text. If people think it would be useful, we should consider some discussion (at the end of :-) the DNSIND meeting in LA (what's the deadline for submission? I think Friday, so get those comments in quick :-). -MAP ---------------------------------------------------------------- INTERNET DRAFT M. A. Patton Expiration Date: April 1996 BBN December 1995 Scheduled Expiration of DNS Resource Records Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). This Internet Draft expires April 1996. [[[Global issues for entire draft: Draft as written expires all RRs of a type together. This seems to be reasonable given some other discussions, but may be controversial. Since my inclination was towards treating a whole RR set the same already and I couldn't figure out a good way to be more fine-grained, I felt it was useful to do it this way, at least to start. For all these reasons, I will leave it as is, unless someone comes up with a compelling reason for it, AND a good design for how to do it. Do we need to expire CNAMES? Can't put an EXP there...unless we make EXP an exception to that rule. I think the DNSsec does this for SIGs...just extend that exemption? Should the SOA serial be updated when records expire? I think the same words that are in the DynDNS draft should be put here... Problem is that this can happen in both primary and secondary servers. Interaction with Dynamic Update. Do expired RRs appear to be there or not for the conditioning section of an update. May want them to appear to be there for several reasons 1) they need to be deleted for real (maybe); 2) may be trying to replace just around time of expire and not having them is a race condition; and 3) may have been used in conditioning because a recent query showed it there. On the other hand, these may want to be really gone once expired, because they're no longer visible to queries and therefore updates may assume they don't exist and say that in the conditional part... Should anything be said about expiring EXP RRs? This draft lets you do it, which can result in odd behaviour. On the other hand, I don't see why outlawing it is really needed (maybe someone will come up with a good use for this "feature"). ]]] Abstract This document describes an additional RR type for the Domain Name System[7,8] which provides for scheduled expiration of RRs in the DNS. These RRs record the time at which a referenced set of RRs are to be removed from the DNS. This can be used to provide the information required to automatically support the reduced TTLs described in RFC1034[8] when anticipating a change, and by being in the zone data, will communicate that information to other servers that recognize the RR, in particular, secondary servers that recieve the data by Zone Transfer (AXFR or IXFR[2]). Introduction [[[TBD]]] [[[Ref discussion in DNSIND and DNSSEC]]] 1. definition of the RR type The Expires RR is defined with mnemonic "EXP" and TYPE code [[[TBD]]] (decimal). The format is based slightly on the format used for the SIG RR in the DNS Security Extensions[1] The format of an Expires (EXP) RR is: 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / / / NAME / | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TYPE = EXP | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | CLASS = IN | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TTL | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | RDLENGTH | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | COVERS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TIME | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: * NAME: an owner name, i.e., the name of the DNS node to which this resource record pertains. * TYPE: two octets containing the EXP RR TYPE code of 31 (decimal). * CLASS: two octets containing the RR IN CLASS code of 1. * TTL: a 32 bit signed integer that specifies the time interval in seconds that the resource record may be cached before the source of the information should again be consulted. * RDLENGTH: 6 * COVERS: is the type code of the RR set that it covers or 255 to indicate that it applies to all RRs of the same name and class. This is a subset of the QTYPE defined in RFC1035. * TIME: The date and time that the referenced RRs are due to expire, represented as an unsigned number of seconds since the start of 1 January 1970, GMT, ignoring leap seconds. [[[It's been suggested to add an "Effective on" time or function. If that's desired by anyone, my temptation is to make it separate. For this to be useful, it (and EXP) would really need to apply to specific RRs rather than a whole RR set. This makes it hard. For all these reasons, I will leave it out, unless someone comes up with a compelling reason for it, AND a good design for how to do it. My inclination is that this should be done with something like adding an EXP, then at the "effective time" doing a DYNDNS update removing the EXP and the RRs it covers and adding the new ones. This probably requires that the expired RRs appear to be there whether they've expired or not for the purposes of update, but they may not be visible to queries, can we make this reasonable.]]] 2. Master File Format The format of EXP RRs follows all the rules of RFC 1035, Section 5, "Master Files." Example master file (based on the example in RFC1035): @ IN SOA VENERA Action.domains ( 20 ; SERIAL 7200 ; REFRESH 600 ; RETRY 3600000; EXPIRE 60) ; MINIMUM NS A.ISI.EDU. NS VENERA NS VAXA MX 10 VENERA MX 20 VAXA ; address record for host A is good until 8am, 1 Jan 1996 A A 26.3.0.103 EXP A 19960101080000 VENERA A 10.1.0.52 A 128.9.0.32 ; all address records for host VENERA are good until midnight, 31 May 1996 EXP A 19960531000000 ; no expiration for VAXA's addresses VAXA A 10.2.0.27 A 128.9.0.33 3. Handling of Expires RRs and RRS covered by them When an authoritative server [[[is this limitation good? bad? other?]]] returns any RR covered by an Expires RR, it must assure that the TTL is small enough that copies will not be cached beyond the given expiration time. Although the server does not need to actually remove expired RRs from its database, it must give the appearance of having done so when formulating replies to query or transfer requests. A simple algorithm for skipping over expired RRs or adjusting their TTL to match an expiration time is shown below: if expire > now { if (expire - now) > TTL { TTL = (expire - now) } include RR in reply } This algorithm makes the TTL just small enough to satisfy the EXP requirements. Some people have suggested more elaborate techniques to reduce the inherent inconsistencies introduced. Such an algorithm might be to use a two day TTL when the change is more than a week away, but a week ahead, start lowering the TTL such that 3 days before the change only 1 day TTLs are given out, and a day in advance it's down to a few hours, and a few hours in advance it's down to 30 minutes. The usefulness of this more gradual approach has been debated [[[do I have any references on this discussion???]]], but in any case it is a local matter as long as the TTL does not exceed that given by the simple algorithm above. 4. Additional Section Processing [[[Do we need this?]]] [[[Maybe suggest including them when they apply? Probably not useful.]]] 5. Acknowledgements The original arguments for this as a separate RR were put forward by Robert Elz in the DNSIND Working Group. Many others described uses and requirements that were the basis of this design. Comments and some explanatory text from Walt Lazear were helpful. I'd also like to thank Arnt Gulbrandsen for his collected list of DNS RFCs and permission to use it as the basis for the References section and Bill Manning, the author of RFC1348[4], for unwittingly supplying the boilerplate and diagrams I used as a basis for this document. Much of the layout of the RR was based on the work of Donald Eastlake and Charles Kaufman in the design of the DNS Security Extensions. 6. Security Considerations Security issues are not [[[yet]]] discussed in this memo. [[[Should any be???]]] [[[ EXP allows add permission to be turned into delete permission]]] [[[ interaction with DNSSEC, which has a different variant of expiration, and with secure update[TBD]. ]]] 7. References [1] DNSsec draft [[[fill in details]]] [2] IXFR draft [[[fill in details]]] [3] RFC 1536: A. Kumar, J. Postel, C. Neuman, P. Danzig, S. Miller, "Common DNS Implementation Errors and Suggested Fixes.", 10/06/1993. [4] RFC 1348: B. Manning, "DNS NSAP RRs", 07/01/1992. [5] RFC 1183: R. Ullman, P. Mockapetris, L. Mamakos, C. Everhart, "New DNS RR Definitions", 10/08/1990. [6] RFC 1101: P. Mockapetris, "DNS encoding of network names and other types", 04/01/1989. [7] RFC 1035: P. Mockapetris, "Domain names - implementation and specification", 11/01/1987. [8] RFC 1034: P. Mockapetris, "Domain names - concepts and facilities", 11/01/1987. [9] RFC 1033: M. Lottor, "Domain administrators operations guide", 11/01/1987. [10] RFC 1032: M. Stahl, "Domain administrators guide", 11/01/1987. [11] RFC 974: C. Partridge, "Mail routing and the domain system", 01/01/1986. 8. Authors' Address: Michael A. Patton Bolt Beranek and Newman 10 Moulton Street Cambridge, MA, 02138 Phone: (617) 873 2737 FAX: (617) 873 3457 Email: map@bbn.com This Internet Draft expires April 1996 Received: from relay.tis.com by neptune.TIS.COM id aa03656; 14 Feb 96 13:57 EST Received: by relay.tis.com; id NAA03705; Wed, 14 Feb 1996 13:59:07 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma003697; Wed, 14 Feb 96 13:58:39 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02107; Wed, 14 Feb 96 13:57:42 EST Received: by relay.tis.com; id NAA03693; Wed, 14 Feb 1996 13:58:37 -0500 Received: from watson.ibm.com(129.34.139.4) by relay.tis.com via smap (V3.1) id xma003685; Wed, 14 Feb 96 13:58:22 -0500 Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 7207; Wed, 14 Feb 96 13:59:14 EST Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.02 on VAGENT2" id 3514; Wed, 14 Feb 1996 13:59:14 EST Received: from edisto.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2Rx) with TCP; Wed, 14 Feb 96 13:59:14 EST Received: by edisto.watson.ibm.com (AIX 3.2/UCB 5.64/900524) id AA20309; Wed, 14 Feb 1996 14:00:11 -0500 Message-Id: <9602141900.AA20309@edisto.watson.ibm.com> X-External-Networks: yes To: Namedroppers@internic.net, DNS-security@TIS.COM Subject: Re: Expires RR proposal In-Reply-To: Your message of Wed, 14 Feb 96 12:06:29 EST. Date: Wed, 14 Feb 96 14:00:11 -0500 From: "Edie E. Gunter" Sender: dns-security-request@neptune.tis.com Precedence: bulk In light of DNSSEC, the EXP RR seems superfluous to me. Everything you can do with EXP, I can do with a SIG. I can't think of when I'd ever want to use EXP. (And in a 10,000 node zone, where each node has an A, KEY, and SIG RR, another 10,000 EXP RR's is going to be a hard sell, no?) I was actually at the Dallas meetings, but I missed the point behind defining a new RR to do something the SIG is more than capable of handling. Edie Received: from relay.tis.com by neptune.TIS.COM id aa09149; 14 Feb 96 16:58 EST Received: by relay.tis.com; id RAA07556; Wed, 14 Feb 1996 17:00:08 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma007540; Wed, 14 Feb 96 16:59:39 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA15228; Wed, 14 Feb 96 16:58:43 EST Received: by relay.tis.com; id QAA07537; Wed, 14 Feb 1996 16:59:38 -0500 Received: from bart.bbn.com(128.89.1.226) by relay.tis.com via smap (V3.1) id xma007534; Wed, 14 Feb 96 16:59:36 -0500 Received: from GAAK.BBN.COM by BART.BBN.COM id aa00832; 14 Feb 96 16:59 EST Date: Wed, 14 Feb 1996 16:57:54 EST Message-Id: To: edie@watson.ibm.com Cc: Namedroppers@internic.net, DNS-security@TIS.COM In-Reply-To: <9602141900.AA20309@edisto.watson.ibm.com> (edie@watson.ibm.com) Subject: Re: Expires RR proposal From: "Michael A. Patton" Sender: dns-security-request@neptune.tis.com Precedence: bulk Date: Wed, 14 Feb 96 14:00:11 -0500 From: "Edie E. Gunter" In light of DNSSEC, the EXP RR seems superfluous to me. That was my reaction when I first heard it mentioned in Dallas, but many discussions at DNSIND, DNSSEC, and in the corridors, convinced me that it was an interesting avenue to explore. Since I was thus on both sides of that question at different times, I figured I might be a good candidate to balance the exposition. Everything you can do with EXP, I can do with a SIG. I can't think of when I'd ever want to use EXP. The times you'd want to use an EXP are when your zone does not run security (which can happen for many reasons[*]) and thus you don't have SIGs. Even if you have some SIGs, using EXPs when what you want is expiration, rather than overloading the SIGs for this function may be simpler to manage (i.e. I could add EXPs by hand edit, I probably wouldn't hand edit a SIG) in some contexts. The original proposal (which is in the DNSSEC doc) was to use a SIG that didn't have any signature data (this has been variously called the NULL SIG algorithm or the "no security" algorithm). The security people were (rightfully, IMHO) somewhat leery of specifying in the DNS Security spec, something that gave no security. This concern came out clearly near the end of the DNSIND meeting. Thus the idea of a separate RR for when this is the functionality you want. Logically use of the EXP RR replaces use of the SIG RR with NULL algorithm. I was actually at the Dallas meetings, but I missed the point behind defining a new RR to do something the SIG is more than capable of handling. The discussion (as I recall) happened mostly at the end of the DNSIND meeting, very briefly at DNSSEC, and in the corridors in between. The basic reason is that there are valid uses for expiration above and beyond those required for DNSSEC, and since there may be reasons that security isn't run[*], having the expiration available as a separable part of the DNS seemed like the right idea. There is a placeholder in the document where I intended to put some of this discussion (in the intro), but I haven't had the time, yet. I'll save this message as a start on that... -MAP (*) Is it even legal in France and/or China to have SIG RRs on your server? (I don't know IANAL, especially in those countries :-). If I have a large isolated (small i) internet on which I trust everyone, why should I pay the cost of running crypto algorithms on all my DNS servers all the time just so I can expire some RRs occasionally? Received: from relay.tis.com by neptune.TIS.COM id aa23210; 15 Feb 96 10:31 EST Received: by relay.tis.com; id KAA16143; Thu, 15 Feb 1996 10:33:24 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma016140; Thu, 15 Feb 96 10:32:56 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13129; Thu, 15 Feb 96 10:31:59 EST Received: by relay.tis.com; id KAA16133; Thu, 15 Feb 1996 10:32:54 -0500 Received: from watson.ibm.com(129.34.139.4) by relay.tis.com via smap (V3.1) id xma016127; Thu, 15 Feb 96 10:32:45 -0500 Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 4255; Thu, 15 Feb 96 10:33:37 EST Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.02 on VAGENT2" id 5603; Thu, 15 Feb 1996 10:33:37 EST Received: from edisto.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2Rx) with TCP; Thu, 15 Feb 96 10:33:36 EST Received: by edisto.watson.ibm.com (AIX 3.2/UCB 5.64/900524) id AA20173; Thu, 15 Feb 1996 10:34:35 -0500 Message-Id: <9602151534.AA20173@edisto.watson.ibm.com> X-External-Networks: yes To: Namedroppers@internic.net, DNS-security@TIS.COM Subject: Re: Expires RR proposal In-Reply-To: Your message of Wed, 14 Feb 96 16:57:54 EST. Date: Thu, 15 Feb 96 10:34:35 -0500 From: "Edie E. Gunter" Sender: dns-security-request@neptune.tis.com Precedence: bulk > The original proposal (which is in the DNSSEC doc) was to use a SIG > that didn't have any signature data (this has been variously called > the NULL SIG algorithm or the "no security" algorithm). The security > people were (rightfully, IMHO) somewhat leery of specifying in the DNS > Security spec, something that gave no security. If this is the only argument, then why not remove SIG from the DNS Security spec into its own spec and allow it to be general purpose? Seriously. Rename it (if you like) and make the signature information optional. (Although I must ask, why is it okay to have a KEY RR with no key data, but it is NOT okay to have a SIG RR with no signature data?) > The times you'd want to use an EXP are when your zone does not run > security (which can happen for many reasons[*]) and thus you don't have > SIGs. Are EXP's disallowed in secure DNS? If not which expiration time will win -- that of the SIG or that of the EXP? Do we really want 2 set of rules regarding what happens to expired RRs -- DNSSEC says they appear as if they've been deleted; the EXP spec implies maybe not? We want dynamic updates to work the same whether you use security or not, right? I do. > Even if you have some SIGs, using EXPs when what you want is > expiration, rather than overloading the SIGs for this function may be > simpler to manage (i.e. I could add EXPs by hand edit, I probably > wouldn't hand edit a SIG) in some contexts. Ah, but simpler for who? A sysadmin surely doesn't need the duplication. And, editting a NULL SIG by hand is as simple as editting an EXP by hand, imho. Edie Received: from relay.tis.com by neptune.TIS.COM id aa03213; 19 Feb 96 17:28 EST Received: by relay.tis.com; id RAA14711; Mon, 19 Feb 1996 17:29:47 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma014704; Mon, 19 Feb 96 17:29:18 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA00296; Mon, 19 Feb 96 17:28:19 EST Received: by relay.tis.com; id RAA14701; Mon, 19 Feb 1996 17:29:17 -0500 Received: from callandor.cybercash.com(204.178.186.70) by relay.tis.com via smap (V3.1) id xma014699; Mon, 19 Feb 96 17:28:52 -0500 Received: by callandor.cybercash.com; id RAA11570; Mon, 19 Feb 1996 17:35:47 -0500 Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (g3.0.3) id xma011567; Mon, 19 Feb 96 17:35:42 -0500 Received: by cybercash.com.cybercash.com (4.1/SMI-4.1) id AA20674; Mon, 19 Feb 96 17:26:27 EST Date: Mon, 19 Feb 1996 17:26:27 -0500 (EST) From: "Donald E. Eastlake 3rd" To: "Edie E. Gunter" Cc: Namedroppers@internic.net, DNS-security@TIS.COM Subject: Re: Expires RR proposal In-Reply-To: <9602151534.AA20173@edisto.watson.ibm.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dns-security-request@neptune.tis.com Precedence: bulk I don't really care that much either way on the EXP RR but I think the primary argument for it was that you SIG's expiration dates may most easily be set all the same by an application that goest through and signs your zone. So an RR might expire in some higher sense either before or after its authenticating SIG expires. Data would not be considered valid if either the EXP or SIG had expired. Donald PS: The dns sec draft does include a "null" SIG and KEY RR so you can use these for expiration under the curretn dns sec draft if you want. On Thu, 15 Feb 1996, Edie E. Gunter wrote: > Date: Thu, 15 Feb 96 10:34:35 -0500 > From: Edie E. Gunter > To: Namedroppers@internic.net, DNS-security@TIS.COM > Subject: Re: Expires RR proposal > > > The original proposal (which is in the DNSSEC doc) was to use a SIG > > that didn't have any signature data (this has been variously called > > the NULL SIG algorithm or the "no security" algorithm). The security > > people were (rightfully, IMHO) somewhat leery of specifying in the DNS > > Security spec, something that gave no security. > > If this is the only argument, then why not remove SIG from the > DNS Security spec into its own spec and allow it to be general > purpose? Seriously. Rename it (if you like) and make the signature > information optional. > > (Although I must ask, why is it okay to have a KEY RR with no key > data, but it is NOT okay to have a SIG RR with no signature data?) > > > The times you'd want to use an EXP are when your zone does not run > > security (which can happen for many reasons[*]) and thus you don't have > > SIGs. > > Are EXP's disallowed in secure DNS? If not which expiration time > will win -- that of the SIG or that of the EXP? Do we really want > 2 set of rules regarding what happens to expired RRs -- DNSSEC > says they appear as if they've been deleted; the EXP spec implies > maybe not? We want dynamic updates to work the same > whether you use security or not, right? I do. > > > Even if you have some SIGs, using EXPs when what you want is > > expiration, rather than overloading the SIGs for this function may be > > simpler to manage (i.e. I could add EXPs by hand edit, I probably > > wouldn't hand edit a SIG) in some contexts. > > Ah, but simpler for who? A sysadmin surely doesn't need the duplication. > And, editting a NULL SIG by hand is as simple as editting > an EXP by hand, imho. > > Edie > ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html Received: from relay.tis.com by neptune.TIS.COM id aa22146; 22 Feb 96 2:26 EST Received: by relay.tis.com; id CAA25100; Thu, 22 Feb 1996 02:28:28 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma025098; Thu, 22 Feb 96 02:27:59 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13117; Thu, 22 Feb 96 02:26:58 EST Received: by relay.tis.com; id CAA25094; Thu, 22 Feb 1996 02:27:58 -0500 Received: from eitech.eit.com(192.100.58.2) by relay.tis.com via smap (V3.1) id xma025092; Thu, 22 Feb 96 02:27:29 -0500 Received: from [153.37.13.174] (pool046.Max18.Los-Angeles.CA.DYNIP.ALTER.NET [153.37.13.174]) by eitech.eit.com (8.6.12/8.6.12) with SMTP id XAA04578; Wed, 21 Feb 1996 23:27:05 -0800 X-Sender: galvin@pop.eit.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 22 Feb 1996 02:30:48 -0400 To: "Edie E. Gunter" From: "James M. Galvin" Subject: Re: Expires RR proposal Cc: Namedroppers@internic.net, DNS-security@TIS.COM Sender: dns-security-request@neptune.tis.com Precedence: bulk At 11:34 AM 2/15/96, Edie E. Gunter wrote: >> The original proposal (which is in the DNSSEC doc) was to use a SIG >> that didn't have any signature data (this has been variously called >> the NULL SIG algorithm or the "no security" algorithm). The security >> people were (rightfully, IMHO) somewhat leery of specifying in the DNS >> Security spec, something that gave no security. > >If this is the only argument, then why not remove SIG from the >DNS Security spec into its own spec and allow it to be general >purpose? Seriously. Rename it (if you like) and make the signature >information optional. You are missing the point. I was particularly vocal against the use of SIG RRs with no signature. It sounds like an oxymoron to me: here's a SIG RR to give you security; oh by the way there's no signature and thus no security. However, being sensitive to the needs of dynamic update in particular, there is clearly a need for an expiration time for RRs. So, the particular suggestion at the DNS security meeting was that the expiration RR be created (so that the concept is useful in general) and that the SIG RR would later be specified to disallow NULL signatures and might even have the expiration value removed in favor of this more general mechanism. The details of this suggestion will be visited when the specification is advanced from proposed to draft. >(Although I must ask, why is it okay to have a KEY RR with no key >data, but it is NOT okay to have a SIG RR with no signature data?) It is necessary to be able to state authoritatively, i.e., guarantee, that key does not exist for a given domain name. One mechanism by which this might be accomplished is to have a SIG record that always covered all RRs for a given domain. Thus, whenever you retrieve a KEY RR you would have to retrieve them all to verify that no KEY RR was intended to exist. A transaction SIG RR is also mechanism that could help this problem. However, it should be straightforward to see that being able to state authoritatively there is no key is a feature worth having. >> The times you'd want to use an EXP are when your zone does not run >> security (which can happen for many reasons[*]) and thus you don't have >> SIGs. > >Are EXP's disallowed in secure DNS? If not which expiration time >will win -- that of the SIG or that of the EXP? Do we really want >2 set of rules regarding what happens to expired RRs -- DNSSEC >says they appear as if they've been deleted; the EXP spec implies >maybe not? We want dynamic updates to work the same >whether you use security or not, right? I do. An expire RR only applies to the RR which it covers, as indicated by the COVER field in the RR. Thus, there should be no conflict. The only potential conflict I see is during the interim existence of both an EXP RR and the expiration in the SIG RR, which wins if there is an EXP RR that covers SIG RRs? My preference is the EXP RR wins, in deference to the migration path of eliminating the SIG RR expiration field. Jim ---------------------------------------------------------------------------- James M. Galvin galvin@eit.com VeriFone/EIT, PO Box 220, Glenwood, MD 21738 +1 410.795.6882 Received: from relay.tis.com by neptune.TIS.COM id aa20531; 23 Feb 96 9:49 EST Received: by relay.tis.com; id JAA22305; Fri, 23 Feb 1996 09:51:24 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma022302; Fri, 23 Feb 96 09:50:58 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA19475; Fri, 23 Feb 96 09:49:55 EST Received: by relay.tis.com; id JAA22292; Fri, 23 Feb 1996 09:50:54 -0500 Received: from ietf.cnri.reston.va.us(132.151.1.35) by relay.tis.com via smap (V3.1) id xma022285; Fri, 23 Feb 96 09:50:45 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa20581; 23 Feb 96 9:44 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Cc: dns-security@TIS.COM From: Internet-Drafts@cnri.reston.va.us Reply-To: Internet-Drafts@cnri.reston.va.us Subject: I-D ACTION:draft-ietf-dnssec-ddi-00.txt Date: Fri, 23 Feb 96 09:44:04 -0500 Message-Id: <9602230944.aa20581@IETF.CNRI.Reston.VA.US> Sender: dns-security-request@neptune.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Security Working Group of the IETF. Title : Detached Domain Name System Information Author(s) : D. Eastlake Filename : draft-ietf-dnssec-ddi-00.txt Pages : 8 Date : 02/22/1996 A standard format is defined for representing detached DNS information. This is anticipated to be of use for storing information retrieved from the Domain Name System (DNS) in archival contexts or contexts not connected to the Internet. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnssec-ddi-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-ddi-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dnssec-ddi-00.txt". NOTE: The mail server at ds.internic.net 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. For questions, please mail to Internet-Drafts@cnri.reston.va.us. 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@ds.internic.net" Content-Type: text/plain Content-ID: <19960222175802.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-ddi-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-ddi-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960222175802.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- Received: from relay.tis.com by neptune.TIS.COM id aa20779; 23 Feb 96 10:00 EST Received: by relay.tis.com; id KAA22557; Fri, 23 Feb 1996 10:01:54 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma022549; Fri, 23 Feb 96 10:01:25 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA20339; Fri, 23 Feb 96 10:00:23 EST Received: by relay.tis.com; id KAA22544; Fri, 23 Feb 1996 10:01:24 -0500 Received: from ietf.cnri.reston.va.us(132.151.1.35) by relay.tis.com via smap (V3.1) id xma022540; Fri, 23 Feb 96 10:01:22 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa20774; 23 Feb 96 9:46 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Cc: dns-security@TIS.COM From: Internet-Drafts@cnri.reston.va.us Reply-To: Internet-Drafts@cnri.reston.va.us Subject: I-D ACTION:draft-ietf-dnssec-update-00.txt Date: Fri, 23 Feb 96 09:46:05 -0500 Message-Id: <9602230946.aa20774@IETF.CNRI.Reston.VA.US> Sender: dns-security-request@neptune.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Security Working Group of the IETF. Title : Secure Domain Name System Dynamic Update Author(s) : D. Eastlake Filename : draft-ietf-dnssec-update-00.txt Pages : 15 Date : 02/22/1996 Domain Name System (DNS) protocol extensions have been defined to authenticate the data in DNS and provide key distribution service (draft-ietf-dnssec-secext-*.txt). DNS Dynamic Update operations have also been defined (draft-ietf-dnsind-dynDNS-*.txt>, but without a detailed description of strong security for the update operation. This draft describes how to use DNS digital signatures covering requests and data to secure updates and restrict them to those authorized to perform them as indicated by the updater's possession of cryptographic keys. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnssec-update-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-update-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dnssec-update-00.txt". NOTE: The mail server at ds.internic.net 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. For questions, please mail to Internet-Drafts@cnri.reston.va.us. 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@ds.internic.net" Content-Type: text/plain Content-ID: <19960222171824.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-update-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-update-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960222171824.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- Received: from relay.tis.com by neptune.TIS.COM id aa21945; 23 Feb 96 11:04 EST Received: by relay.tis.com; id LAA23979; Fri, 23 Feb 1996 11:06:26 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma023972; Fri, 23 Feb 96 11:05:58 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA25650; Fri, 23 Feb 96 11:04:56 EST Received: by relay.tis.com; id LAA23965; Fri, 23 Feb 1996 11:05:56 -0500 Received: from watson.ibm.com(129.34.139.4) by relay.tis.com via smap (V3.1) id xmaa23949; Fri, 23 Feb 96 11:05:28 -0500 Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 0803; Thu, 22 Feb 96 12:22:50 EST Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.02 on VAGENT2" id 5411; Thu, 22 Feb 1996 12:22:50 EST Received: from edisto.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2Rx) with TCP; Thu, 22 Feb 96 12:22:50 EST Received: by edisto.watson.ibm.com (AIX 3.2/UCB 5.64/900524) id AA18232; Thu, 22 Feb 1996 12:23:53 -0500 Message-Id: <9602221723.AA18232@edisto.watson.ibm.com> X-External-Networks: yes To: "James M. Galvin" Cc: Namedroppers@internic.net, DNS-security@TIS.COM Subject: Re: Expires RR proposal In-Reply-To: Your message of Thu, 22 Feb 96 02:30:48 D. Date: Thu, 22 Feb 96 12:23:53 -0500 From: "Edie E. Gunter" Sender: dns-security-request@neptune.tis.com Precedence: bulk > You are missing the point. I was particularly vocal against the use of SIG > RRs with no signature. It sounds like an oxymoron to me: here's a SIG RR > to give you security; oh by the way there's no signature and thus no > security. I'm afraid I may still be missing the point... > However, being sensitive to the needs of dynamic update in particular, > there is clearly a need for an expiration time for RRs. So, the particular > suggestion at the DNS security meeting was that the expiration RR be > created (so that the concept is useful in general) The concept is useful in general. The EXPIRES RR, however, offers no more generality than a NULL SIG, that I can see. > and that the SIG RR > would later be specified to disallow NULL signatures and might even have > the expiration value removed in favor of this more general mechanism. The > details of this suggestion will be visited when the specification is > advanced from proposed to draft. I would hope that you'd leave DNSSEC just like it is. The NULL SIG has been found to work just fine in the AIX and OS/2 DNS products which support dynamic updates. > However, it should be straightforward to see that being able to state > authoritatively there is no key is a feature worth having. Granted. Still, as you said above, it sounds like an oxymoron to me: here's a KEY RR to give you security; oh by the way there's no key data and thus no security. I don't see why the SIG is different here. Lack of signature data in a SIG would be a pretty strong hint to me that there is no security. But, I could always verify that by going back to the server and looking at the KEY. Edie Received: from relay.tis.com by neptune.TIS.COM id aa25719; 23 Feb 96 14:10 EST Received: by relay.tis.com; id OAA26952; Fri, 23 Feb 1996 14:11:57 -0500 From: lazear@gateway.mitre.org MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma026947; Fri, 23 Feb 96 14:11:28 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA08214; Fri, 23 Feb 96 14:10:26 EST Received: by relay.tis.com; id OAA26940; Fri, 23 Feb 1996 14:11:27 -0500 Received: from gateway.mitre.org(128.29.31.10) by relay.tis.com via smap (V3.1) id xma026936; Fri, 23 Feb 96 14:11:03 -0500 Received: from dockside.mitre.org (dockside.mitre.org [128.29.31.77]) by gateway.mitre.org (8.7.2/8.7.2) with ESMTP id OAA11438; Fri, 23 Feb 1996 14:12:05 -0500 (EST) Received: from localhost (lazear@localhost) by dockside.mitre.org (8.7.2/8.7.2) with SMTP id OAA20769; Fri, 23 Feb 1996 14:15:24 -0500 (EST) Message-Id: <199602231915.OAA20769@dockside.mitre.org> X-Authentication-Warning: dockside.mitre.org: lazear owned process doing -bs X-Authentication-Warning: dockside.mitre.org: Host lazear@localhost didn't use HELO protocol To: "Edie E. Gunter" Cc: "James M. Galvin" , Namedroppers@internic.net, DNS-security@TIS.COM, lazear@gateway.mitre.org Subject: Re: Expires RR proposal In-Reply-To: Your message of "Thu, 22 Feb 96 12:23:53 EST." <9602221723.AA18232@edisto.watson.ibm.com> Date: Fri, 23 Feb 96 14:15:23 -0500 Sender: dns-security-request@neptune.tis.com Precedence: bulk > The concept is useful in general. The EXPIRES RR, however, offers > no more generality than a NULL SIG, that I can see. > The EXPIRE RR does not need some other server to verify with a KEY RR that the null SIG record is valid. The EXPIRE RR stands by itself, as do A, CNAME, and PTR records. No other infrastructure is required. > > and that the SIG RR > > would later be specified to disallow NULL signatures and might even have > > the expiration value removed in favor of this more general mechanism. The > > details of this suggestion will be visited when the specification is > > advanced from proposed to draft. > > I would hope that you'd leave DNSSEC just like it is. The > NULL SIG has been found to work just fine in the AIX and > OS/2 DNS products which support dynamic updates. > Did those systems have to implement *any* other infrastructure to make the NULL SIG work? It is the added complexity of nulling out the rest of DNSSEC that is annoying to those who want EXPIRE RRs. > > However, it should be straightforward to see that being able to state > > authoritatively there is no key is a feature worth having. > > Granted. Still, as you said above, it sounds like an oxymoron to me: > here's a KEY RR to give you security; oh by the way there's no key > data and thus no security. > The EXPIRE RR is a timer, not a security feature. One doesn't need to make the simple function more complicated. > I don't see why the SIG is different here. Lack of signature > data in a SIG would be a pretty strong hint to me that there is > no security. But, I could always verify that by going back > to the server and looking at the KEY. Exactly the complexity to avoid. Walt Received: from relay.tis.com by neptune.TIS.COM id aa26784; 23 Feb 96 15:11 EST Received: by relay.tis.com; id PAA28936; Fri, 23 Feb 1996 15:13:43 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma028929; Fri, 23 Feb 96 15:13:15 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA12245; Fri, 23 Feb 96 15:12:13 EST Received: by relay.tis.com; id PAA28924; Fri, 23 Feb 1996 15:13:13 -0500 Received: from watson.ibm.com(129.34.139.4) by relay.tis.com via smap (V3.1) id xma028919; Fri, 23 Feb 96 15:13:07 -0500 Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 9367; Fri, 23 Feb 96 15:13:34 EST Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.02 on VAGENT2" id 3955; Fri, 23 Feb 1996 15:13:34 EST Received: from edisto.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2Rx) with TCP; Fri, 23 Feb 96 15:13:34 EST Received: by edisto.watson.ibm.com (AIX 3.2/UCB 5.64/900524) id AA15345; Fri, 23 Feb 1996 15:14:38 -0500 Message-Id: <9602232014.AA15345@edisto.watson.ibm.com> X-External-Networks: yes To: lazear@gateway.mitre.org Cc: Namedroppers@internic.net, DNS-security@TIS.COM Subject: Re: Expires RR proposal In-Reply-To: Your message of Fri, 23 Feb 96 14:15:23 EST. <199602231915.OAA20769@dockside.mitre.org> Date: Fri, 23 Feb 96 15:14:37 -0500 From: "Edie E. Gunter" Sender: dns-security-request@neptune.tis.com Precedence: bulk > Did those systems have to implement *any* other infrastructure to make > the NULL SIG work? It is the added complexity of nulling out the rest > of DNSSEC that is annoying to those who want EXPIRE RRs. No, nothing else from DNSSEC was needed for NULL SIGs. > > I don't see why the SIG is different here. Lack of signature > > data in a SIG would be a pretty strong hint to me that there is > > no security. But, I could always verify that by going back > > to the server and looking at the KEY. > Exactly the complexity to avoid. And, if you don't care about security, you don't do this more complex step. The complexity I'd like to avoid is that of DNS as a whole -- duplication of function in multiple RRs and over-engineering solutions to simple problems. Edie Received: from relay.tis.com by neptune.TIS.COM id aa27109; 23 Feb 96 15:28 EST Received: by relay.tis.com; id PAA29611; Fri, 23 Feb 1996 15:29:55 -0500 From: lazear@gateway.mitre.org MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma029603; Fri, 23 Feb 96 15:29:27 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13293; Fri, 23 Feb 96 15:28:25 EST Received: by relay.tis.com; id PAA29600; Fri, 23 Feb 1996 15:29:25 -0500 Received: from gateway.mitre.org(128.29.31.10) by relay.tis.com via smap (V3.1) id xma029586; Fri, 23 Feb 96 15:29:04 -0500 Received: from dockside.mitre.org (dockside.mitre.org [128.29.31.77]) by gateway.mitre.org (8.7.2/8.7.2) with ESMTP id PAA12476; Fri, 23 Feb 1996 15:30:04 -0500 (EST) Received: from localhost (lazear@localhost) by dockside.mitre.org (8.7.2/8.7.2) with SMTP id PAA20909; Fri, 23 Feb 1996 15:33:23 -0500 (EST) Message-Id: <199602232033.PAA20909@dockside.mitre.org> X-Authentication-Warning: dockside.mitre.org: lazear owned process doing -bs X-Authentication-Warning: dockside.mitre.org: Host lazear@localhost didn't use HELO protocol To: "Edie E. Gunter" Cc: lazear@gateway.mitre.org, Namedroppers@internic.net, DNS-security@TIS.COM, lazear@gateway.mitre.org Subject: Re: Expires RR proposal In-Reply-To: Your message of "Fri, 23 Feb 96 15:14:37 EST." <9602232014.AA15345@edisto.watson.ibm.com> Date: Fri, 23 Feb 96 15:33:20 -0500 Sender: dns-security-request@neptune.tis.com Precedence: bulk > No, nothing else from DNSSEC was needed for NULL SIGs. > And, if you don't care about security, you don't do this more > complex step. > > The complexity I'd like to avoid is that of DNS as a whole -- > duplication of function in multiple RRs and over-engineering > solutions to simple problems. > Perhaps it makes sense to split out the SIG RR into its own document, to allow it to progress independant of the DNSSEC work? Perhaps as a "special case" description of the NULL SIG and its usage, leaving the "secure" usage to be defined in the context of the rest of the DNSSEC? This might satisfy both the secure and insecure usage environments? Walt Received: from relay.tis.com by neptune.TIS.COM id aa04490; 23 Feb 96 23:52 EST Received: by relay.tis.com; id XAA04963; Fri, 23 Feb 1996 23:43:57 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma004960; Fri, 23 Feb 96 23:43:28 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA28475; Fri, 23 Feb 96 23:42:26 EST Received: by relay.tis.com; id XAA04957; Fri, 23 Feb 1996 23:43:27 -0500 Received: from gw.home.vix.com(192.5.5.1) by relay.tis.com via smap (V3.1) id xma004955; Fri, 23 Feb 96 23:43:11 -0500 Received: by gw.home.vix.com id UAA26457; Fri, 23 Feb 1996 20:44:13 -0800 (PST) Date: Fri, 23 Feb 1996 20:44:13 -0800 (PST) X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: dns-security@TIS.COM From: Paul A Vixie Subject: Re: Expires RR proposal Organization: Vixie Enterprises Message-Id: References: <199602232033.PAA20909@dockside.mitre.org> Nntp-Posting-Host: wisdom.home.vix.com In-Reply-To: lazear@gateway.mitre.org's message of 23 Feb 1996 13:13:20 -0800 Sender: dns-security-request@neptune.tis.com Precedence: bulk >Perhaps it makes sense to split out the SIG RR into its own >document, to allow it to progress independant of the DNSSEC >work? Perhaps as a "special case" description of the NULL SIG >and its usage, leaving the "secure" usage to be defined in the >context of the rest of the DNSSEC? This might satisfy both >the secure and insecure usage environments? > > Walt DNSSEC is almost at PS. And the description of SIG(NULL) in the document is adequate to EXP's purposes. Perhaps Donald and Charlie will add a sentence or two during the PS review process? -- Paul Vixie La Honda, CA "Illegitimibus non carborundum." pacbell!vixie!paul Received: from relay.tis.com by neptune.TIS.COM id aa04487; 23 Feb 96 23:52 EST Received: by relay.tis.com; id XAA04952; Fri, 23 Feb 1996 23:42:27 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma004949; Fri, 23 Feb 96 23:41:58 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA28446; Fri, 23 Feb 96 23:40:56 EST Received: by relay.tis.com; id XAA04945; Fri, 23 Feb 1996 23:41:57 -0500 Received: from gw.home.vix.com(192.5.5.1) by relay.tis.com via smap (V3.1) id xma004942; Fri, 23 Feb 96 23:41:40 -0500 Received: by gw.home.vix.com id UAA26402; Fri, 23 Feb 1996 20:42:42 -0800 (PST) Date: Fri, 23 Feb 1996 20:42:42 -0800 (PST) X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: dns-security@TIS.COM From: Paul A Vixie Subject: Re: Expires RR proposal Organization: Vixie Enterprises Message-Id: References: <9602232014.AA15345@edisto.watson.ibm.com> Nntp-Posting-Host: wisdom.home.vix.com In-Reply-To: edie@watson.ibm.com's message of 23 Feb 1996 13:07:51 -0800 Sender: dns-security-request@neptune.tis.com Precedence: bulk In article <9602232014.AA15345@edisto.watson.ibm.com>, edie@watson.ibm.com ("Edie E. Gunter") writes: > The complexity I'd like to avoid is that of DNS as a whole -- > duplication of function in multiple RRs and over-engineering > solutions to simple problems. Me, too. Since a SIG(NULL) does what EXP would do, and since SIG(NULL) is much easier to implement than SIG(*), I see no reason for EXP. I see EXP as unnecessary complexity for a system whose comparitive simplicity has been its biggest reason for success. -- Paul Vixie La Honda, CA "Illegitimibus non carborundum." pacbell!vixie!paul Received: from relay.tis.com by neptune.TIS.COM id aa11814; 24 Feb 96 11:19 EST Received: by relay.tis.com; id LAA08474; Sat, 24 Feb 1996 11:21:36 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma008472; Sat, 24 Feb 96 11:21:07 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA10670; Sat, 24 Feb 96 11:20:04 EST Received: by relay.tis.com; id LAA08469; Sat, 24 Feb 1996 11:21:06 -0500 Received: from callandor.cybercash.com(204.178.186.70) by relay.tis.com via smap (V3.1) id xma008467; Sat, 24 Feb 96 11:21:05 -0500 Received: by callandor.cybercash.com; id LAA25245; Sat, 24 Feb 1996 11:28:30 -0500 Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (g3.0.3) id xma025243; Sat, 24 Feb 96 11:28:26 -0500 Received: by cybercash.com.cybercash.com (4.1/SMI-4.1) id AA23891; Sat, 24 Feb 96 11:18:48 EST Date: Sat, 24 Feb 1996 11:18:47 -0500 (EST) From: "Donald E. Eastlake 3rd" To: dns-security@TIS.COM Subject: Re: Expires RR proposal (fwd) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dns-security-request@neptune.tis.com Precedence: bulk Guess I should have cc'ed dns-security to star with on this message... ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html ---------- Forwarded message ---------- Date: Sat, 24 Feb 1996 10:40:56 -0500 From: Donald E. Eastlake 3rd To: Multiple recipients of list NAMEDROPPERS Subject: Re: Expires RR proposal On Fri, 23 Feb 1996 lazear@GATEWAY.MITRE.ORG wrote: > Perhaps it makes sense to split out the SIG RR into its own > document, to allow it to progress independant of the DNSSEC > work? Perhaps as a "special case" description of the NULL SIG > and its usage, leaving the "secure" usage to be defined in the > context of the rest of the DNSSEC? This might satisfy both > the secure and insecure usage environments? This doesn't seem particularly useful to me. The current DNSSEC draft (draft-ietf-dnssec-secext-09.txt) provides for null signatures (algorithm 253 signatures) and currently has the following sort of verbage is a couple of places: "... Number 253, known as the "expiration date algorithm", is used when the expiration date or other non-signature fields of the SIG are desired without any actual security. It is anticipated that this algorithm will only be used in connection with some modes of DNS dynamic update. For number 253, the signature field will be null. ..." I suspect some minor tweaking of this would be all that would be required for separate expiration use. But so far I haven't noticed anyone answer my point that I thought the reason for an EXP RR was when you *did* have security. In that case, the SIGs are normally all added by a seprate applicaton that puts a uniform expiration date in, sometime far enough in the future that you are sure you will get around to re-signing the zone before then. I suppose it could take into account TTL but that's not the right thing either as TTL is really just for cache consistency, not ultimate expiration. So if you do have security and the SIG expiration is fixed by your security machinery and TTL is for cache consistency, there is no place for expiration other than EXP. > Walt Donald ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html Received: from relay.tis.com by neptune.TIS.COM id aa19164; 26 Feb 96 8:58 EST Received: by relay.tis.com; id JAA20495; Mon, 26 Feb 1996 09:00:39 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma020486; Mon, 26 Feb 96 09:00:11 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA01130; Mon, 26 Feb 96 08:59:06 EST Received: by relay.tis.com; id JAA20476; Mon, 26 Feb 1996 09:00:09 -0500 Received: from eitech.eit.com(192.100.58.2) by relay.tis.com via smap (V3.1) id xma020462; Mon, 26 Feb 96 08:59:53 -0500 Received: from [153.37.6.7] (pool007.Max6.Washington.DC.DYNIP.ALTER.NET [153.37.6.7]) by eitech.eit.com (8.6.12/8.6.12) with SMTP id GAA03150; Mon, 26 Feb 1996 06:00:38 -0800 X-Sender: galvin@pop.eit.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 26 Feb 1996 09:04:37 -0400 To: Paul A Vixie From: "James M. Galvin" Subject: Re: Expires RR proposal Cc: dns-security@TIS.COM Sender: dns-security-request@neptune.tis.com Precedence: bulk At 12:42 AM 2/24/96, Paul A Vixie wrote: >In article <9602232014.AA15345@edisto.watson.ibm.com>, >edie@watson.ibm.com ("Edie E. Gunter") writes: >> The complexity I'd like to avoid is that of DNS as a whole -- >> duplication of function in multiple RRs and over-engineering >> solutions to simple problems. > >Me, too. Since a SIG(NULL) does what EXP would do, and since SIG(NULL) >is much easier to implement than SIG(*), I see no reason for EXP. I see >EXP as unnecessary complexity for a system whose comparitive simplicity >has been its biggest reason for success. Well, beauty is in the eyes of the beholder. SIG(NULL) was invented to accommodate the needs of dynamic update that wanted an expire without security. Frankly, I don't know why, but there's more of them than there are of me, so C'est la Vie. However, I do not support SIG(NULL), I have never supported SIG(NULL), and I never will support SIG(NULL). It's hard enough convincing people what is secure and what's not, when there is security and when there isn't, and we're only going to confuse the issue further by providing a security enhancement to DNS with absolutely no security whatsoever. It's totally ludicrous. Dynamic update should have done EXP in the first place. In fact, SIG should use EXP instead of having it in the SIG RR; that's the only reason I relented in my argument against SIG(NULL). People did not want to slow down DNSSEC by waiting for EXP so we needed a transition state. Jim ---------------------------------------------------------------------------- James M. Galvin galvin@eit.com VeriFone/EIT, PO Box 220, Glenwood, MD 21738 +1 410.795.6882 Received: from relay.tis.com by neptune.TIS.COM id aa20591; 26 Feb 96 9:57 EST Received: by relay.tis.com; id JAA21959; Mon, 26 Feb 1996 09:59:39 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma021948; Mon, 26 Feb 96 09:59:13 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA04818; Mon, 26 Feb 96 09:58:07 EST Received: by relay.tis.com; id JAA21940; Mon, 26 Feb 1996 09:59:10 -0500 Received: from unknown(147.28.0.39) by relay.tis.com via smap (V3.1) id xma021928; Mon, 26 Feb 96 09:58:40 -0500 Received: by rip.psg.com (Smail3.1.29.1 #1) id m0tr4Og-00080KC; Mon, 26 Feb 96 06:59 PST Message-Id: Date: Mon, 26 Feb 96 06:59 PST From: Randy Bush To: "James M. Galvin" Cc: dns-security@TIS.COM Subject: Re: Expires RR proposal References: Sender: dns-security-request@neptune.tis.com Precedence: bulk > Dynamic update should have done EXP in the first place. In fact, SIG > should use EXP instead of having it in the SIG RR; that's the only reason I > relented in my argument against SIG(NULL). People did not want to slow > down DNSSEC by waiting for EXP so we needed a transition state. agreed. randy Received: from relay.tis.com by neptune.TIS.COM id aa21981; 26 Feb 96 11:04 EST Received: by relay.tis.com; id LAA23266; Mon, 26 Feb 1996 11:06:10 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma023259; Mon, 26 Feb 96 11:05:42 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA10574; Mon, 26 Feb 96 11:04:37 EST Received: by relay.tis.com; id LAA23247; Mon, 26 Feb 1996 11:05:40 -0500 Received: from gw.home.vix.com(192.5.5.1) by relay.tis.com via smap (V3.1) id xma023235; Mon, 26 Feb 96 11:05:20 -0500 Received: by gw.home.vix.com id IAA29970; Mon, 26 Feb 1996 08:06:20 -0800 (PST) X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by wisdom.home.vix.com id AA31959; Mon, 26 Feb 1996 08:06:20 -0800 Message-Id: <9602261606.AA31959@wisdom.home.vix.com> To: "James M. Galvin" Cc: dns-security@TIS.COM Subject: Re: Expires RR proposal In-Reply-To: Your message of "Mon, 26 Feb 1996 09:04:37 -0400." Date: Mon, 26 Feb 1996 08:06:20 -0800 From: Paul A Vixie Sender: dns-security-request@neptune.tis.com Precedence: bulk Someone here said that the expiration in a SIG pertains to me signature, whereas the expiration in an EXP pertains to EXP's RRset. If that's right, then the solutions spaces are disjoint and we should progress both. Received: from relay.tis.com by neptune.TIS.COM id aa29869; 26 Feb 96 16:22 EST Received: by relay.tis.com; id QAA01198; Mon, 26 Feb 1996 16:23:55 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma001193; Mon, 26 Feb 96 16:23:27 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA03550; Mon, 26 Feb 96 16:22:21 EST Received: by relay.tis.com; id QAA01184; Mon, 26 Feb 1996 16:23:25 -0500 Received: from unknown(129.34.139.4) by relay.tis.com via smap (V3.1) id xma001177; Mon, 26 Feb 96 16:23:20 -0500 Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 5123; Mon, 26 Feb 96 16:23:39 EST Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.02 on VAGENT2" id 4963; Mon, 26 Feb 1996 16:23:38 EST Received: from edisto.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2Rx) with TCP; Mon, 26 Feb 96 16:23:38 EST Received: by edisto.watson.ibm.com (AIX 3.2/UCB 5.64/900524) id AA19247; Mon, 26 Feb 1996 16:24:44 -0500 Message-Id: <9602262124.AA19247@edisto.watson.ibm.com> X-External-Networks: yes To: Paul A Vixie Cc: dns-security@TIS.COM Subject: Re: Expires RR proposal In-Reply-To: Your message of Mon, 26 Feb 96 08:06:20 PST. <9602261606.AA31959@wisdom.home.vix.com> Date: Mon, 26 Feb 96 16:24:44 -0500 From: "Edie E. Gunter" Sender: dns-security-request@neptune.tis.com Precedence: bulk > Someone here said that the expiration in a SIG pertains to me signature, > whereas the expiration in an EXP pertains to EXP's RRset. If that's > right, then the solutions spaces are disjoint and we should progress both. There's just this one funny little quirk to be resolved. DNSSEC specifies that when the SIG expires, the covered RRs in effect go away (they're no longer provided in query responses and don't appear in a zone transfer.) I think the idea here was that secure servers don't give out unauthenticated data. ?? The net then is that when the SIG expires, the covered RRset also expires. Of course, if Jim wants to revamp DNSSEC to remove/redesign this "feature" and have the security stuff work with a new EXPIRE RR, as has been suggested/implied here, that's a different matter. Edie Received: from relay.tis.com by neptune.TIS.COM id aa00561; 27 Feb 96 17:45 EST Received: by relay.tis.com; id RAA20396; Tue, 27 Feb 1996 17:47:29 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma020392; Tue, 27 Feb 96 17:47:00 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA06541; Tue, 27 Feb 96 17:45:56 EST Received: by relay.tis.com; id RAA20389; Tue, 27 Feb 1996 17:46:59 -0500 Received: from eitech.eit.com(192.100.58.2) by relay.tis.com via smap (V3.1) id xma020386; Tue, 27 Feb 96 17:46:45 -0500 Received: from [153.37.7.16] (pool016.Max7.Washington.DC.DYNIP.ALTER.NET [153.37.7.16]) by eitech.eit.com (8.6.12/8.6.12) with SMTP id OAA04130; Tue, 27 Feb 1996 14:47:37 -0800 X-Sender: galvin@pop.eit.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 27 Feb 1996 17:51:37 -0400 To: "Edie E. Gunter" From: "James M. Galvin" Subject: Re: Expires RR proposal Cc: Paul A Vixie , dns-security@TIS.COM Sender: dns-security-request@neptune.tis.com Precedence: bulk At 5:24 PM 2/26/96, Edie E. Gunter wrote: >> From Paul Vixie >> Someone here said that the expiration in a SIG pertains to me signature, >> whereas the expiration in an EXP pertains to EXP's RRset. If that's >> right, then the solutions spaces are disjoint and we should progress both. > >There's just this one funny little quirk to be resolved. DNSSEC >specifies that when the SIG expires, the covered RRs in effect >go away (they're no longer provided in query responses and don't >appear in a zone transfer.) I think the idea here was that >secure servers don't give out unauthenticated data. ?? The net >then is that when the SIG expires, the covered RRset also expires. > >Of course, if Jim wants to revamp DNSSEC to remove/redesign this >"feature" and have the security stuff work with a new EXPIRE RR, >as has been suggested/implied here, that's a different matter. I don't think a revamp/remove/redesign is necessary. At least, a scenario where there's a conflict is not immediately obvious to me. It would help me if someone who may be more knowledgeable about dynamic update could identify one. The expiration in the SIG RR indicate when the SIG expires. A SIG RR covers a particular type of other RR. When the SIG expires the RRs are to be removed from the DNS. The expiration in the EXP RR covers a particular type of other RR. When that time is reached the RRs are to be removed from the DNS. In either case, when the expiration time is reached the data is to be considered unavailable and removed from the DNS. I'm at a loss to identify a time when I would want either the signature or the expiration to remain valid when the other has been reached. Jim ---------------------------------------------------------------------------- James M. Galvin galvin@eit.com VeriFone/EIT, PO Box 220, Glenwood, MD 21738 +1 410.795.6882 Received: from relay.tis.com by neptune.TIS.COM id aa01218; 27 Feb 96 18:12 EST Received: by relay.tis.com; id SAA20887; Tue, 27 Feb 1996 18:13:59 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma020882; Tue, 27 Feb 96 18:13:31 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA07118; Tue, 27 Feb 96 18:12:26 EST Received: by relay.tis.com; id SAA20877; Tue, 27 Feb 1996 18:13:29 -0500 Received: from gw.home.vix.com(192.5.5.1) by relay.tis.com via smap (V3.1) id xma020873; Tue, 27 Feb 96 18:13:23 -0500 Received: by gw.home.vix.com id PAA00366; Tue, 27 Feb 1996 15:14:12 -0800 (PST) X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by wisdom.home.vix.com id AA00233; Tue, 27 Feb 1996 15:14:17 -0800 Message-Id: <9602272314.AA00233@wisdom.home.vix.com> To: "James M. Galvin" Cc: "Edie E. Gunter" , dns-security@TIS.COM Subject: Re: Expires RR proposal In-Reply-To: Your message of "Tue, 27 Feb 1996 17:51:37 -0400." Date: Tue, 27 Feb 1996 15:14:17 -0800 From: Paul A Vixie Sender: dns-security-request@neptune.tis.com Precedence: bulk Dynamic Update does not require any sort of SIG(NULL) or EXP RR. That need was part of previous drafts, and is long, long gone. Patton's draft is not security related or dynamic update related, but rather is just a normal DNS extension. I have no idea why it is being discussed on dns-security. Received: from relay.tis.com by neptune.TIS.COM id aa13545; 28 Feb 96 4:19 EST Received: by relay.tis.com; id EAA25585; Wed, 28 Feb 1996 04:21:34 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma025582; Wed, 28 Feb 96 04:21:05 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA14453; Wed, 28 Feb 96 04:20:00 EST Received: by relay.tis.com; id EAA25579; Wed, 28 Feb 1996 04:21:04 -0500 Received: from gw.home.vix.com(192.5.5.1) by relay.tis.com via smap (V3.1) id xma025577; Wed, 28 Feb 96 04:20:51 -0500 Received: by gw.home.vix.com id BAA15808; Wed, 28 Feb 1996 01:21:52 -0800 (PST) Date: Wed, 28 Feb 1996 01:21:52 -0800 (PST) X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: dns-security@TIS.COM From: Paul A Vixie Subject: Re: Expires RR proposal Organization: Vixie Enterprises Message-Id: References: <9602262124.AA19247@edisto.watson.ibm.com> Nntp-Posting-Host: wisdom.home.vix.com In-Reply-To: edie@watson.ibm.com's message of 26 Feb 1996 14:24:16 -0800 Sender: dns-security-request@neptune.tis.com Precedence: bulk >There's just this one funny little quirk to be resolved. DNSSEC >specifies that when the SIG expires, the covered RRs in effect >go away (they're no longer provided in query responses and don't >appear in a zone transfer.) I think the idea here was that >secure servers don't give out unauthenticated data. ?? The net >then is that when the SIG expires, the covered RRset also expires. That strikes me as the wrong thing to do. Send the data, along with the expired signature. What's expired is the signature, not the data. This constitutes my first and only objection to DNSSEC, but since Edie had to point it out to me, I'm not going to lodge it formally (I had my chance.) -- Paul Vixie La Honda, CA "Illegitimibus non carborundum." pacbell!vixie!paul Received: from relay.tis.com by neptune.TIS.COM id aa21716; 28 Feb 96 10:52 EST Received: by relay.tis.com; id KAA01329; Wed, 28 Feb 1996 10:54:00 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma001307; Wed, 28 Feb 96 10:53:35 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA28325; Wed, 28 Feb 96 10:52:29 EST Received: by relay.tis.com; id KAA01293; Wed, 28 Feb 1996 10:53:32 -0500 Received: from watson.ibm.com(129.34.139.4) by relay.tis.com via smap (V3.1) id xma001276; Wed, 28 Feb 96 10:53:10 -0500 Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 9113; Wed, 28 Feb 96 10:53:55 EST Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.02 on VAGENT2" id 8402; Wed, 28 Feb 1996 10:53:55 EST Received: from edisto.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2Rx) with TCP; Wed, 28 Feb 96 10:53:54 EST Received: by edisto.watson.ibm.com (AIX 3.2/UCB 5.64/900524) id AA15217; Wed, 28 Feb 1996 10:55:02 -0500 Message-Id: <9602281555.AA15217@edisto.watson.ibm.com> X-External-Networks: yes To: dns-security@TIS.COM Subject: Re: Expires RR proposal In-Reply-To: Your message of Tue, 27 Feb 96 17:51:37 D. Date: Wed, 28 Feb 96 10:55:01 -0500 From: "Edie E. Gunter" Sender: dns-security-request@neptune.tis.com Precedence: bulk Jim, > I don't think a revamp/remove/redesign is necessary. At least, a scenario > where there's a conflict is not immediately obvious to me. It would help > me if someone who may be more knowledgeable about dynamic update could > identify one. Dynamic update doesn't need expiration. I don't think there's a problem there. > The expiration in the SIG RR indicate when the SIG expires. A SIG RR > covers a particular type of other RR. When the SIG expires the RRs are to > be removed from the DNS. > > The expiration in the EXP RR covers a particular type of other RR. When > that time is reached the RRs are to be removed from the DNS. > > In either case, when the expiration time is reached the data is to be > considered unavailable and removed from the DNS. I'm at a loss to identify > a time when I would want either the signature or the expiration to remain > valid when the other has been reached. What you've described here sounds reasonable. My original complaint (over in namedroppers) against the EXPIRE RR, which got lost in all the hubbub over NULL SIGs, was that if there were two ways for RR's to be expired, how would the server decide which expiration time would win? As a user, I don't want to go to the trouble to set up an EXPIRE RR only to have a SIG expire earlier wiping out my data before I wanted it to go. I'll need to know to set them both the same. ?? (An implementation detail is how to resolve this with an offline zone signing procedure.) My other complaint (which also got lost in the fray) was against having two different ways of treating the expired RR's. DNSSEC says when the SIG expires, the RR's are gone. The EXPIRE spec suggests that they may stay around and be used in dynamic update processing. If the two different ways of treating expired data were allowed, then this raises lots of questions. If the EXPIRE time arrives before the SIG time in secure DNS, then are the EXPIRE rules used in handling the expired RRs? And vice versa if the SIG time arrives first? If EXPIRE RRs are used in unsecure DNS, would we see different results for the same database, same update, as in a secure DNS? It seems to me if there are 2 ways to expire data, then what happens to that expired data should be the same using either method of expiration. Someone suggested that the EXPIRE RR would only be used in unsecure DNS. I haven't seen anything from the DNSSEC folks to indicate it would be disallowed in secure DNS, however. What I thought you (or was it someone else?) were suggesting in earlier mail where it was mentioned having DNSSEC use an EXPIRE RR, was that you would do something like remove the expiration time from the SIG and *require* an EXPIRE RR for every SIG. Then, the time in the EXPIRE RR would indicate when the SIG would expire (of course, since an EXPIRE covers an RR type I don't know if this would work.) And then maybe DNSSEC would require EXPIRE RRs for the RRs the SIG covers and it would require that those expiration times be set the same as for the SIG. Of course, this would all be handled by software so managing it would not be a big deal. It would, however, make the zone files much larger with all these extra RR's. That's the kind of redesign I thought was being suggested. Obviously, I misunderstood. Now, I really don't know what was meant by hinting DNSSEC could use the EXPIRE RR. Sorry to be so longwinded... Edie Received: from relay.tis.com by neptune.TIS.COM id aa28776; 29 Feb 96 17:27 EST Received: by relay.tis.com; id RAA28025; Thu, 29 Feb 1996 17:29:28 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma028017; Thu, 29 Feb 96 17:29:12 -0500 Received: from polar.tis.com.tis.com by tis.com (4.1/SUN-5.64) id AA12566; Thu, 29 Feb 96 17:28:06 EST Date: Thu, 29 Feb 96 17:28:06 EST From: Olafur Gudmundsson Message-Id: <9602292228.AA12566@tis.com> Received: by polar.tis.com.tis.com (4.1/SMI-4.1) id AA08175; Thu, 29 Feb 96 17:28:05 EST To: dns-security@neptune.tis.com Subject: ANNOUNCE: TIS/DNSSEC Beta 1.0 is now available Sender: dns-security-request@neptune.tis.com Precedence: bulk We are please to announce that the first Beta release of TIS/DNSSEC is now available. This version is a implementation of the current DNSSEC draft and it is based on bind-4.9.3-REL, it uses RSAREF, but you need to retrieve a copy from RSA. We are actively seeking beta testers. We are also pleased to announce the FIRST secure zone, sd-bogus.tis.com which is served from uranus.tis.com. We are also making a DNSSEC enhanced version of DIG available, in executable form for popular platforms. This version of dig is extended to query sd-bogus and other secure servers. There are no export restrictions on the executables For information on how to acquire TIS/DNSSEC retrieve the file /pub/DNSSEC/README on the host ftp.tis.com via anonymous FTP, for further instruction on how the get the TIS/DNSSEC distribution. The new dig a sunos4.x executable versions are ftp:/ftp.tis.com/pub/DNSSEC/sdig.sunos4.gz Other versions will be made available as ftp:/ftp.tis.com/pub/DNSSEC/sdig..gz If you have any questions or problems please send a note to tisdnssec-support@tis.com. If you compile the new dig on a popular platform that we do not have an executable for please let us know. Enjoy, Olafur Received: from relay.tis.com by neptune.TIS.COM id aa24447; 6 Mar 96 17:19 EST Received: by relay.tis.com; id RAA01571; Wed, 6 Mar 1996 17:20:59 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma001567; Wed, 6 Mar 96 17:20:48 -0500 Received: from antares.tis.com by tis.com (4.1/SUN-5.64) id AA01221; Wed, 6 Mar 96 17:19:43 EST Message-Id: <9603062219.AA01221@tis.com> To: dns-security@TIS.COM Subject: Re: ANNOUNCE: TIS/DNSSEC Beta 1.0 is now available In-Reply-To: Your message of "Thu, 29 Feb 1996 17:28:06 EST." <9602292228.AA12566@tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <4787.826150814.1@tis.com> Date: Wed, 06 Mar 1996 17:20:14 -0500 From: Olafur Gudmundsson Sender: dns-security-request@neptune.tis.com Precedence: bulk Olafur Gudmundsson writes: > We are please to announce that the first Beta release of > TIS/DNSSEC is now available. This version is a implementation > of the current DNSSEC draft and it is based on bind-4.9.3-REL, > it uses RSAREF, but you need to retrieve a copy from RSA. > > We are actively seeking beta testers. I have installed a WEB page that allows you retrieve both TIS/DNSSEC and RSAREF. http://www.tis.com/docs/Research/iip/dnssec.html Olafur Received: from relay.tis.com by neptune.TIS.COM id aa01517; 7 Mar 96 3:07 EST Received: by relay.tis.com; id DAA06881; Thu, 7 Mar 1996 03:09:06 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma006879; Thu, 7 Mar 96 03:08:38 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13952; Thu, 7 Mar 96 03:07:33 EST Received: by relay.tis.com; id DAA06873; Thu, 7 Mar 1996 03:08:36 -0500 Received: from callandor.cybercash.com(204.178.186.70) by relay.tis.com via smap (V3.1) id xma006869; Thu, 7 Mar 96 03:08:10 -0500 Received: by callandor.cybercash.com; id DAA20383; Thu, 7 Mar 1996 03:15:22 -0500 Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (g3.0.3) id xma020378; Thu, 7 Mar 96 03:15:06 -0500 Received: by cybercash.com (4.1/SMI-4.1) id AA22530; Thu, 7 Mar 96 03:05:29 EST Date: Thu, 7 Mar 1996 03:05:28 -0500 (EST) From: "Donald E. Eastlake 3rd" To: dns-security@TIS.COM Subject: Re: Expires RR proposal In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dns-security-request@neptune.tis.com Precedence: bulk The currrent dnssec contemplates that all RRs in a zone would have SIGs that all expire at the same time. In that case, really the whole zone is either there or not. With dynamic update, you are more likely to get SIGs with different expiration dates. SIG expiring should certainly wipe out an RR in a cache but it is not at all clear to me that it should drop out of a zone and cause the AXFR sig to fail. So I think authoritative servers should keep it in the zone. I don't think any EXP RR should repilace the expiration field in the SIG RR. I just dont see the need to add a lot of EXP RRs and make SIG calculation more complex by including the EXP RR when signing. Donald On Wed, 28 Feb 1996, Paul A Vixie wrote: > Date: Wed, 28 Feb 1996 01:21:52 -0800 (PST) > From: Paul A Vixie > To: dns-security@TIS.COM > Subject: Re: Expires RR proposal > > >There's just this one funny little quirk to be resolved. DNSSEC > >specifies that when the SIG expires, the covered RRs in effect > >go away (they're no longer provided in query responses and don't > >appear in a zone transfer.) I think the idea here was that > >secure servers don't give out unauthenticated data. ?? The net > >then is that when the SIG expires, the covered RRset also expires. > > That strikes me as the wrong thing to do. Send the data, along with the > expired signature. What's expired is the signature, not the data. This > constitutes my first and only objection to DNSSEC, but since Edie had to > point it out to me, I'm not going to lodge it formally (I had my chance.) > -- > Paul Vixie > La Honda, CA "Illegitimibus non carborundum." > > pacbell!vixie!paul > ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html Received: from relay.tis.com by neptune.TIS.COM id aa07300; 7 Mar 96 9:41 EST Received: by relay.tis.com; id JAA11352; Thu, 7 Mar 1996 09:43:16 -0500 From: lazear@gateway.mitre.org MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma011344; Thu, 7 Mar 96 09:42:51 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA23827; Thu, 7 Mar 96 09:41:47 EST Received: by relay.tis.com; id JAA11337; Thu, 7 Mar 1996 09:42:50 -0500 Received: from gateway.mitre.org(128.29.31.10) by relay.tis.com via smap (V3.1) id xma011334; Thu, 7 Mar 96 09:42:45 -0500 Received: from dockside.mitre.org (dockside.mitre.org [128.29.31.77]) by gateway.mitre.org (8.7.2/8.7.2) with ESMTP id JAA01925; Thu, 7 Mar 1996 09:43:48 -0500 (EST) Received: from localhost (lazear@localhost) by dockside.mitre.org (8.7.2/8.7.2) with SMTP id JAA13331; Thu, 7 Mar 1996 09:47:10 -0500 (EST) Message-Id: <199603071447.JAA13331@dockside.mitre.org> X-Authentication-Warning: dockside.mitre.org: lazear owned process doing -bs X-Authentication-Warning: dockside.mitre.org: Host lazear@localhost didn't use HELO protocol To: "Donald E. Eastlake 3rd" Cc: dns-security@TIS.COM, lazear@gateway.mitre.org Subject: Re: Expires RR proposal In-Reply-To: Your message of "Thu, 07 Mar 96 03:05:28 EST." Date: Thu, 07 Mar 96 09:47:08 -0500 Sender: dns-security-request@neptune.tis.com Precedence: bulk >SIG expiring should certainly wipe out an RR in a cache but it is not at all >clear to me that it should drop out of a zone and cause the AXFR sig to fail. >So I think authoritative servers should keep it in the zone. I agree...it seems that an expired SIG RR means that the data is no longer secured, not that it's invalid. Otherwise, how can you tell the difference between insecure and secured data? Donald suggests sending the expired SIG with an answer...I'd prefer that the SIG disappear and the answer come back as unsigned (completely insecure, not just used-to-be secured). Walt Received: from relay.tis.com by neptune.TIS.COM id aa21583; 8 Mar 96 1:14 EST Received: by relay.tis.com; id BAA22132; Fri, 8 Mar 1996 01:16:31 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma022130; Fri, 8 Mar 96 01:16:02 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02895; Fri, 8 Mar 96 01:14:57 EST Received: by relay.tis.com; id BAA22127; Fri, 8 Mar 1996 01:16:01 -0500 Received: from gw.home.vix.com(192.5.5.1) by relay.tis.com via smap (V3.1) id xma022125; Fri, 8 Mar 96 01:15:52 -0500 Received: by gw.home.vix.com id WAA23698; Thu, 7 Mar 1996 22:16:56 -0800 (PST) Date: Thu, 7 Mar 1996 22:16:56 -0800 (PST) X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: dns-security@TIS.COM From: Paul A Vixie Subject: Re: Expires RR proposal Organization: Vixie Enterprises Message-Id: References: <199603071447.JAA13331@dockside.mitre.org> Nntp-Posting-Host: wisdom.home.vix.com In-Reply-To: lazear@gateway.mitre.org's message of 7 Mar 1996 07:37:08 -0800 Sender: dns-security-request@neptune.tis.com Precedence: bulk > I agree...it seems that an expired SIG RR means that the data is no longer > secured, not that it's invalid. Otherwise, how can you tell the difference > between insecure and secured data? Donald suggests sending the expired SIG > with an answer...I'd prefer that the SIG disappear and the answer come back > as unsigned (completely insecure, not just used-to-be secured). At DNSIND today, MAP presented his EXP proposal and the consensus of those present was that it would not address DHCP's needs. We're going to pursue a different angle. SIG(NULL) will disappear from the next DNSSEC document. Future DNS expiry discussions will take place on namedroppers@internic.net. -- Paul Vixie La Honda, CA "Illegitimibus non carborundum." pacbell!vixie!paul Received: from relay.tis.com by neptune.TIS.COM id aa08210; 9 Mar 96 11:47 EST Received: by relay.tis.com; id LAA00691; Sat, 9 Mar 1996 11:49:48 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma000681; Sat, 9 Mar 96 11:49:27 -0500 Received: from by tis.com (4.1/SUN-5.64) id AC01693; Sat, 9 Mar 96 11:48:24 EST Received: by relay; id HAA03506; Sat, 9 Mar 1996 07:44:44 -0500 Received: from unknown(192.100.58.2) by relay.tis.com via smap (V3.1) id xmaa03403; Sat, 9 Mar 96 07:39:57 -0500 Received: from [153.37.111.46] (pool046.Max2.Raleigh.NC.DYNIP.ALTER.NET [153.37.111.46]) by eitech.eit.com (8.6.12/8.6.12) with SMTP id SAA04143 for ; Fri, 8 Mar 1996 18:37:04 -0800 X-Sender: galvin@pop.eit.com (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="============_-1385786801==_============" Date: Fri, 8 Mar 1996 21:41:35 -0400 To: dns-security@TIS.COM From: "James M. Galvin" Subject: draft Minutes of Spring IETF 1996 Sender: dns-security-request@neptune.tis.com Precedence: bulk --============_-1385786801==_============ Content-Type: text/plain; charset="us-ascii" Enclosed below is a draft of the minutes of the Spring IETF 1996 meeting. Suggestions to improve, corrections, and omissions are hereby solicited. I will submit either the draft below or its revision in approximately one week: friday, March 15. Thanks, Jim --============_-1385786801==_============ Content-Type: text/plain; name="dnssec-minutes.txt"; charset="us-ascii" Content-Disposition: attachment; filename="dnssec-minutes.txt" Minutes of the DNS Security Working Group Spring IETF 1996 The working group met during one meeting period with the following agenda: Charter Review Secure DNS Status document implementation Requirements Review Dynamic Update Discussion A revised Charter that included the secure dynamic update task was presented to the working group for review. A revision will be posted to the mailing list for final review prior to submission to the Area Director and Secretariat for approval and posting. The secure DNS specifications (draft-ietf-dnssec-secext-09.txt and draft-ietf-dnssec-as-map-03.txt) are currently in IETF Last Call. The IESG will make its decision during its next regularly scheduled meeting; the documents are expected to be advanced to Proposed Standard. Trusted Information Systems (TIS) announced the availability of their beta implementation of the DNS security enhancements. It is available for anonymous FTP to U.S. and Canadian sites. Retrieve the file ftp://ftp.tis.com/pub/DNSSEC/README for more details. Beta testers are requested to contact tisdnssec-support@tis.com for more information. Prior to beginning the secure dynamic update discussion a review of the requirements for it, as agreed at the last meeting, was presented. The requirements are: must detect replay of transactions must be able to order transactions must address clock synchronization should address all of current dynamic update specification Donald Eastlake presented an overview of the secure dynamic update draft (draft-ietf-dnssec-update-00.txt) he has proposed. Since no significant discussion resulted information about implementations was requested, to which TIS committed to beginning its implementation of the proposal soon. A caution was offered about deploying secure dynamic update given the lack of experience we have with insecure dynamic update. However, the Security Area Director was quick to point out he considered this a feature. The reason is because more often than not the security area finds itself retrofitting security into a protocol, a process that is usually imperfect and unnecessarily constrains the integration. The meeting closed with the working group agreeing to wait until the summer IETF before deciding whether to advance the current proposal. Waiting will permit TIS to begin its implementation and evaluate the completeness of the specification. --============_-1385786801==_============ Content-Type: text/plain; charset="us-ascii" ---------------------------------------------------------------------------- James M. Galvin galvin@eit.com VeriFone/EIT, PO Box 220, Glenwood, MD 21738 +1 410.795.6882 --============_-1385786801==_============-- Received: from relay.tis.com by neptune.TIS.COM id aa08209; 9 Mar 96 11:47 EST Received: by relay.tis.com; id LAA00686; Sat, 9 Mar 1996 11:49:47 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma000680; Sat, 9 Mar 96 11:49:26 -0500 Received: from by tis.com (4.1/SUN-5.64) id AC01693; Sat, 9 Mar 96 11:48:23 EST Received: by relay; id HAA03469; Sat, 9 Mar 1996 07:39:24 -0500 Received: from unknown(192.100.58.2) by relay.tis.com via smap (V3.1) id xma003403; Sat, 9 Mar 96 07:31:49 -0500 Received: from [153.37.111.46] (pool046.Max2.Raleigh.NC.DYNIP.ALTER.NET [153.37.111.46]) by eitech.eit.com (8.6.12/8.6.12) with SMTP id SAA04133 for ; Fri, 8 Mar 1996 18:36:30 -0800 X-Sender: galvin@pop.eit.com (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="============_-1385786828==_============" Date: Fri, 8 Mar 1996 21:41:08 -0400 To: dns-security@TIS.COM From: "James M. Galvin" Subject: draft revised charter Sender: dns-security-request@neptune.tis.com Precedence: bulk --============_-1385786828==_============ Content-Type: text/plain; charset="us-ascii" Enclosed below is the proposed updated charter for this working group. It includes the secure dynamic update task we started at the Winter IETF. Comments and suggestions for improvement are hereby solicited. I will submit this or its revision to the area director and secretariat next friday, March 15. Thanks, Jim --============_-1385786828==_============ Content-Type: text/plain; name="dnssec-charter-new.txt"; charset="us-ascii" Content-Disposition: attachment; filename="dnssec-charter-new.txt" Domain Name System Security (dnssec) ------------------------------------ Charter Current status: active working group Chair(s): James Galvin Security Area Director(s): Jeffrey Schiller Mailing lists: General Discussion:dns-security@tis.com To Subscribe: dns-security-request@tis.com Archive: ftp://ftp.tis.com/pub/lists/dns-security Description of Working Group: The Domain Name System Security Working Group (DNSSEC) will ensure enhancements to the secure DNS protocol to protect the dynamic update operation of the DNS. Specifically, it must be possible to detect the replay of update transactions and it must be possible to order update transactions. Clock synchronization should be addressed as well as all of the dynamic update specification. Some of the issues to be explored and resolved include o scope of creation, deletion, and updates for both names and zones o protection of names subject to dynamic update during zone transfer o scope of KEY resource record for more specific names in wildcard scope o use of or relationship with proposed expiration resource record One essential assumption has been identified: data in the DNS is considered public information. This assumption means that discussions and proposals involving data confidentiality and access control are explicitly outside the scope of this working group. Goals and Milestones: Spring 96 Working draft for secure dynamic update Summer 96 Revised draft for secure dynamic update Winter 96 Submit proposal for ensuring security of dynamic update of DNS to the IESG for consideration as a Proposed Standard --============_-1385786828==_============ Content-Type: text/plain; charset="us-ascii" ---------------------------------------------------------------------------- James M. Galvin galvin@eit.com VeriFone/EIT, PO Box 220, Glenwood, MD 21738 +1 410.795.6882 --============_-1385786828==_============-- Received: from relay.tis.com by neptune.TIS.COM id aa08393; 11 Mar 96 9:35 EST Received: by relay.tis.com; id JAA14431; Mon, 11 Mar 1996 09:37:39 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma014428; Mon, 11 Mar 96 09:37:12 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA12587; Mon, 11 Mar 96 09:36:11 EST Received: by relay.tis.com; id JAA14420; Mon, 11 Mar 1996 09:37:09 -0500 Received: from unknown(204.178.186.70) by relay.tis.com via smap (V3.1) id xma014398; Mon, 11 Mar 96 09:36:52 -0500 Received: by callandor.cybercash.com; id JAA26348; Mon, 11 Mar 1996 09:44:28 -0500 Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (g3.0.3) id xma026345; Mon, 11 Mar 96 09:44:05 -0500 Received: by cybercash.com (4.1/SMI-4.1) id AA00514; Mon, 11 Mar 96 09:33:55 EST Date: Mon, 11 Mar 1996 09:33:55 -0500 (EST) From: "Donald E. Eastlake 3rd" To: lazear@gateway.mitre.org Cc: dns-security@TIS.COM Subject: Re: Expires RR proposal In-Reply-To: <199603071447.JAA13331@dockside.mitre.org> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dns-security-request@neptune.tis.com Precedence: bulk All data in a secure zone is supposed to be secured. You can only get insecure data from insecure zones. I was only suggesting sending expired SIGs and the data they cover in zone transfers to avoid invalidataing the possibly pre-computed AXFR signature. Allowing any unsigned answer from a secure zone totally destorys all security. Any corrupt server can then answer anything it wants by just leaving out the SIGs. If you permit RRs with expired info to appear in any sort of reply (zone transfer for regular query), it is absolutely essential that the expired SIGs accompany it (unless its truncated in which case it can be obtained by a separate query). Dobnald On Thu, 7 Mar 1996 lazear@gateway.mitre.org wrote: > Date: Thu, 07 Mar 96 09:47:08 -0500 > From: lazear@gateway.mitre.org > To: "Donald E. Eastlake 3rd" > Cc: dns-security@tis.com, lazear@gateway.mitre.org > Subject: Re: Expires RR proposal > > >SIG expiring should certainly wipe out an RR in a cache but it is not at all > >clear to me that it should drop out of a zone and cause the AXFR sig to fail. > >So I think authoritative servers should keep it in the zone. > > I agree...it seems that an expired SIG RR means that the data is no longer > secured, not that it's invalid. Otherwise, how can you tell the difference > between insecure and secured data? Donald suggests sending the expired SIG > with an answer...I'd prefer that the SIG disappear and the answer come back > as unsigned (completely insecure, not just used-to-be secured). > > Walt > ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html Received: from relay.tis.com by neptune.TIS.COM id aa17787; 11 Mar 96 15:32 EST Received: by relay.tis.com; id PAA22684; Mon, 11 Mar 1996 15:34:04 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma022680; Mon, 11 Mar 96 15:33:36 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02143; Mon, 11 Mar 96 15:32:36 EST Received: by relay.tis.com; id PAA22675; Mon, 11 Mar 1996 15:33:34 -0500 Received: from gw.home.vix.com(192.5.5.1) by relay.tis.com via smap (V3.1) id xma022670; Mon, 11 Mar 96 15:33:31 -0500 Received: by gw.home.vix.com id MAA21227; Mon, 11 Mar 1996 12:34:40 -0800 (PST) Date: Mon, 11 Mar 1996 12:34:40 -0800 (PST) X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: dns-security@TIS.COM From: Paul A Vixie Subject: Re: Expires RR proposal Organization: Vixie Enterprises Message-Id: References: <199603071447.JAA13331@dockside.mitre.org> Nntp-Posting-Host: wisdom.home.vix.com In-Reply-To: dee@cybercash.com's message of 11 Mar 1996 07:40:53 -0800 Sender: dns-security-request@neptune.tis.com Precedence: bulk >Allowing any unsigned answer from a secure zone totally destorys all >security. Any corrupt server can then answer anything it wants by just >leaving out the SIGs. If you permit RRs with expired info to appear in >any sort of reply (zone transfer for regular query), it is absolutely >essential that the expired SIGs accompany it (unless its truncated in >which case it can be obtained by a separate query). > >Donald Yes. That's fine. I don't think expired SIGs should cause automatic zone updates; expired SIGs are part of the zone like anything else, and they should be sent in answer along with the data they used to cover. Secure resolvers should ignore the data if the accompanying signature is unavailable (through truncation and failed query) or expired. RRs should _not_ disappear, or appear to disappear, when their SIG expires. -- Paul Vixie La Honda, CA "Illegitimibus non carborundum." pacbell!vixie!paul Received: from relay.tis.com by neptune.TIS.COM id aa21209; 11 Mar 96 17:30 EST Received: by relay.tis.com; id RAA25232; Mon, 11 Mar 1996 17:32:39 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma025228; Mon, 11 Mar 96 17:32:10 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA07918; Mon, 11 Mar 96 17:31:10 EST Received: by relay.tis.com; id RAA25225; Mon, 11 Mar 1996 17:32:09 -0500 Received: from suntan.tandem.com(192.216.221.8) by relay.tis.com via smap (V3.1) id xma025223; Mon, 11 Mar 96 17:32:05 -0500 Received: from adm.loc201.tandem.com by suntan.tandem.com (8.6.12/suntan5.960119) for id OAA29254; Mon, 11 Mar 1996 14:33:15 -0800 Received: from [155.186.130.241] (sanders_mac.loc201.tandem.com) by adm.loc201.tandem.com (4.1/6main.940209) id AA00582; Mon, 11 Mar 96 14:33:08 PST X-Sender: sanders_james\comm@igate.cup.tandem.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Mar 1996 14:33:38 -0800 To: dns-security@TIS.COM From: Jim Sanders Subject: TIS-DNSSEC.Beta1 Download problem Sender: dns-security-request@neptune.tis.com Precedence: bulk Sorry to address the list, but just following the instructions in "ftp.tis.com/pub/DNSSEC/Readme." It seem that TIS' usual convention of hiding the floating subdir until you respond to an ITAR notice is working here...but the README file does not tell me what to do other than "get the file /pub/DNSSEC/dist/dndsec-2d722a/dnssec-beta.1.tgz," which results in "file not found." I assume "2d722a" is an old floater. Where is the key to answer the question that will get me the floating subdir? --Jim-- << Jim Sanders, Staff Scientist - Transaction Security >> << Network Applications Services, Tandem Computers Incorporated >> << Voice: 408-285-4192, FAX: 408-285-2380, Email: sanders_james@tandem.com >> Received: from relay.tis.com by neptune.TIS.COM id aa21672; 11 Mar 96 17:42 EST Received: by relay.tis.com; id RAA25440; Mon, 11 Mar 1996 17:44:41 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma025436; Mon, 11 Mar 96 17:44:39 -0500 Received: from antares.tis.com by tis.com (4.1/SUN-5.64) id AA08411; Mon, 11 Mar 96 17:43:38 EST Date: Mon, 11 Mar 96 17:43:38 EST From: Olafur Gudmundsson Message-Id: <9603112243.AA08411@tis.com> Received: by antares.tis.com (4.1/SMI-4.1) id AA07074; Mon, 11 Mar 96 17:44:18 EST To: "Donald E. Eastlake 3rd" Cc: ogud@TIS.COM, dns-security@TIS.COM Subject: Re: Expires RR proposal In-Reply-To: Your message of "Mon, 11 Mar 1996 09:33:55 EST." Sender: dns-security-request@neptune.tis.com Precedence: bulk "Donald E. Eastlake 3rd" writes: > All data in a secure zone is supposed to be secured. You can only get > insecure data from insecure zones. Not quite true. Zone for example, can not sign the NS records of subzones. If a server for the zone is NOT a secondary for the subzone then it will return the NS records without SIGs. Same goes for zone KEY records, they are not supposed to be signed by the zone, if zone is missing .PARENT file then the KEY will be returned without signatures. In both these cases the records are supposed to be signed by someone else. Zone has the choice of not signing select other records, for example informational records within signing scope of delegated keys. > I was only suggesting sending expired > SIGs and the data they cover in zone transfers to avoid invalidataing the > possibly pre-computed AXFR signature. > > Allowing any unsigned answer from a secure zone totally destorys all > security. Any corrupt server can then answer anything it wants by just > leaving out the SIGs. I disagree, corrupt server can return any data it want, it can lie about the existence/content of any records it is asked about. DNSSEC can prove that the data with SIGs a server returned is valid, but DNSSEC can not prevent a malicious server from trying to lie to you. If you want strong protection against a subverted server, you need to check more than one source. > If you permit RRs with expired info to appear in > any sort of reply (zone transfer for regular query), it is absolutely > essential that the expired SIGs accompany it (unless its truncated in > which case it can be obtained by a separate query). > > ===================================================================== > Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com > 318 Acton Street +1 508-371-7148(fax) dee@world.std.com > Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) > http://www.cybercash.com http://www.eff.org/blueribbon.html > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Olafur Gudmundsson ogud@tis.com (410)-442-0039 x400 489-4688 FAX (Baltimore Numbers) http://www.tis.com/docs/Research/iip/dnssec.html Received: from relay.tis.com by neptune.TIS.COM id aa22039; 12 Mar 96 16:47 EST Received: by relay.tis.com; id QAA10729; Tue, 12 Mar 1996 16:49:12 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma010725; Tue, 12 Mar 96 16:48:44 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA19188; Tue, 12 Mar 96 16:47:43 EST Received: by relay.tis.com; id QAA10719; Tue, 12 Mar 1996 16:48:42 -0500 Received: from callandor.cybercash.com(204.178.186.70) by relay.tis.com via smap (V3.1) id xma010714; Tue, 12 Mar 96 16:48:13 -0500 Received: by callandor.cybercash.com; id QAA27185; Tue, 12 Mar 1996 16:55:58 -0500 Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (g3.0.3) id xma027182; Tue, 12 Mar 96 16:55:33 -0500 Received: by cybercash.com (4.1/SMI-4.1) id AA19422; Tue, 12 Mar 96 16:45:16 EST Date: Tue, 12 Mar 1996 16:45:16 -0500 (EST) From: "Donald E. Eastlake 3rd" To: Olafur Gudmundsson Cc: dns-security@TIS.COM Subject: Re: Expires RR proposal In-Reply-To: <9603112243.AA08411@tis.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dns-security-request@neptune.tis.com Precedence: bulk On Mon, 11 Mar 1996, Olafur Gudmundsson wrote: > Date: Mon, 11 Mar 96 17:43:38 EST > From: Olafur Gudmundsson > To: "Donald E. Eastlake 3rd" > Cc: ogud@tis.com, dns-security@tis.com > Subject: Re: Expires RR proposal > > "Donald E. Eastlake 3rd" writes: > > All data in a secure zone is supposed to be secured. You can only get > > insecure data from insecure zones. > Not quite true. > Zone for example, can not sign the NS records of subzones. > If a server for the zone is NOT a secondary for the subzone then it will > return the NS records without SIGs. > Same goes for zone KEY records, they are not supposed to be signed by > the zone, if zone is missing .PARENT file then the KEY will be > returned without signatures. > In both these cases the records are supposed to be signed by someone else. > Zone has the choice of not signing select other records, for example > informational records within signing scope of delegated keys. You are correct. Non-authoritative data isn't signed. > > I was only suggesting sending expired > > SIGs and the data they cover in zone transfers to avoid invalidataing the > > possibly pre-computed AXFR signature. > > > > Allowing any unsigned answer from a secure zone totally destorys all > > security. Any corrupt server can then answer anything it wants by just > > leaving out the SIGs. > I disagree, corrupt server can return any data it want, > it can lie about the existence/content of any records it is asked about. > DNSSEC can prove that the data with SIGs a server returned is valid, > but DNSSEC can not prevent a malicious server from trying to lie to you. > If you want strong protection against a subverted server, > you need to check more than one source. What I should have said is that if the same data can sometimes appear securely signed and sometimes not when being fetched from a secure zone from a security compliant server, then allowing the unsigned version opens you to accepting these lies. On of the reasons for the NXT RR is so that you get something back signed even for non-exitent names and types... > > If you permit RRs with expired info to appear in > > any sort of reply (zone transfer for regular query), it is absolutely > > essential that the expired SIGs accompany it (unless its truncated in > > which case it can be obtained by a separate query). This was my main point. If data is supposed to be signed, then you can't accept an unsigned statement that it has expired, you need a signed statement. > > ===================================================================== > > Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com > > 318 Acton Street +1 508-371-7148(fax) dee@world.std.com > > Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) > > http://www.cybercash.com http://www.eff.org/blueribbon.html > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Olafur Gudmundsson ogud@tis.com > (410)-442-0039 x400 489-4688 FAX (Baltimore Numbers) > http://www.tis.com/docs/Research/iip/dnssec.html Donald ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html Received: from relay.tis.com by neptune.TIS.COM id aa14066; 14 Mar 96 13:22 EST Received: by relay.tis.com; id NAA07888; Thu, 14 Mar 1996 13:24:00 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma007886; Thu, 14 Mar 96 13:23:31 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA29794; Thu, 14 Mar 96 13:22:29 EST Received: by relay.tis.com; id NAA07880; Thu, 14 Mar 1996 13:23:30 -0500 Received: from netcom9.netcom.com(192.100.81.119) by relay.tis.com via smap (V3.1) id xma007877; Thu, 14 Mar 96 13:23:28 -0500 Received: by netcom9.netcom.com (8.6.13/Netcom) id KAA14604; Thu, 14 Mar 1996 10:24:13 -0800 Date: Thu, 14 Mar 1996 10:24:13 -0800 From: John Kennedy Message-Id: <199603141824.KAA14604@netcom9.netcom.com> To: cat-ietf@mit.edu, dns-security@TIS.COM, ietf-pkix@tandem.com, ipsec@TIS.COM, spki@c2.org, www-security@nsmx.rutgers Subject: CYLINK's Support for Open Public Key Standards Sender: dns-security-request@neptune.tis.com Precedence: bulk ---------------------------------------------------------------------------- CYLINK Corporation March 14, 1996 The following is a copy of an announcement I made in the IPSEC and PKIX working group sessions at IETF Los Angeles. In response to numerous requests, I am posting a copy of the announcement to the applicable IETF working group mailing lists. -John Kennedy, CYLINK ---------------------------------------------------------------------------- CYLINK'S SUPPORT FOR OPEN PUBLIC KEY STANDARDS EXISTING AND PROSPECTIVE CYLINK LICENSEES OF THE STANFORD PUBLIC KEY PATENTS MAY SUPPLEMENT THEIR LICENSES IN ACCORDANCE WITH THE FOLLOWING STATEMENT.: ATTACHMENT "A" STATEMENT OF PATENT POSITION Cylink Corporation, through its wholly owned subsidiary Caro-Kann Corporation, holds exclusive sublicensing rights to the following U.S. patents owned by the Leland Stanford Junior University: Cryptographic Apparatus and Method ("Hellman-Diffie")......................... No. 4,200,770 Public Key Cryptographic Apparatus and Method ("Hellman-Merkle")............. No. 4,218,582 In order to promote the widespread use of these inventions from Stanford University and adoption of the [Name IETF Standard] reference by the IETF community, [Name of Licensee] has acquired the right under its sublicense from Cylink to offer the [Name IETF Standard] reference implementation to all third parties on a royalty free basis. This royalty free privilege is limited to use of the [Name IETF Standard] reference implementation in accordance with proposed, pending or approved IETF standards, and applies only when used with Diffie- Hellman key exchange, the Digital Signature Standard, or any other public key techniques which are publicly available for commercial use on a royalty free basis. Any use of the [Name IETF Standard] reference implementation which does not satisfy these conditions and incorporates the practice of public key may require a separate patent license to the Stanford Patents which must be negotiated with Cylink's subsidiary, Caro-Kann Corporation. For additional licensing information please contact: Robert Fougner Director of Licensing CYLINK Corporation 910 Hermosa Court Sunnyvale, CA 94086 (408) 735-5893 ---------------------------------------------------------------------------- Received: from relay.tis.com by neptune.TIS.COM id aa16011; 14 Mar 96 14:10 EST Received: by relay.tis.com; id OAA08747; Thu, 14 Mar 1996 14:12:30 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma008725; Thu, 14 Mar 96 14:12:01 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02563; Thu, 14 Mar 96 14:10:59 EST Received: by relay.tis.com; id OAA08722; Thu, 14 Mar 1996 14:12:00 -0500 Received: from chimay.mach.cs.cmu.edu(128.2.222.167) by relay.tis.com via smap (V3.1) id xma008720; Thu, 14 Mar 96 14:11:59 -0500 Received: from CHIMAY.MACH.CS.CMU.EDU by CHIMAY.MACH.CS.CMU.EDU id aa19577; 14 Mar 96 14:10:48 EST To: John Kennedy Cc: cat-ietf@mit.edu, dns-security@TIS.COM, ietf-pkix@tandem.com, ipsec@TIS.COM, spki@c2.org In-Reply-To: Your message of "Thu, 14 Mar 96 10:24:13 PST" <199603141824.KAA14604@netcom9.netcom.com> From: Dave Johnson Subject: Re: CYLINK's Support for Open Public Key Standards Date: Thu, 14 Mar 96 14:10:46 EST Message-Id: <19575.826830646@CHIMAY.MACH.CS.CMU.EDU> Sender: dns-security-request@neptune.tis.com Precedence: bulk >---------------------------------------------------------------------------- > >CYLINK Corporation >March 14, 1996 > > >The following is a copy of an announcement I made in the IPSEC >and PKIX working group sessions at IETF Los Angeles. In response to >numerous requests, I am posting a copy of the announcement to the >applicable IETF working group mailing lists. > >-John Kennedy, CYLINK > > >---------------------------------------------------------------------------- > >CYLINK'S SUPPORT FOR OPEN PUBLIC KEY STANDARDS > >EXISTING AND PROSPECTIVE CYLINK LICENSEES OF THE STANFORD PUBLIC >KEY PATENTS MAY SUPPLEMENT THEIR LICENSES IN ACCORDANCE WITH THE >FOLLOWING STATEMENT.: > > >ATTACHMENT "A" > > >STATEMENT OF PATENT POSITION > >Cylink Corporation, through its wholly owned subsidiary Caro-Kann >Corporation, holds exclusive sublicensing rights to the following >U.S. patents owned by the Leland Stanford Junior University: > > Cryptographic Apparatus and Method > ("Hellman-Diffie")......................... No. 4,200,770 > > Public Key Cryptographic Apparatus and Method > ("Hellman-Merkle")............. No. 4,218,582 > >In order to promote the widespread use of these inventions >from Stanford University and adoption of the [Name IETF Standard] >reference by the IETF community, [Name of Licensee] has acquired >the right under its sublicense from Cylink to offer the [Name IETF >Standard] reference implementation to all third parties on a royalty free >basis. > >This royalty free privilege is limited to use of the [Name IETF >Standard] reference implementation in accordance with proposed, >pending or approved IETF standards, and applies only when used with >Diffie- Hellman key exchange, the Digital Signature Standard, or any other >public key techniques which are publicly available for commercial >use on a royalty free basis. Any use of the [Name IETF Standard] reference >implementation which does not satisfy these conditions and incorporates >the practice of public key may require a separate patent license >to the Stanford Patents which must be negotiated with Cylink's >subsidiary, Caro-Kann Corporation. > > >For additional licensing information please contact: > > Robert Fougner > Director of Licensing > CYLINK Corporation > 910 Hermosa Court > Sunnyvale, CA 94086 > (408) 735-5893 > >---------------------------------------------------------------------------- How does this apply to a non-profit organization (such as a university) that wants to make a "reference implementation" of an IETF protocol (that uses Diffie-Hellman) freely available? Under the RSAREF license, I think this was possible, but has this changed things? Dave -- David B. Johnson E-mail: dbj@cs.cmu.edu Assistant Professor Home page: http://www.cs.cmu.edu/~dbj Computer Science Department Phone: (412) 268-7399 Carnegie Mellon University Fax: (412) 268-5576 5000 Forbes Avenue Pittsburgh, PA 15213-3891 Received: from relay.tis.com by neptune.TIS.COM id aa15318; 18 Mar 96 13:54 EST Received: by relay.tis.com; id NAA23715; Mon, 18 Mar 1996 13:56:21 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma023709; Mon, 18 Mar 96 13:55:52 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02084; Mon, 18 Mar 96 13:54:46 EST Received: by relay.tis.com; id NAA23702; Mon, 18 Mar 1996 13:55:51 -0500 Received: from eitech.eit.com(192.100.58.2) by relay.tis.com via smap (V3.1) id xma023695; Mon, 18 Mar 96 13:55:37 -0500 Received: from [153.37.6.62] (pool038.Max6.Washington.DC.DYNIP.ALTER.NET [153.37.6.38]) by eitech.eit.com (8.6.12/8.6.12) with SMTP id KAA08485; Mon, 18 Mar 1996 10:56:35 -0800 X-Sender: galvin@pop.eit.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 18 Mar 1996 14:01:36 -0400 To: "James M. Galvin" From: "James M. Galvin" Subject: Re: draft Minutes of Spring IETF 1996 Cc: dns-security@TIS.COM Sender: dns-security-request@neptune.tis.com Precedence: bulk Hearing no comments on the draft minutes I have submitted them to the secretariat for posting to the IETF online directories and inclusion in the proceedings. Thanks, Jim ---------------------------------------------------------------------------- James M. Galvin galvin@eit.com VeriFone/EIT, PO Box 220, Glenwood, MD 21738 +1 410.795.6882 Received: from relay.tis.com by neptune.TIS.COM id aa15317; 18 Mar 96 13:54 EST Received: by relay.tis.com; id NAA23714; Mon, 18 Mar 1996 13:56:21 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma023710; Mon, 18 Mar 96 13:55:52 -0500 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02085; Mon, 18 Mar 96 13:54:47 EST Received: by relay.tis.com; id NAA23700; Mon, 18 Mar 1996 13:55:51 -0500 Received: from eitech.eit.com(192.100.58.2) by relay.tis.com via smap (V3.1) id xma023693; Mon, 18 Mar 96 13:55:34 -0500 Received: from [153.37.6.62] (pool038.Max6.Washington.DC.DYNIP.ALTER.NET [153.37.6.38]) by eitech.eit.com (8.6.12/8.6.12) with SMTP id KAA08474; Mon, 18 Mar 1996 10:56:27 -0800 X-Sender: galvin@pop.eit.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 18 Mar 1996 14:01:27 -0400 To: "James M. Galvin" From: "James M. Galvin" Subject: Re: draft revised charter Cc: dns-security@TIS.COM Sender: dns-security-request@neptune.tis.com Precedence: bulk Hearing no comments on the proposed charter I have submitted it as an update to the IETF online directories. Thanks, Jim ---------------------------------------------------------------------------- James M. Galvin galvin@eit.com VeriFone/EIT, PO Box 220, Glenwood, MD 21738 +1 410.795.6882 Received: from relay.tis.com by neptune.TIS.COM id aa13801; 8 Apr 96 23:26 EDT Received: by relay.tis.com; id XAA19425; Mon, 8 Apr 1996 23:28:45 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma019423; Mon, 8 Apr 96 23:28:16 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA03437; Mon, 8 Apr 96 23:27:10 EDT Received: by relay.tis.com; id XAA19420; Mon, 8 Apr 1996 23:28:15 -0400 Received: from ctrvx1.vanderbilt.edu(129.59.1.21) by relay.tis.com via smap (V3.1) id xma019418; Mon, 8 Apr 96 23:27:53 -0400 Received: from ctrvax.Vanderbilt.Edu by ctrvax.Vanderbilt.Edu (PMDF V5.0-5 #11488) id <01I3B9Q8SFOG8XEC6E@ctrvax.Vanderbilt.Edu> for listys@ctrvax.Vanderbilt.Edu; Mon, 08 Apr 1996 21:03:19 -0500 (CDT) Date: Mon, 08 Apr 1996 21:03:19 -0500 (CDT) From: BEZALEL GAVISH Subject: Proceedings of 4th International Conference on Telecommunications Systems To: listys: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Message-Id: <01I3B9Q8SPBM8XEC6E@ctrvax.Vanderbilt.Edu> X-Vms-To: IN%"listys" X-Vms-Cc: GAVISHB Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: dns-security-approval@neptune.tis.com Precedence: bulk The fourth International Conference on Telecommunication Systems was held March 21-24, 1996, in Nashville, TN. Close to 150 participants from 27 countries gave over 85 presentations on a variety of topics. Proceedings containing the papers presented during the conference have been produced. A few remaining copies of the proceedings are available for sale. The table of contents and ordering information are located at URL http://www.vanderbilt.edu/Owen/gavish/tsm96proceedings.html ------------------------------------------------------------------------------- Bezalel Gavish Owen Graduate School of Management Vanderbilt University Nashville, TN, 37203 Bitnet: GAVISHB@VUCTRVAX Internet: GAVISHB@CTRVAX.VANDERBILT.EDU Tel: (615) 322-3659 Home: (615) 370-0813 FAX: (615) 343-7177 ------------------------------------------------------------------------------- Received: from relay.tis.com by neptune.TIS.COM id aa19194; 16 May 96 19:04 EDT Received: by relay.tis.com; id TAA03645; Thu, 16 May 1996 19:05:43 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma003643; Thu, 16 May 96 19:05:14 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA14788; Thu, 16 May 96 19:05:26 EDT Received: by relay.tis.com; id TAA03640; Thu, 16 May 1996 19:05:13 -0400 Received: from toad.com(140.174.2.1) by relay.tis.com via smap (V3.1) id xma003634; Thu, 16 May 96 19:04:45 -0400 Received: from localhost (localhost [127.0.0.1]) by toad.com (8.7.5/8.7.3) with SMTP id QAA21043; Thu, 16 May 1996 16:07:19 -0700 (PDT) Message-Id: <199605162307.QAA21043@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: dns-security@TIS.COM, gnu@toad.com Subject: Lame delegation for sd-bogus.tis.com Date: Thu, 16 May 1996 16:07:18 -0700 From: John Gilmore Sender: dns-security-approval@neptune.tis.com Precedence: bulk I've been testing against your Secure DNS server. This isn't a bug report against the code, but against the domain records you are serving from TIS. The NS records for sd-bogus.tis.com at its parent, tis.com, say that you have two name servers for it, relay.tis.com and uranus.tis.com. This isn't actually true, though. relay.tis.com is not authoritative for sd-bogus.tis.com, and uranus.tis.com only lists itself as a name server for sd-bogus.tis.com. I suggest fixing the records at the tis.com servers, so that they only list uranus.tis.com. John Gilmore Received: from relay.tis.com by neptune.TIS.COM id aa04433; 17 May 96 13:33 EDT Received: by relay.tis.com; id NAA16352; Fri, 17 May 1996 13:35:22 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma016320; Fri, 17 May 96 13:34:58 -0400 Received: from antares.tis.com by tis.com (4.1/SUN-5.64) id AA11648; Fri, 17 May 96 13:35:10 EDT Message-Id: <9605171735.AA11648@tis.com> To: John Gilmore Cc: dns-security@TIS.COM Subject: Re: Lame delegation for sd-bogus.tis.com In-Reply-To: Your message of "Thu, 16 May 1996 16:07:18 MST." <199605162307.QAA21043@toad.com> Date: Fri, 17 May 1996 13:35:16 -0500 From: Olafur Gudmundsson Sender: dns-security-approval@neptune.tis.com Precedence: bulk John Gilmore writes: > I've been testing against your Secure DNS server. This isn't a bug > report against the code, but against the domain records you are > serving from TIS. > > The NS records for sd-bogus.tis.com at its parent, tis.com, say that > you have two name servers for it, relay.tis.com and uranus.tis.com. > > This isn't actually true, though. > relay.tis.com is not authoritative for sd-bogus.tis.com, and > uranus.tis.com only lists itself as a name server for sd-bogus.tis.com. > > I suggest fixing the records at the tis.com servers, so that they > only list uranus.tis.com. > > John Gilmore > Thanks pointing this out, the NS records have been fixed Olafur Received: from relay.tis.com by neptune.TIS.COM id aa24241; 29 May 96 8:07 EDT Received: by relay.tis.com; id IAA22052; Wed, 29 May 1996 08:08:29 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma022050; Wed, 29 May 96 08:08:00 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA06752; Wed, 29 May 96 08:08:08 EDT Received: by relay.tis.com; id IAA22047; Wed, 29 May 1996 08:07:59 -0400 Received: from toad.com(140.174.2.1) by relay.tis.com via smap (V3.1) id xma022045; Wed, 29 May 96 08:07:37 -0400 Received: from localhost (localhost [127.0.0.1]) by toad.com (8.7.5/8.7.3) with SMTP id FAA23126; Wed, 29 May 1996 05:10:11 -0700 (PDT) Message-Id: <199605291210.FAA23126@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: dns-security@TIS.COM, gnu@toad.com Subject: CD bit set incorrectly in query responses; SIG-only responses Date: Wed, 29 May 1996 05:10:10 -0700 From: John Gilmore Sender: dns-security-approval@neptune.tis.com Precedence: bulk [Last time I sent email to this address I received a flame back from someone I had never met. If this is the wrong address to report bugs in the TIS DNS Security code, somebody please let me know the right one.] I'm testing an independent implementation of DNS Security against the TIS server. I've found that when sending DNS requests to uranus.tis.com, I get back query headers that set the "CD" bit (checking disabled), even though my resolver never sent queries that set the bit. I verified this with an ethernet packet monitor. (This may have never been tested, since old dig's won't print the CD bit, and your new dig's may be setting the CD bit themselves.) Try: dig @uranus.tis.com sd-bogus.tis.com. soa Here's what I get: ; <<>> DiG 2.1 <<>> @uranus.tis.com sd-bogus.tis.com. soa ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 ;; flags: qr aa rd ra cd; Ques: 1, Ans: 1, Auth: 1, Addit: 0 ;; QUESTIONS: ;; sd-bogus.tis.com, type = SOA, class = IN ;; ANSWERS: sd-bogus.tis.com. 10000 SIG SOA 1 10000 833143035 830551042 0xbfd2 sd-bogus.tis.com. PoW60a+MQzjdXjjF4xgvtZ9ZkAUKCKnlTkPitGAyzFbRzbJd136a8OHvnViRFo6udNJLUYccfdQvfVcS0o2kVsRTMkQpp/Z+/9/rHFAPHXE= ;; AUTHORITY RECORDS: sd-bogus.tis.com. 10000 SIG NS 1 10000 833143035 830551042 0xbfd2 sd-bogus.tis.com. u0ZPTKcyHyg6pZDb22nWPVDNlNqY2Bkeh6WyVwTIM0KPDi6ghaLybMsp2QhHOg4YawC4Ky0EtKcf/ckCOY/Zc+Q9apn+u5P2jcFRxSDOHgc= ;; Total query time: 90 msec ;; FROM: toad.com to SERVER: uranus.tis.com 192.94.214.95 ;; WHEN: Wed May 29 05:03:58 1996 ;; MSG SIZE sent: 34 rcvd: 258 Note also that the query results themselves are also incorrect. Though I asked for an SOA record, I got back one SIG record, but no SOA records. The additional data section includes a SIG record but no NS records. I get this same result (query results only include SIGs) using TIS's dig program instead of my own. I'll append that output below. John Gilmore ; <<>> DiG 2.1 <<>> @uranus.tis.com sd-bogus.tis.com. soa ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 ;; flags: qr aa rd ra ad; Ques: 1, Ans: 1, Auth: 1, Addit: 0 ;; QUESTIONS: ;; sd-bogus.tis.com, type = SOA, class = IN ;; ANSWERS: sd-bogus.tis.com. 10000 SIG SOA ( 1 ; alg labels=3 10000 ; TTL 19960526203715 ; Signature expiration 19960426203722 ; time signed 49106 ; Key foot print sd-bogus.tis.com. ; Signers name PoW60a+MQzjdXjjF4xgvtZ9ZkAUKCKnlTkPitGAyzFbRzbJd136a8OHvnViRFo6udNJLUYccfdQvfVcS0o2kVsRTMkQpp/Z+/9/rHFAPHXE= ) ; END Signature ;; AUTHORITY RECORDS: sd-bogus.tis.com. 10000 SIG NS ( 1 ; alg labels=3 10000 ; TTL 19960526203715 ; Signature expiration 19960426203722 ; time signed 49106 ; Key foot print sd-bogus.tis.com. ; Signers name u0ZPTKcyHyg6pZDb22nWPVDNlNqY2Bkeh6WyVwTIM0KPDi6ghaLybMsp2QhHOg4YawC4Ky0EtKcf/ckCOY/Zc+Q9apn+u5P2jcFRxSDOHgc= ) ; END Signature ;; Total query time: 116 msec ;; FROM: toad.com to SERVER: uranus.tis.com 192.94.214.95 ;; WHEN: Wed May 29 05:04:09 1996 ;; MSG SIZE sent: 34 rcvd: 258 Received: from relay.tis.com by neptune.TIS.COM id aa25546; 29 May 96 9:22 EDT Received: by relay.tis.com; id JAA25148; Wed, 29 May 1996 09:23:51 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma025131; Wed, 29 May 96 09:23:42 -0400 Received: from antares.tis.com by tis.com (4.1/SUN-5.64) id AA12299; Wed, 29 May 96 09:23:47 EDT Message-Id: <9605291323.AA12299@tis.com> To: John Gilmore Cc: ogud@TIS.COM, tisdnssec-support@TIS.COM, dns-security@TIS.COM Subject: Re: CD bit set incorrectly in query responses; SIG-only responses In-Reply-To: Your message of "Wed, 29 May 1996 05:10:10 PDT." <199605291210.FAA23126@toad.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <14082.833376243.1@tis.com> Date: Wed, 29 May 1996 09:24:05 -0400 From: Olafur Gudmundsson Sender: dns-security-approval@neptune.tis.com Precedence: bulk John Gilmore writes: > [Last time I sent email to this address I received a flame back from > someone I had never met. If this is the wrong address to report bugs > in the TIS DNS Security code, somebody please let me know the nright one.] The address to reach the implementers is tisdnssec-support@tis.com I think this mailing list is an appropriate forum to discuss inter-operational issues. If someone has problems with that please speak up. I will reply to John's other questions after I have a cup of coffee and check the code. Olafur Received: from relay.tis.com by neptune.TIS.COM id aa01522; 29 May 96 14:26 EDT Received: by relay.tis.com; id OAA06101; Wed, 29 May 1996 14:28:31 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma006092; Wed, 29 May 96 14:28:23 -0400 Received: from antares.tis.com.tis.com by tis.com (4.1/SUN-5.64) id AA28649; Wed, 29 May 96 14:28:29 EDT Date: Wed, 29 May 96 14:28:29 EDT From: Olafur Gudmundsson Message-Id: <9605291828.AA28649@tis.com> Received: by antares.tis.com.tis.com (4.1/SMI-4.1) id AA14480; Wed, 29 May 96 14:28:48 EDT To: John Gilmore Cc: ogud@TIS.COM, tisdnssec-support@TIS.COM, dns-security@TIS.COM Subject: Re: CD bit set incorrectly in query responses; SIG-only responses In-Reply-To: Your message of "Wed, 29 May 1996 05:10:10 PDT." <199605291210.FAA23126@toad.com> Sender: dns-security-approval@neptune.tis.com Precedence: bulk John Gilmore writes: > I'm testing an independent implementation of DNS Security against the > TIS server. I've found that when sending DNS requests to > uranus.tis.com, I get back query headers that set the "CD" bit > (checking disabled), even though my resolver never sent queries that > set the bit. I verified this with an ethernet packet monitor. (This > may have never been tested, since old dig's won't print the CD bit, > and your new dig's may be setting the CD bit themselves.) Try: > > dig @uranus.tis.com sd-bogus.tis.com. soa > > Here's what I get: > > ; <<>> DiG 2.1 <<>> @uranus.tis.com sd-bogus.tis.com. soa > ; (1 server found) > ;; res options: init recurs defnam dnsrch > ;; got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 > ;; flags: qr aa rd ra cd; Ques: 1, Ans: 1, Auth: 1, Addit: 0 > ;; QUESTIONS: > ;; sd-bogus.tis.com, type = SOA, class = IN > > ;; ANSWERS: > sd-bogus.tis.com. 10000 SIG SOA 1 10000 833143035 830551042 0xbfd2 >> sd-bogus.tis.com. PoW60a+MQzjdXjjF4xgvtZ9ZkAUKCKnlTkPitGAyzFbRzbJd136a8OHvn >>ViRFo6udNJLUYccfdQvfVcS0o2kVsRTMkQpp/Z+/9/rHFAPHXE= > > ;; AUTHORITY RECORDS: > sd-bogus.tis.com. 10000 SIG NS 1 10000 833143035 830551042 0xbfd2 >>sd-bogus.tis.com. u0ZPTKcyHyg6pZDb22nWPVDNlNqY2Bkeh6WyVwTIM0KPDi6ghaLybMsp2Q >>hHOg4YawC4Ky0EtKcf/ckCOY/Zc+Q9apn+u5P2jcFRxSDOHgc= > > ;; Total query time: 90 msec > ;; FROM: toad.com to SERVER: uranus.tis.com 192.94.214.95 > ;; WHEN: Wed May 29 05:03:58 1996 > ;; MSG SIZE sent: 34 rcvd: 258 John Good to have you implement DNSSEC. I do not see the CD bit set. (Notice that in the output from my version of dig in your original question below, the cd bit is not reported as set). There is one place in my code that sets the cd bit (in mk_query()). When the bind server is answering the query above it does not execute that line. When running gdb dig I get the following header with the above query. (gdb) where #0 __fp_nquery (msg=0xefffd778 "", len=136, file=0x232b4) at res_debug.c:342 #1 0x1a934 in res_send (buf=0xeffff778 "", buflen=34, ans=0xefffd778 "", anssiz=8192) at res_send.c:708 #2 0x4598 in main (argc=3, argv=0xefffd384) at dig.c:660 (gdb) p *hp $6 = {id = 6, qr = 1, opcode = 0, aa = 0, tc = 0, rd = 1, ra = 1, unused = 0, cd = 0, ad = 0, rcode = 0, qdcount = 1, ancount = 1, nscount = 1, arcount = 1} Neither CD or AD bit is set. This looks like your and my implementation do not agree on the location of cd bit. (an inter-operation problem that we need to figure out). The values of the third and fourth byte (header flags) are (on a Sparc) (gdb) printf "%x %x\n", *(msg+2), *(msg+3) 81 80 If the CD bit was set the value of the fourth byte would be "a0" > > > Note also that the query results themselves are also incorrect. > Though I asked for an SOA record, I got back one SIG record, but > no SOA records. The additional data section includes a SIG record > but no NS records. > > I get this same result (query results only include SIGs) using TIS's > dig program instead of my own. I'll append that output below. > > John Gilmore This is the current behavior when the signatures have expired!! NOT correct and not the best one but one that people notice. This is one of the open questions in the DNSSEC work. What to return when the signatures expire. DNSSEC draft does not explicitly state what to return, and we should talk about this issue. John lets take the inter-operation question of the CD bit off-line and resolve it. I will raise the larger question of what to return when the data is expired, on this and other appropriate mailing lists. Olafur > > ; <<>> DiG 2.1 <<>> @uranus.tis.com sd-bogus.tis.com. soa > ; (1 server found) > ;; res options: init recurs defnam dnsrch > ;; got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 > ;; flags: qr aa rd ra ad; Ques: 1, Ans: 1, Auth: 1, Addit: 0 > ;; QUESTIONS: > ;; sd-bogus.tis.com, type = SOA, class = IN > > ;; ANSWERS: > sd-bogus.tis.com. 10000 SIG SOA ( > 1 ; alg labels=3 > 10000 ; TTL > 19960526203715 ; Signature expiration > 19960426203722 ; time signed > 49106 ; Key foot print > sd-bogus.tis.com. ; Signers name > PoW60a+MQzjdXjjF4xgvtZ9ZkAUKCKnlTkPitGAyzFbRzbJd136a8OHvnViRFo6 >>udNJLUYccfdQvfVcS0o2kVsRTMkQpp/Z+/9/rHFAPHXE= > ) ; END Signature > > ;; AUTHORITY RECORDS: > sd-bogus.tis.com. 10000 SIG NS ( > 1 ; alg labels=3 > 10000 ; TTL > 19960526203715 ; Signature expiration > 19960426203722 ; time signed > 49106 ; Key foot print > sd-bogus.tis.com. ; Signers name > u0ZPTKcyHyg6pZDb22nWPVDNlNqY2Bkeh6WyVwTIM0KPDi6ghaLybMsp2QhHOg4 >>YawC4Ky0EtKcf/ckCOY/Zc+Q9apn+u5P2jcFRxSDOHgc= > ) ; END Signature > > ;; Total query time: 116 msec > ;; FROM: toad.com to SERVER: uranus.tis.com 192.94.214.95 > ;; WHEN: Wed May 29 05:04:09 1996 > ;; MSG SIZE sent: 34 rcvd: 258 > Received: from relay.tis.com by neptune.TIS.COM id aa20855; 30 May 96 11:40 EDT Received: by relay.tis.com; id LAA25186; Thu, 30 May 1996 11:41:38 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma025181; Thu, 30 May 96 11:41:11 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA19552; Thu, 30 May 96 11:41:18 EDT Received: by relay.tis.com; id LAA25172; Thu, 30 May 1996 11:41:09 -0400 Received: from igw2.watson.ibm.com(129.34.139.6) by relay.tis.com via smap (V3.1) id xma025167; Thu, 30 May 96 11:41:01 -0400 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.7.4/8.7.1) with ESMTP id LAA19926 for ; Thu, 30 May 1996 11:43:55 -0400 Received: from edisto.watson.ibm.com (edisto.watson.ibm.com [9.2.23.43]) by mailhub1.watson.ibm.com (8.7.1/03-28-96) with SMTP id LAA43959 for ; Thu, 30 May 1996 11:43:36 -0400 Received: by edisto.watson.ibm.com (AIX 3.2/UCB 5.64/900524) id AA20189; Thu, 30 May 1996 11:43:46 -0400 Message-Id: <9605301543.AA20189@edisto.watson.ibm.com> X-External-Networks: yes To: dns-security@TIS.COM Subject: Secure DNS Dynamic Update draft Date: Thu, 30 May 96 11:43:46 -0500 From: "Edie E. Gunter" Sender: dns-security-approval@neptune.tis.com Precedence: bulk Using the security scheme outlined in this draft, how does one dynamically add a new name to a DNS database? That is, the name doesn't exist in DNS and I want to send in an update to create it there, so I need to authenticate the update with a KEY of some sort. Which KEY would that be? Section 3.1.1 seems to suggest that there would be a wildcard already defined for the zone, and I should have the private part of that key in order to sign my update. Is that correct? What about the zone key? If there is a zone key defined (and there must be, right?) then can I use it to sign an update that creates a new name? Then, is there anything special about setting up a "user" KEY RR for this new name? I want to allow a user to do further updates on that name using its own KEY rather than a wildcard or zone key. Would this new KEY RR being created dynamically just be signed by the wildcard key or zone key as above? This would seem to satisfy the requirement that its authority be traceable to the zone key, but is there some other subltely I'm missing? It seems that the wildcard key, like the zone key is one that you'd want to keep to just an administrator or two. You wouldn't want everyone to have the private part of the wildcard key, or they could step on each other's updates using it for authentication, right? So, this would imply that adding new names is something that a sys-admin would do and is not something that individual users would do on their own. Is that the intention? Edie Received: from relay.tis.com by neptune.TIS.COM id aa05113; 3 Jun 96 23:45 EDT Received: by relay.tis.com; id XAA04151; Mon, 3 Jun 1996 23:47:14 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma004147; Mon, 3 Jun 96 23:46:46 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA03760; Mon, 3 Jun 96 23:46:51 EDT Received: by relay.tis.com; id XAA04141; Mon, 3 Jun 1996 23:46:44 -0400 Received: from callandor.cybercash.com(204.178.186.70) by relay.tis.com via smap (V3.1) id xma004135; Mon, 3 Jun 96 23:46:25 -0400 Received: by callandor.cybercash.com; id XAA21383; Mon, 3 Jun 1996 23:46:20 -0400 Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (V3.1) id xma021370; Mon, 3 Jun 96 23:45:53 -0400 Received: by cybercash.com (4.1/SMI-4.1) id AA00247; Mon, 3 Jun 96 23:43:32 EDT Date: Mon, 3 Jun 1996 23:43:31 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: "Edie E. Gunter" Cc: dns-security@TIS.COM Subject: Re: Secure DNS Dynamic Update draft In-Reply-To: <9605301543.AA20189@edisto.watson.ibm.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dns-security-approval@neptune.tis.com Precedence: bulk On Thu, 30 May 1996, Edie E. Gunter wrote: > Date: Thu, 30 May 96 11:43:46 -0500 > From: Edie E. Gunter > To: dns-security@TIS.COM > Subject: Secure DNS Dynamic Update draft > > Using the security scheme outlined in this draft, how does one > dynamically add a new name to a DNS database? That is, the name > doesn't exist in DNS and I want to send in an update to create > it there, so I need to authenticate the update with a KEY of some > sort. Which KEY would that be? Section 3.1.1 seems to suggest that > there would be a wildcard already defined for the zone, and I should > have the private part of that key in order to sign my update. Is > that correct? What about the zone key? If there is a zone > key defined (and there must be, right?) then can I use it > to sign an update that creates a new name? The general idea is to use a wildcard named key to sign an update to add a new name. This is not necessarily at the zone level. You could have *.foo.zone.tld be the owner name of a KEY RR that authorizes adding inferior names (such aas bar.foo.zone.tld) where zone.tld is the zone name. A zone key is very powerful. It seem unlikely that you would want to distribute it to outside entities doing updates. If the zone owner itself, who signs the zone, is also doing the updates, there are lots of ways it can do that, like just signing a new version of the zone. > Then, is there anything special about setting up a "user" KEY > RR for this new name? I want to allow a user to do further > updates on that name using its own KEY rather than a wildcard > or zone key. Would this new KEY RR being created dynamically > just be signed by the wildcard key or zone key as above? This > would seem to satisfy the requirement that its authority be > traceable to the zone key, but is there some other subltely > I'm missing? The update adding the "user" KEY with a non-zero signatory field would probably be signed by a wildcard KEY. The entry that ends up in the zone might or might not be signed by the zone key depending on which mode the secure dynamic zone is operating in. If not signed by the zone key it would be signed by the update key. > It seems that the wildcard key, like the zone key is one that > you'd want to keep to just an administrator or two. You wouldn't > want everyone to have the private part of the wildcard key, or > they could step on each other's updates using it for authentication, > right? So, this would imply that adding new names is something > that a sys-admin would do and is not something that individual > users would do on their own. Is that the intention? The real zone administrator/owner can just edit the master file and re-sign the zone. If you want them to use dynamic update instead, then you can have a zone-wide wildcard KEY they use to sign updates. But the principle orientation of dynamic update is towards having a number of agents capable of updating the zone in various limited ways. The limit could be name scope, where the wildcards use names inferior to the zone name, or the limit could be by using the "weak" or "unique name" limits on keys that can be optionally implemented by secure dynamic DNS servers and, if implemented, can eliminate the problem of "stepping on each other". > Edie Donald ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html Received: from relay.tis.com by neptune.TIS.COM id aa17877; 21 Jun 96 17:09 EDT Received: by relay.tis.com; id RAA19581; Fri, 21 Jun 1996 17:11:23 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma019579; Fri, 21 Jun 96 17:10:59 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA29054; Fri, 21 Jun 96 17:10:58 EDT Received: by relay.tis.com; id RAA19574; Fri, 21 Jun 1996 17:10:53 -0400 Received: from treetops.commerce.net(204.162.67.5) by relay.tis.com via smap (V3.1.1) id xma019570; Fri, 21 Jun 96 17:10:49 -0400 Received: from [153.37.6.41] (pool017.Max6.Washington.DC.DYNIP.ALTER.NET [153.37.6.17]) by treetops.commerce.net (8.7.4/8.6.4) with ESMTP id OAA11951 for ; Fri, 21 Jun 1996 14:10:55 -0700 (PDT) X-Sender: galvin@pop.commerce.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Jun 1996 17:14:49 -0400 To: dns-security@TIS.COM From: "James M. Galvin" Subject: DRAFT agenda for DNS Security WG Sender: dns-security-approval@neptune.tis.com Precedence: bulk Just in case you haven't noticed, we are having a meeting on wednesday, June 26, 9am-11:30am. The agenda for the meeting is: agenda bashing and introductions status of documents DNS Security Extensions - draft-dnssec-secext-09.txt Mapping AS Number into the DNS - draft-dnssec-as-map-03.txt Secure DNS Dynamic Update - draft-dnssec-update-00.txt status of implementations TIS DNS security TIS dynamic update others?? issues next steps are we ready to advance secure dynamic update? See you there, Jim ---------------------------------------------------------------------------- James M. Galvin galvin@commerce.net CommerceNet, PO Box 220, Glenwood, MD 21738 +1 410.795.6882 http://www.commerce.net/ http://www.eff.org/blueribbon Received: from relay.tis.com by neptune.TIS.COM id aa22344; 24 Jun 96 10:39 EDT Received: by relay.tis.com; id JAA15232; Mon, 24 Jun 1996 09:36:53 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma015217; Mon, 24 Jun 96 09:36:25 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA18121; Mon, 24 Jun 96 09:36:28 EDT Received: by relay.tis.com; id JAA15211; Mon, 24 Jun 1996 09:36:23 -0400 Received: from hpheger4.nm.informatik.uni-muenchen.de(129.187.214.24) by relay.tis.com via smap (V3.1.1) id xma015150; Mon, 24 Jun 96 09:33:53 -0400 Received: (from unterrei@localhost) by hpheger4.nm.informatik.uni-muenchen.de (8.7.5/8.6.10) id PAA02537 for dns-security@tis.com; Mon, 24 Jun 1996 15:36:30 +0200 (MESZ) From: Gertraud Unterreitmeier Message-Id: <199606241336.PAA02537@hpheger4.nm.informatik.uni-muenchen.de> Subject: Implementations ? To: dns-security@TIS.COM Date: Mon, 24 Jun 1996 15:36:29 +0200 (MESZ) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: dns-security-approval@neptune.tis.com Precedence: bulk Hello, does there exist implementations of the 'dnssec' which are available outside of USA/Canada? Gertraud Unterreitmeier Received: from relay.tis.com by neptune.TIS.COM id aa05300; 26 Jun 96 13:41 EDT Received: by relay.tis.com; id NAA15910; Wed, 26 Jun 1996 13:43:44 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma015895; Wed, 26 Jun 96 13:43:16 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA03647; Wed, 26 Jun 96 13:43:18 EDT Received: by relay.tis.com; id NAA15890; Wed, 26 Jun 1996 13:43:13 -0400 Received: from treetops.commerce.net(204.162.67.5) by relay.tis.com via smap (V3.1.1) id xma015886; Wed, 26 Jun 96 13:43:10 -0400 Received: from [206.167.192.166] (ietf192-166.ietf.risq.qc.ca [206.167.192.166]) by treetops.commerce.net (8.7.4/8.6.4) with ESMTP id KAA05624 for ; Wed, 26 Jun 1996 10:43:09 -0700 (PDT) X-Sender: galvin@pop.commerce.net Message-Id: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="============_-1376311195==_============" Date: Wed, 26 Jun 1996 13:48:17 -0400 To: dns-security@TIS.COM From: "James M. Galvin" Subject: draft Minutes of DNS Security Working Group Sender: dns-security-approval@neptune.tis.com Precedence: bulk --============_-1376311195==_============ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Enclosed below is the first version of the DNS Security Working Group Minutes. Comments, questions, and corrections are due by monday, July 1, at which time they will be submitted for inclusion in the proceedings. Enjoy, Jim --============_-1376311195==_============ Content-Type: text/plain; name="dnssec-minutes.txt"; charset="us-ascii" Content-Disposition: attachment; filename="dnssec-minutes.txt" The DNS Security Working Group met for one working group session. First item on the agenda was the status of the three documents before us. draft-dnssec-as-map-03.txt - It was decided to remove this document from consideration by the working group. At a minimum, it sets up a requirement for yet another centralized authority to come into existence to manage the name space, which would seem to be problematic in today's Internet. In any case, there is a very small minority of people interested in this document at this time. The area director has indicated that if there is a group who would like to pursue this work he will consider a proposal for a new working group. draft-dnssec-secext-09.txt - The document has been through working group and IETF last call, and has been reviewed by the IESG. It has been revised according to comments received and a new version has been submitted to the IESG for final review. We expect the document to be approved and submitted to the RFC Editor for publication as a Proposed Standard. draft-dnssec-update-00.txt - Per our agreement last March, this document is waiting for implementation experience before we submit it to the IESG. Trusted Information Systems expects to complete an alpha reference implementation prior to the December meeting. If not, we previously agreed to submit the document to the IESG anyway, since any further delay would be counter-productive. TIS spoke briefly on the status of its implementation. They indicated there would be a new release soon (during July). Also, they have applied for an export license that would permit the global distribution of the software, with cryptographic calls but without the cryptographic software, i.e., it would include calls to RSAREF but it would not include RSAREF. John Gilmore and IBM each indicated they have partial implementations. It was pointed out that Microsoft has an implementation underway but no one was present from Microsoft to either confirm or deny the activity. There are no implementations of secure dynamic update at this time. Three remaining issues were brought to the floor and discussed. The results of the discussion are as follows. First, the DNS security document does not currently include any worked examples of how to validate public keys. It was agreed that several examples of validation, including both to the root and to other trusted points, be added to the document when it progresses from Proposed to Draft. Second, the question was raised as to what the validation policy should be for the global DNS. It was agreed that now that we have Secure DNS we need to better understand the validation process and its implications. The Chair took an action item to form a sub-group to prepare a draft validation policy for the working group to review. This document will become an adjunct to the secure DNS specification and ultimately submitted for consideration as a proposed standard. Third, it was pointed out that the TIS reference implementation does the security enhancements in the server, not in the client. TIS took as an action item to enhance its implementation to include security support for the client. This working group will meet at the Winter 1996 IETF. At that time we will review any secure dynamic update implementation experience and consider whether to advance the secure dynamic update specification. In addition, the validation policy sub-group will present a draft document for review by the working group. --============_-1376311195==_============ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ---------------------------------------------------------------------------- James M. Galvin galvin@commerce.net CommerceNet, PO Box 220, Glenwood, MD 21738 +1 410.795.6882 http://www.commerce.net/ http://www.eff.org/blueribbon --============_-1376311195==_============-- Received: from relay.tis.com by neptune.TIS.COM id aa15555; 2 Jul 96 12:56 EDT Received: by relay.tis.com; id MAA05355; Tue, 2 Jul 1996 12:58:01 -0400 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma005324; Tue, 2 Jul 96 12:57:36 -0400 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA01949; Tue, 2 Jul 96 12:57:32 EDT Received: by relay.tis.com; id MAA05308; Tue, 2 Jul 1996 12:57:31 -0400 Received: from callandor.cybercash.com(204.178.186.70) by relay.tis.com via smap (V3.1.1) id xma005305; Tue, 2 Jul 96 12:57:27 -0400 Received: by callandor.cybercash.com; id MAA12938; Tue, 2 Jul 1996 12:53:52 -0400 Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (V3.1) id xma005019; Tue, 2 Jul 96 07:58:08 -0400 Received: by cybercash.com (4.1/SMI-4.1) id AA25789; Tue, 2 Jul 96 08:01:56 EDT Date: Tue, 2 Jul 1996 08:01:56 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: Gertraud Unterreitmeier MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM Cc: dns-security@TIS.COM Subject: Re: Implementations ? In-Reply-To: <199606241336.PAA02537@hpheger4.nm.informatik.uni-muenchen.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dns-security-approval@neptune.tis.com Precedence: bulk Gertraud, I don't think anyone else has replied to you yet so I guess I will. As far as I know, the current inplementations are inside the US but they all expect to be exportable. TIS is currently negotiating with the US Government about export approval. Donald On Mon, 24 Jun 1996, Gertraud Unterreitmeier wrote: > Date: Mon, 24 Jun 1996 15:36:29 +0200 (MESZ) > From: Gertraud Unterreitmeier > To: dns-security@TIS.COM > Subject: Implementations ? > > Hello, > > does there exist implementations of > the 'dnssec' which are available > outside of USA/Canada? > > Gertraud Unterreitmeier > > ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html Received: from relay.hq.tis.com by neptune.TIS.COM id aa19834; 25 Jul 96 13:09 EDT Received: by relay.hq.tis.com; id MAA13067; Thu, 25 Jul 1996 12:34:16 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma013046; Thu, 25 Jul 96 12:33:48 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA10043; Thu, 25 Jul 96 12:33:25 EDT Received: by relay.hq.tis.com; id MAA13034; Thu, 25 Jul 1996 12:33:46 -0400 Received: from capone.ch.apollo.hp.com(15.254.24.3) by relay.tis.com via smap (V3.1.1) id xma013006; Thu, 25 Jul 96 12:33:20 -0400 Received: from thunk.orchard.medford.ma.us (thunk.ch.apollo.hp.com) by capone.ch.apollo.hp.com id ; Thu, 25 Jul 1996 12:35:36 -0400 Received: from thunk (sommerfeld@localhost) by thunk.orchard.medford.ma.us (8.6.12/8.6.12) with ESMTP id MAA03743 for ; Thu, 25 Jul 1996 12:35:35 -0400 Message-Id: <199607251635.MAA03743@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs To: dns-security@TIS.COM Subject: what happened to the validation sub-group? Date: Thu, 25 Jul 1996 12:35:33 -0400 From: Bill Sommerfeld Sender: dns-security-approval@neptune.tis.com Precedence: bulk What happened to the validation sub-group? Has it not started yet? The draft minutes said.. Second, the question was raised as to what the validation policy should be for the global DNS. It was agreed that now that we have Secure DNS we need to better understand the validation process and its implications. The Chair took an action item to form a sub-group to prepare a draft validation policy for the working group to review. This document will become an adjunct to the secure DNS specification and ultimately submitted for consideration as a proposed standard. At the last IETF meeting, there was a call for volunteers for this sub-group; I volunteered, someone took my name, and I haven't heard anything since... I have some experience in dealing with these issues in other systems. I have an idea for what some possible policies may be, and some thoughts on how to encode that into the DNS, and I'd like to contribute.. - Bill Received: from relay.hq.tis.com by neptune.TIS.COM id aa27358; 29 Jul 96 9:36 EDT Received: by relay.hq.tis.com; id JAA15186; Mon, 29 Jul 1996 09:39:19 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma015175; Mon, 29 Jul 96 09:38:53 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA18086; Mon, 29 Jul 96 09:38:25 EDT Received: by relay.hq.tis.com; id JAA15168; Mon, 29 Jul 1996 09:38:49 -0400 Received: from henson.rutgers.edu(128.6.75.66) by relay.tis.com via smap (V3.1.1) id xma015165; Mon, 29 Jul 96 09:38:44 -0400 Received: (from wli@localhost) by henson.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id JAA22671; Mon, 29 Jul 1996 09:40:53 -0400 Date: Mon, 29 Jul 1996 09:40:53 -0400 From: Wanglai Li Message-Id: <199607291340.JAA22671@henson.rutgers.edu> To: dns-security@TIS.COM, ietf-pkix@tandem.com, ietf-tls@w3.org, ipsec@TIS.COM, set-discuss@commerce.net Subject: DIMACS Workshop on Trust Management in Networks Cc: jf@research.att.com, wli@dimacs.rutgers.edu Sender: dns-security-approval@neptune.tis.com Precedence: bulk -------------------------------------------------------------------------- | DIMACS: Center for Discrete Mathematics & Theoretical Computer Science | | A National Science Foundation Science and Technology Center | -------------------------------------------------------------------------- DIMACS Workshop on Trust Management in Networks Dates: Sept. 30 - Oct. 2, 1996 Location: CORE Bldg., Rutgers University Busch Campus, Piscataway NJ Co-Chairs: Ernie Brickell, Bankers Trust, brickell@btec.com Joan Feigenbaum, AT&T Research, jf@research.att.com Dave Maher, AT&T Research, dpm@research.att.com Theme: The use of public-key cryptography on a mass-market scale requires sophisticated mechanisms for managing trust. For example, any application that receives a signed request for action is forced to answer the central question ``Is the key used to sign this request authorized to take this action?'' In certain applications, this question reduces to ``Does this key belong to this person?'' In others, the authorization question is considerably more complicated, and resolving it requires techniques for formulating security policies and security credentials, determining whether particular sets of credentials satisfy the relevant policies, and deferring trust to third parties. This workshop covers all aspects of the trust management problem. Relevant topics include but are not limited to: General approaches to trust management Languages, systems, and tools Certificates and public-key infrastructure Formal models and analysis Trust management in specific application domains, including but not limited to: Banking E-mail Internet commerce Licensing Medical information systems Mobile programs and ``code signing'' Revocation of cryptographic keys Confirmed speakers include: Butler Lampson, Microsoft Matt Blaze, AT&T Research Steve Kent, BBN Carl Ellison, Cybercash Contributed talks: If you would like to attend and give a talk, please email a one-page abstract (NOT A FULL PAPER) in ascii format to Joan Feigenbaum at jf@research.att.com by September 1, 1996. The Trust Management workshop will be informal, and there are currently no plans to publish proceedings. For more information: If you would like to attend but not give a talk, contact Joan Feigenbaum at jf@research.att.com any time before the beginning of the workshop. There is a small amount of support available for people who do not have other sources of travel funds. Information about local arrangements, travel, lodging and registration can be found at http://dimacs.rutgers.edu/Workshops/Management. Those without WWW access can contact Pat Pravato at 908-445-5929 or pravato@dimacs.rutgers.edu. This workshop is part of DIMACS Special Year on Networks. Information about the Special Year on Networks can be found at DIMACS WWW site: http://dimacs.rutgers.edu or by contacting the center. --------------------------------------------------------------------- The Special Year program is made possible by long term funding from the National Science Foundation, the New Jersey Commission on Science and Technology and DIMACS university and industry partners. DIMACS Center; Rutgers University; P.O. Box 1179; Piscataway, NJ 08855-1179 TEL: 908-445-5928 FAX: 908-445-5932 ** EMAIL: center@dimacs.rutgers.edu WWW: http://dimacs.rutgers.edu **TELNET: telnet info.rutgers.edu 90 DIMACS is a partnership of Rutgers University, Princeton University, AT&T Research, Bellcore, and Lucent - Bell Laboratories. Received: from relay.hq.tis.com by neptune.TIS.COM id aa03830; 31 Jul 96 1:21 EDT Received: by relay.hq.tis.com; id BAA04427; Wed, 31 Jul 1996 01:23:41 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma004421; Wed, 31 Jul 96 01:23:13 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA11937; Wed, 31 Jul 96 01:22:45 EDT Received: by relay.hq.tis.com; id BAA04417; Wed, 31 Jul 1996 01:23:11 -0400 Received: from ctrvx1.vanderbilt.edu(129.59.1.21) by relay.tis.com via smap (V3.1.1) id xma004415; Wed, 31 Jul 96 01:22:46 -0400 Received: from ctrvax.Vanderbilt.Edu by ctrvax.Vanderbilt.Edu (PMDF V5.0-5 #11488) id <01I7PBNUBVI88XFSXJ@ctrvax.Vanderbilt.Edu> for list1@ctrvax.Vanderbilt.Edu; Wed, 31 Jul 1996 00:23:17 -0500 (CDT) Date: Wed, 31 Jul 1996 00:23:16 -0500 (CDT) From: BEZALEL GAVISH Subject: CFP - 5th International conference on telecommunication Systems To: list1: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Message-Id: <01I7PBNUC55E8XFSXJ@ctrvax.Vanderbilt.Edu> X-Vms-To: IN%"list1" X-Vms-Cc: GAVISHB Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: dns-security-approval@neptune.tis.com Precedence: bulk TSM97CFP C A L L for P A P E R S 5th International Conference on Telecommunication Systems Modelling and Analysis March 20-23, 1997 Nashville, TN Sponsored by: American Telecommunications Systems Management Association BellSouth Telecommunications, Inc. IFIP Working Group 7.3 "Computer system modelling and performance evaluation" INFORMS Technical Section on Telecommunications INFORMS College of Information Systems Owen Graduate School of Management The 5th International Conference on Telecommunication Systems - Modelling and Analysis will be held in Nashville on March 20-23, 1997. The conference will build on the tradition of the earlier conferences with a few changes in format due to the new conference location. The general idea is to limit the number of participants, concentrate on a few topics, present new problems and problem areas, encouraging informal interaction and exchanges of ideas. The objective is to advance the state of the modelling and analysis in telecommunications by stimulating research activity on new and important problems. The conference will be divided into segments with each segment devoted to a specific topic. This will allow for little conflict between segments. All papers will be screened by the Program Committee to ensure the quality of presentations. A decentralized paper handling process will be used. The Program Committee has been divided along geographical regions with a separate Program Subcommittee assigned to each region. Abstracts and papers should be submitted directly to the Program Committee Chair of the appropriate area. It is expected that this will expedite the paper review process. In response to suggestions made by last year's participants, social and cultural activities will be included in the 1997 agenda. The conference will be held at two sites, Thursday and Friday meetings will take place at the Tenessee Economic Development Center at the BellSouth Tower in downtown Nashville. The Saturday and Sunday meeting will be held at the Union Station hotel (see description at the end of the message). Lead Speakers and Keynote speakers include: Erol Gelenbe, Andrew Viterbi, Paul Kuehn. The Chairmen of the geographic Program Committees are: ---Australia, New Zealand and South East Asia: Prof. Richard Harris Department of Communication and Electronic Engineering Royal Melbourne Institute of Technology 723 Swanston Street Carlton, Victoria Australia, 3001 Phone : 61 3 9282 2450 (CATT), 61 3 9660 2457 (RMIT) Fax : 61 3 9282 2490 (CATT), 61 3 9660 1060 (RMIT) E-Mail : richard@catt.rmit.edu.au ---Europe: (except Scandinavia and Baltic states) Prof. Guy Pujolle Laboratoire PRiSM Universite de Versailles - Saint Quentin 45 avenue des Etats-Unis 78 035 Versailles Cedex FRANCE Phone : +33 (1) 39 25 40 61 Fax : +33 (1) 39 25 40 57 E-Mail : guy.pujolle@prism.uvsq.fr ---Europe: (Scandinavia and Baltic states) Dr. Johan M. Karlsson Department of Communication Systems Lund Institute of Technology P.O. Box 118 S-221 00 Lund Sweden E-Mail : johan@tts.lth.se ---North America: Prof. June S. Park Department of Management Sciences The University of Iowa 108 Pappajohn Business Administration Bldg. Iowa City, IA 52242-1000 USA Phone : 319-335-2087 Fax : 319-335-1956 E-Mail : jpark@scout-po.biz.uiowa.edu ---North East Asia: Prof. Yutaka Takahashi Nara Institute of Science and Technology Takayama-cho 8916-5, Ikoma-shi, Nara, 630-01 JAPAN Phone : 81 74 372 5350 Fax : 81 74 372 5359 E-Mail : ytanaka@mn.waseda.ac.jp ---South and Central America: Dr. Ernesto Santibanez-Gonzalez Escuela de Ingenieria Industrial Universidad Catolica, Valparaiso Av. Brasil 2147 Valparaiso Chile Phone : 56 32 257331 Fax : 56 2 214823 E-Mail : esantiba@aix1.ucv.cl ---Chairman of the Economics track: Prof. William W. Sharkey Federal Communications Commission 1919 M Street Washington, DC 20554 USA Phone : 202-418-2743 Fax : 202-418-1413 E-Mail : wsharkey@fcc.gov ---All other geographic areas: Prof. Bezalel Gavish Owen Graduate School of Management Vanderbilt University Tel: 615-322-3659 401 21st Avenue South FAX: 615-343-7177 Nashville, TN 37203 Email: gavishb@ctrvax.vanderbilt.edu Listed below are some of the potential segments: -- Configuration of ATM networks -- Internet and its Impact on Commerce -- Internet and Intranet -- Standards -- Topological Design and Network Configuration Problems -- Design and Analysis of Local Access Networks and Outside Plant Problems -- Low Earth Orbit Satellite Communication Systems -- Cellular Systems and PCS Modelling and Configuration -- Time Dependent Expansion of Telecommunication Systems -- Designing Networks for Reliability and Availability -- Network Design Problems in Gigabit and Terabit Networks -- LAN, WAN Global Network Interconnection -- ATM, ISDN, BISDN Modeling and Analysis Issues -- Artificial Intelligence/Heuristics in Telecommunication Systems -- Group Decision Support Systems -- Quantitative Methods in Network Management -- Pricing and Economic Analysis of Telecommunications -- Impact of Telecommunications on Industrial Organization -- Performance Evaluation of Telecommunication Systems -- Distributed Computing and Distributed Data Bases -- Security and Privacy Issues in Telecommunications -- Virtual Reality, Multimedia and their Impact The Program Committee is open to any ideas you might have regarding additional topics or format of the conference. The intention is whenever possible, to limit the number of parallel sessions to two. The conference is scheduled over a weekend so as to reduce teaching conflicts for academic participants, enabling participants to take advantage of weekend hotel and airfare rates and of the many events that take place in the downtown area. Due to the limit on the number of participants early conference and hotel registration is recommended. The Union Station Hotel is the official hotel of the conference. To ensure your participation, please use the following steps: 1. Send to the appropriate Program Committee Chair by October 1, 1996, a paper (preferable), or titles and extended abstracts for potential presentations to be considered for the conference. Sending more than one extended abstract is encouraged, enabling the Program Committee to have a wider choice in terms of assigning talks to segments. Use E-mail to expedite the submission of titles and abstracts. 2. Use the forms at the end of this message to preregister for the conference and the hotal. Let us also know if you would like to have a formal duty during the conference as: Session Chair, or Discussant. 3. You will be notified by December 1, 1996, which abstract/s have been selected for the conference. Detailed instructions on how to prepare camera ready copies will be sent to authors of accepted presentations. January 30, 1997, is the deadline for sending a final version of the paper. Participants will receive copies of the collection of papers to be presented. All papers submitted to the conference will be considered for publication in the "Telecommunication Systems" Journal. The Program Committee looks forward to receiving your feedback/ideas. Feel free to volunteer any help you can offer. If you have suggestions for Segment Leaders (i.e., individuals who will have a longer time to give an overview/state of the art talk on their segment subject) please E-mail them to Prof Gavish. Also, if there are individuals whose participation you view as important, please send their names and E-mail addresses to the Program Committee Chairman, or forward to them a copy of this message. I look forward to a very successful conference. Sincerely yours, Bezalel Gavish ------------------------------------------------------------------------------- Cut Here ------------------------------------------------------------------------------- Fifth International Conference on Telecommunication Systems Modelling and Analysis REGISTRATION FORM Date: __________________ Dates: March 20, 1997 (afternoon) to March 23, 1997 Name: ________________________________________ Title: __________________ Affiliation: __________________________________________________________________ Address: __________________________________________________________________ __________________________________________________________________ Phone: ____________________________ FAX: _______________________________ E-mail: __________________________________________________________________ Potential Title of Paper(s): __________________________________________________ ____________________________________________________________________ I would like to Volunteer as Comments A Session Chair : Yes No ________________________________________________ A Discussant : Yes No ________________________________________________ Organize a Session: Yes No ________________________________________________ ________________________________________________ REGISTRATION RATES and DEADLINES Last Applica- Academic Industry Corporate ble Date Rate Rate Rate --------------- -------- -------- -------- 1. Preregistration Until Dec. 9, 1996 $ 400 $ 500 $1,300 2. Registration Until Jan. 15, 1997 $ 500 $ 600 $1,300 3. On Site Registration After Jan. 15, 1997 $ 600 $ 750 $1,500 As part of the conference registration dues you can become a member of the "American Telecommunication Systems Management Association" . Please mark an X in the following entry if you wish to become an ATSMA member. ____ Yes, I wish to become an ATSMA member. ____ No, I don't wish to become an ATSMA member. Mail your registration form and check to: Mrs. Dru Lundeng Owen Graduate School of Management Vanderbilt University 401 21st Avenue, South Nashville, TN 37203, USA The check should be endorsed to: ATSMA, Inc. Refund Policy: Half refund, for requests received by February 1, 1997. No refund after February 1, 1997. ----------------------------------------------------------------------------- If you have any questions regarding the conference, please contact Dru Lundeng at 615-322-3694 or through E-mail at lundeng@ctrvax.vanderbilt.edu. Hotel Reservation A block of rooms has been reserved at Union Station Hotel for the Conference participants. Please make your hotel arrangements early, to insure getting a room at the special conference rate. You will need to mention that you are a participant of the Telecommunication Systems Conference to receive the best price. Our advice is to make your reservations as soon as possible. Hotel rooms will be released from the Telecommunication Systems Conference blocks on February 15, 1997, so please be sure and reserve your rooms before February 15th. Union Station Hotel 1001 Broadway Nashville, TN 37203 Phone: 615-726-1001 or 1-800-331-2123 Fax: 615-742-3084 $99.00 Single or Double Occupancy Room $109.00 Triple or Quad Occupancy Room - Rates are subject to state and local tax, which is now 12.25 percent. ------------------------------------------------------------------------- Union Station Hotel Reservation Request Form Name of Conference: Telecommunication Systems Conference Arrival Date _________________ Departure Date __________________ Guest Name:__________________________________________________ Address :__________________________________________________ :__________________________________________________ Phone No. :__________________________________________________ A one night deposit should be enclosed to guarantee the reservation Payment Method: Check Check No.______________ Amount____________ Credit Card Type______________ No.____________________ Expiration Date____________ Type of Room: King or 2 Double Beds Smoking or Nonsmoking -------------------------------------------------------------------------- Union Station Hotel Description A Grand Heritage Hotel Features and Amenities In the heart of "Music City" stands a hotel with the personality of an intimate friend...Union Station Hotel. The heartbeat of Nashville has always been strongest at the Union Station. >From the grand opening in 1890 until the decline of rail travel in the 50s no other building in the city has been the site of more commercial activity and human drama. Nearly a century later, the Union Station Hotel, a National Historic Landmark, is again an integral part of life in Music City 124 guest rooms including 13 suites on seven levels are architecturally distinctive and capture the historic elegance of a bygone era. Stained glass, glittering gold leaf and newly silvered mirrors scatter reflections of an era which has endured for nearly a century. 4 conference rooms with over 10,000 square feet of flexible meeting and banquet space to accommodate groups of 5 to 200. * Arthur's Restaurant - gourmet dining, the recipient of the Mobil Travel Guide's Four Stars, Wine Spectator's Award of Excellence, and the Travel Holiday Award. * Broadway Bistro - casual dining open for lunch and dinner. Selected in the 1996 Zagat Survey as the city's best overall and best dining hotel. Heritage Executive Level with enhanced amenities ideal for the business and leisure traveler including concierge service, continental breakfast and evening cocktails Monday through Friday. * Valet parking. * Complimentary limo service in downtown Nashville. * Complimentary newspaper. * Blocks from downtown area, famed Music Row, Vanderbilt University and Convention Center. Recommended Airport: Nashville Metro Airport, 7 miles to the East. Transportation: Grayline Shuttle to the hotel. $8.00 one way, $14.00 round trip. Complimentary shuttle service within three mile radius of hotel for conference guests. ------------------------------------------------------------------------------- Bezalel Gavish Owen Graduate School of Management Vanderbilt University Nashville, TN, 37203 Bitnet: GAVISHB@VUCTRVAX Internet: GAVISHB@CTRVAX.VANDERBILT.EDU Tel: (615) 322-3659 Home: (615) 370-0813 FAX: (615) 343-7177 ------------------------------------------------------------------------------- Received: from relay.hq.tis.com by neptune.TIS.COM id aa09083; 5 Aug 96 11:45 EDT Received: by relay.hq.tis.com; id LAA23222; Mon, 5 Aug 1996 11:48:29 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma023198; Mon, 5 Aug 96 11:48:07 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA20377; Mon, 5 Aug 96 11:47:37 EDT Received: by relay.hq.tis.com; id LAA23181; Mon, 5 Aug 1996 11:48:00 -0400 Received: from ietf.org(132.151.1.19) by relay.tis.com via smap (V3.1.1) id xma023152; Mon, 5 Aug 96 11:47:30 -0400 Received: from localhost by ietf.org id aa01650; 5 Aug 96 11:12 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Cc: dns-security@TIS.COM From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnssec-secext-10.txt Date: Mon, 05 Aug 1996 11:12:38 -0400 Message-Id: <9608051112.aa01650@ietf.org> Sender: dns-security-approval@neptune.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Security Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : Domain Name System Security Extensions Author(s) : D. Eastlake, C. Kaufman Filename : draft-ietf-dnssec-secext-10.txt Pages : 45 Date : 08/02/1996 The Domain Name System (DNS) has become a critical operational part of the Internet infrastructure yet it has no strong security mechanisms to assure data integrity or authentication. Extensions to the DNS are described that provide these services to security aware resolvers or applications through the use of cryptographic digital signatures. These digital signatures are included in secured zones as resource records. Security can still be provided even through non-security aware DNS servers in many cases. The extensions also provide for the storage of authenticated public keys in the DNS. This storage of keys can support general public key distribution service as well as DNS security. The stored keys enable security aware resolvers to learn the authenticating key of zones in addition to those for which they are initially configured. Keys associated with DNS names can be retrieved to support other protocols. Provision is made for a variety of key types and algorithms. In addition, the security extensions provide for the optional authentication of DNS protocol transactions. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnssec-secext-10.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-secext-10.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dnssec-secext-10.txt". NOTE: The mail server at ds.internic.net 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. For questions, please mail to Internet-Drafts@ietf.org 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@ds.internic.net" Content-Type: text/plain Content-ID: <19960805101146.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-secext-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-secext-10.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960805101146.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from relay.hq.tis.com by neptune.TIS.COM id aa09944; 5 Aug 96 12:21 EDT Received: by relay.hq.tis.com; id MAA24134; Mon, 5 Aug 1996 12:24:00 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma024127; Mon, 5 Aug 96 12:23:32 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA21949; Mon, 5 Aug 96 12:23:02 EDT Received: by relay.hq.tis.com; id MAA24117; Mon, 5 Aug 1996 12:23:30 -0400 Received: from ietf.org(132.151.1.19) by relay.tis.com via smap (V3.1.1) id xmaa24110; Mon, 5 Aug 96 12:23:15 -0400 Received: from localhost by ietf.org id aa03738; 5 Aug 96 11:49 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Cc: dns-security@TIS.COM From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnssec-secext-10.txt Date: Mon, 05 Aug 1996 11:49:33 -0400 Message-Id: <9608051149.aa03738@ietf.org> Sender: dns-security-approval@neptune.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Security Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : Domain Name System Security Extensions Author(s) : D. Eastlake, C. Kaufman Filename : draft-ietf-dnssec-secext-10.txt Pages : 45 Date : 08/02/1996 The Domain Name System (DNS) has become a critical operational part of the Internet infrastructure yet it has no strong security mechanisms to assure data integrity or authentication. Extensions to the DNS are described that provide these services to security aware resolvers or applications through the use of cryptographic digital signatures. These digital signatures are included in secured zones as resource records. Security can still be provided even through non-security aware DNS servers in many cases. The extensions also provide for the storage of authenticated public keys in the DNS. This storage of keys can support general public key distribution service as well as DNS security. The stored keys enable security aware resolvers to learn the authenticating key of zones in addition to those for which they are initially configured. Keys associated with DNS names can be retrieved to support other protocols. Provision is made for a variety of key types and algorithms. In addition, the security extensions provide for the optional authentication of DNS protocol transactions. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnssec-secext-10.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-secext-10.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dnssec-secext-10.txt". NOTE: The mail server at ds.internic.net 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. For questions, please mail to Internet-Drafts@ietf.org 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@ds.internic.net" Content-Type: text/plain Content-ID: <19960802160759.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-secext-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-secext-10.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960802160759.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from relay.hq.tis.com by neptune.TIS.COM id aa20634; 5 Aug 96 23:23 EDT Received: by relay.hq.tis.com; id XAA06807; Mon, 5 Aug 1996 23:25:47 -0400 Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma006805; Mon, 5 Aug 96 23:25:19 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA04354; Mon, 5 Aug 96 23:24:49 EDT Received: by relay.hq.tis.com; id XAA06800; Mon, 5 Aug 1996 23:25:17 -0400 Received: from megamegs.decisive.com(206.171.43.137) by relay.tis.com via smap (V3.1.1) id xma006791; Mon, 5 Aug 96 23:24:48 -0400 Received: from jamie.decisive.com ([206.171.43.189]) by megamegs.decisive.com (post.office MTA v1.9.3 ID# 0-12889) with SMTP id AAA151 for ; Mon, 5 Aug 1996 19:43:15 -0700 Received: by jamie.decisive.com with Microsoft Mail id <01BB830C.A4A14820@jamie.decisive.com>; Mon, 5 Aug 1996 20:28:20 -0700 Message-Id: <01BB830C.A4A14820@jamie.decisive.com> From: Network Education Center To: "'dns-security@tis.com'" Subject: Survey on Continuing Education for Network Computing Professionals Date: Mon, 5 Aug 1996 18:29:06 -0700 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sender: dns-security-approval@neptune.tis.com Precedence: bulk This survey is on behalf of an education center dedicated to the needs = of network computing professionals. We are asking your input to help us = create better education/training programs for you and your company. Your = responses will be completely confidential. If we receive your completed survey by Monday, August 12, 1996, we'll = automatically enter you in a contest for a prize of $1,000; one winner = will be chosen from among those who complete the survey. Thank you in = advance for your help.=20 (Authentication marker -- ~3%e%INTCADX%8%1%454%5CTJVlfE%8021& -- do not = remove.)=20 To respond, create a reply e-mail message that contains the survey. = Some e-mail systems require you to manually copy and paste the survey = into your reply. Make sure the reply contains the *entire* = authentication marker, including what looks like garbage. To answer a question, type an x between the brackets, like this: [ x ]. = For fill-in-the-blanks, type between the brackets like this: [ your = response ]. Please make no other changes to this survey. 1. If for any reason you do NOT want to be contacted in the future via = e-mail, please indicate after the first question by placing an "x" = within the brackets. You will be omitted from future e-mail surveys. [ ] a) Please omit me from future e-mail surveys. 2. What is your company's PRIMARY industry or business? Choose one: [ ] a) Aerospace [ ] b) Communications carrier (telco, broadband, internet) [ ] c) Financial services [ ] d) Healthcare [ ] e) Manufacturing: computer/software [ ] f) Manufacturing: non-computer [ ] g) Government/military [ ] h) Publishing/media/advertising/public relations [ ] i) Transportation/utilities [ ] j) Wholesale/retail: non-computer [ ] k) Education [ ] l) Entertainment [ ] m) Computer reseller/retailer/VAR [ ] n) Systems integration/consulting [ ] o) Other, please specify... [ ] 3. What is your job function? Choose one: [ ] a) IS/MIS/Data processing [ ] b) LAN/network systems [ ] c) Internet/Web [ ] d) Intranet (in-TRA-net) [ ] e) Data communications/telecommunications [ ] f) PC/microcomputer/information center [ ] g) Systems analyst/applications development [ ] h) Systems engineer/integration [ ] i) Other computer-related, please specify... [ ] [ ] j) Executive/corporate office [ ] k) Financial/accounting [ ] l) Engineering/R&D [ ] m) Sales/marketing [ ] n) Other administrative, please specify... [ ] [ ] o) Consulting (computer related) [ ] p) Training/education [ ] q) Other professional, please specify... [ ] 4. Please check the statements below that describe your involvement = with networks. Choose all that apply: [ ] a) I manage networks. [ ] b) I design networks. [ ] c) I install networks. [ ] d) I troubleshoot/fix networks. [ ] e) I train or support network users. [ ] f) I initiate the evaluation of new network technologies. [ ] g) I evaluate or specify brands of network products. [ ] h) I ensure that networks meet specific business or = organizational objectives. 5. What is the scope of your involvement with networking in your = organization? Choose one: [ ] a) Entire organization or enterprise [ ] b) Entire work location [ ] c) Multiple departments at more than one location [ ] d) For a single department only [ ] e) Other 6. How many servers do you have installed in your organization? Choose one: [ ] a) Over 50 [ ] b) 10 to 49 [ ] c) 1 to 9 [ ] d) None 7. How many LANS do you have installed in your organization? Choose one: [ ] a) Over 25 [ ] b) 5 to 24 [ ] c) 1 to 4 [ ] d) None 8. How many microcomputers/workstations are connected to LANS in your = organization? Choose one: [ ] a) 500 or more [ ] b) 25 to 499 [ ] c) 1 to 24 [ ] d) None 9. How many employees do you supervise? Choose one: [ ] a) Up to 3 people [ ] b) 4 to 10 people [ ] c) More than 10 people [ ] d) None 10. Do you yourself have responsibility for networking = education/training provided to employees in your company? Choose one: [ ] a) Yes [ ] b) No [ ] c) Don't know 11. What is the annual budget for education/training for yourself and = those you supervise? Please enter the amount within the following brackets. [ ] 12. During the last 12 months, where did you or those you supervise = receive education/training for networking? Choose all that apply: [ ] a) In-house [ ] b) University/college [ ] c) Seminars [ ] d) Internet [ ] e) Other [ ] f) No education/training on networking was received NOW WE WANT YOUR OPINIONS ABOUT A POSSIBLE EDUCATION CURRICULUM ON = NETWORKING TECHNOLOGIES. For each of the following 10 course = descriptions, please indicate your level of interest. 13. A Network Technologies course covering circuits and fibers; = modulation and modems; LANs; WANs; frames; cell switching; wireless; = satellites; connection-oriented and connectionless service; = characteristics of each technology; addressing; media access; = comparisons. Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 14. A Network Interconnection and Internetworking course covering = interconnection technologies; repeaters, bridges, and routers; internet = addressing; address binding; datagram forwarding; techniques to = accomodate heterogeneity (e.g. encapsulation and fragmentation). Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 15. A Network Protocols and Protocol Design course covering protocol = layering; problems protocols solve; loss, reordering, corruption, = congestion, duplication, and replay; techniques such as framing, = checksumming, sliding window, and retransmission; focus on the transport = layer, but cover other layers. Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 16. A Routing and Routing Protocols course covering packet forwarding; = route propagation; vector-distance and link-state algorithms; spanning = tree. Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 17. A Distributed Programming and Applications course covering = client-server paradigm; socket API; middleware (e.g. RPC and CORBA); = building a server; multithread server execution; protection and = authorization; example applications. Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 18. A Network and Protocol Performance Evaluation course covering = throughput and delay; measuring and tuning protocols; instrumentation of = protocol stacks; traffic analysis; self-similar behavior. Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 19. A Networking and Protocol Support for Multimedia Applications = course covering high-speed networks; resource allocation and performance = guarantees; protocols for audio and video; techniques such as = compression and delayed playback. Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 20. An Advanced Server Design and Implementation course covering = implementation of concurrent, parallel servers; large-scale designs; = proxy servers (e.g., SLIRP); techniques such as buffering, replication, = caching, and application gateways. Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 21. An Advanced Routing course covering policy-based routing; = multicast; mobility; inter- and intra-layer encapsulation; longest = prefix forwarding table lookup algorithms; virtual LANS. Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 22. An Advanced Network Applications course covering EDI; electronic = commerce; advanced Web techniques (e.g. Java). Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 23. What would your level of interest be in taking a group of these = courses as a coordinated curriculum? Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting THINKING ABOUT THE CHARACTERISTICS AND BENEFITS OF DIFFERENT TYPES OF = EDUCATION PROGRAMS that could be made available for networking = technologies, please indicate which of the following would be important = to you. 24. A course curriculum leads to an advanced college degree. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 25. Each course generates a document of professional certification. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 26. Course curriculum leads to an overall certification. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 27. Course is available at your place of work. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 28. Course is available at a local university or college campus. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 29. Courses available at an industry event you already attend. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 30. Courses conducted by an advanced educational institute staffed by = networking experts. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 31. A core curriculum of a specified number of courses that would = follow a building educational sequence. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 32. A concentrated face-to-face education program conducted over = consecutive days. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 33. Ability to take class lessons, labs and tests over the Internet = from your desktop. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 34. What other thoughts do you have concerning what could be done to = improve educational or training programs on networking technologies? Please write within the brackets. [ ] 35. How many years have you been professionally involved in computing? Choose one: [ ] a) Less than 2 years [ ] b) 2 to 4 years [ ] c) 5 to 10 years [ ] d) More than 10 years 36. Which of the following ranges includes your age? Choose one: [ ] a) 18 to 34 [ ] b) 35 to 44 [ ] c) 45 to 54 [ ] d) 55 and older 37. Which of the following represents your highest level of education? Choose one: [ ] a) Attended high school [ ] b) Graduated high school [ ] c) Attended college [ ] d) Bachelor's degree [ ] e) Master's degree [ ] f) Doctorate degree 38. What do you estimate your total household income was last year? = (Please estimate total income for everyone in your household, including = salaries, wages, bonuses, interest, dividends, etc.) Choose one: [ ] a) Less than $15,000 [ ] b) $15,000 to $24,999 [ ] c) $25,000 to $34,999 [ ] d) $35,000 to $49,999 [ ] e) $50,000 to $74,999 [ ] f) $75,000 to $99,999 [ ] g) $100,000 to $149,999 [ ] h) $150,000 or more [ ] i) Don't know Thank you for participating in this survey. To: IETF-Announce: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at Message-ID: <9608281020.aa13972@neptune.TIS.COM> neptune.TIS.COM Cc: dns-security@TIS.COM From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnssec-ddi-01.txt Date: Wed, 28 Aug 1996 09:23:59 -0400 Message-Id: <9608280923.aa11736@ietf.org> Sender: dns-security-approval@neptune.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Security Working Group of the IETF. Title : Detached Domain Name System Information Author(s) : D. Eastlake Filename : draft-ietf-dnssec-ddi-01.txt Pages : 8 Date : 08/26/1996 A standard format is defined for representing detached DNS information. This is anticipated to be of use for storing information retrieved from the Domain Name System (DNS), including security information, in archival contexts or contexts not connected to the Internet. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnssec-ddi-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-ddi-01.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dnssec-ddi-01.txt". NOTE: The mail server at ds.internic.net 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. For questions, please mail to Internet-Drafts@ietf.org 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@ds.internic.net" Content-Type: text/plain Content-ID: <19960826105019.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-ddi-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-ddi-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960826105019.I-D@ietf.org> --OtherAccess-- --NextPart-- To: IETF-Announce: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at Message-ID: <9608281030.aa14178@neptune.TIS.COM> neptune.TIS.COM Cc: dns-security@TIS.COM From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnssec-update-01.txt Date: Wed, 28 Aug 1996 09:23:48 -0400 Message-Id: <9608280923.aa11683@ietf.org> Sender: dns-security-approval@neptune.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Security Working Group of the IETF. Title : Secure Domain Name System Dynamic Update Author(s) : D. Eastlake Filename : draft-ietf-dnssec-update-01.txt Pages : 15 Date : 08/26/1996 Domain Name System (DNS) protocol extensions have been defined to authenticate the data in DNS and provide key distribution services (draft-ietf-dnssec-secext-10.txt). DNS Dynamic Update operations have also been defined (draft-ietf-dnsind-dynDNS-*.txt>, but without a detailed description of strong security for the update operation. This draft describes how to use DNS digital signatures covering requests and data to secure updates and restrict them to those authorized to perform them as indicated by the updater's possession of cryptographic keys. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnssec-update-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-update-01.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dnssec-update-01.txt". NOTE: The mail server at ds.internic.net 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. For questions, please mail to Internet-Drafts@ietf.org 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@ds.internic.net" Content-Type: text/plain Content-ID: <19960826104145.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-update-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-update-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960826104145.I-D@ietf.org> --OtherAccess-- --NextPart-- To: IETF-Announce: ;, tis.com@TIS.COM Cc: dns-security@TIS.COM From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnssec-update-01.txt Date: Wed, 28 Aug 1996 09:23:48 -0400 Message-Id: <9608280923.aa11683@ietf.org> Sender: dns-security-approval@neptune.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Security Working Group of the IETF. Title : Secure Domain Name System Dynamic Update Author(s) : D. Eastlake Filename : draft-ietf-dnssec-update-01.txt Pages : 15 Date : 08/26/1996 Domain Name System (DNS) protocol extensions have been defined to authenticate the data in DNS and provide key distribution services (draft-ietf-dnssec-secext-10.txt). DNS Dynamic Update operations have also been defined (draft-ietf-dnsind-dynDNS-*.txt>, but without a detailed description of strong security for the update operation. This draft describes how to use DNS digital signatures covering requests and data to secure updates and restrict them to those authorized to perform them as indicated by the updater's possession of cryptographic keys. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnssec-update-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-update-01.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dnssec-update-01.txt". NOTE: The mail server at ds.internic.net 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. For questions, please mail to Internet-Drafts@ietf.org 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@ds.internic.net" Content-Type: text/plain Content-ID: <19960826104145.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-update-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-update-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960826104145.I-D@ietf.org> --OtherAccess-- --NextPart-- -- John C. Kelley System Administrator (301) 854-6889 Trusted Information Systems, Inc. (301) 854-5363 FAX 3060 Washington Road johnk@tis.com (work) Glenwood, MD 21738 johnk@radix.net (play) To: IETF-Announce: ;, tis.com@TIS.COM Cc: RFC Editor Cc: Internet Architecture Board Cc: dns-security@TIS.COM From: The IESG Subject: Protocol Action: Domain Name System Security Extensions to Proposed Standard Date: Wed, 28 Aug 1996 10:57:37 -0400 Message-Id: <9608281057.aa17308@ietf.org> Sender: dns-security-approval@neptune.tis.com Precedence: bulk The IESG has approved the Internet-Draft "Domain Name System Security Extensions" as a Proposed Standard. The IESG contact person is Jeffrey I. Schiller. Technical Summary This document describes security extensions to the Internet Domain Name System (DNS). These security extensions permit security aware resolvers to authenticate and verify the integrity of information stored in secured zones in the DNS. It makes use of public key cryptography and digital signatures to provide these services. In addition to providing integrity assured DNS lookups this proposal provides a mechanism to store and distribute public keys that may be used for other applications. Working Group Summary This document is the primary output of the DNS Security Working Group. At least one implementation of this proposal exists and the working group has come to consensus on this protocol. Protocol Quality This protocol has been reviewed by Jeffrey I. Schiller, Security Area Director. To: dns-security@TIS.COM, gnu@toad.com Subject: Announcement of DNS Security in production BIND tree Date: Thu, 29 Aug 1996 19:07:39 -0700 From: John Gilmore Sender: dns-security-approval@neptune.tis.com Precedence: bulk Message-ID: <9608300805.aa20509@neptune.TIS.COM> Paul Vixie has released a test version of BIND which contains some DNS Security features. The release is available now at ftp://ftp.vix.com/pub/bind/testing/bind-4.9.5-T3B.tar.gz. Only the existence of KEY and SIG records is implemented in this BIND. There is no cryptography implemented; the signatures are never checked. This permits keys and signatures to be stored and retrieved in a completely exportable version of BIND, which is part of the main production BIND evolution. The released code is partly based on IBM changes for Dynamic DNS, and is partly original with me. It was not based on TIS's version because of their export control concerns and restrictive copyrights (which have since been almost resolved). The State Department has approved TIS's request to export their cryptographic version of BIND. TIS is now waiting for final Commerce Dept. approval. When they receive it, I will work with them and Paul to merge their version into the production BIND sources, and to add further cryptographic code to the resolver, to provide production-quality, worldwide, end-to-end cryptovalidation of DNS resource records. In the meantime, TIS's release is useful for experimentation, and for generating offline KEY and SIG records (which can then be served to the world with the just-released production BIND server). I encourage all organizations who are interested in Secure DNS to upgrade their organization's production copy of BIND to Paul's latest release. This will facilitate Secure DNS testing and deployment. I have started a mailing list for people who are interested in deploying Secure DNS in production use. There is also for top-level domain service providers to work out their issues with Secure DNS. Send me email at postmaster@toad.com if you'd like to join either list. This is the first software release from my S/WAN (Secure Wide Area Network) project, whose ultimate goal is to provide transparent improvements to the privacy and security of all Internet communications. See http://www.cygnus.com/~gnu/swan.html. Thank you for supporting the ongoing securing of the Internet infrastructure. John Gilmore Received: from relay.hq.tis.com by neptune.TIS.COM id aa24782; 30 Aug 96 12:05 EDT Received: by relay.hq.tis.com; id MAA17055; Fri, 30 Aug 1996 12:08:36 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma017044; Fri, 30 Aug 96 12:08:06 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA20208; Fri, 30 Aug 96 12:07:24 EDT Received: by relay.hq.tis.com; id MAA17041; Fri, 30 Aug 1996 12:08:04 -0400 Received: from kerby.cybersafe.com(192.156.168.6) by relay.tis.com via smap (V3.1.1) id xma017035; Fri, 30 Aug 96 12:07:51 -0400 Received: from pinky.cybersafe.com (pinky.cybersafe.com [192.156.168.33]) by kerby.cybersafe.com (8.7.5/8.7.3/8.7.5, dpg hack 30jul96) with SMTP id JAA14179; Fri, 30 Aug 1996 09:10:11 -0700 (PDT) Received: by pinky.cybersafe.com (NX5.67f2/NX3.0S) id AA10185; Fri, 30 Aug 96 09:10:10 -0700 Message-Id: <9608301610.AA10185@pinky.cybersafe.com> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Dennis Glatting Date: Fri, 30 Aug 96 09:10:09 -0700 To: John Gilmore Subject: Re: Announcement of DNS Security in production BIND tree Cc: dns-security@TIS.COM Reply-To: dennis.glatting@cybersafe.com References: <9608300805.aa20509@neptune.TIS.COM> Sender: dns-security-approval@neptune.tis.com Precedence: bulk Is the release subject to the same DNS bug that has been causing havoc across the Internet? -dpg Message-Id: <199608301703.KAA20724@toad.com> To: dennis.glatting@cybersafe.com Cc: John Gilmore , dns-security@TIS.COM, gnu@toad.com Subject: Re: Announcement of DNS Security in production BIND tree In-Reply-To: <9608301610.AA10185@pinky.cybersafe.com> Date: Fri, 30 Aug 1996 10:03:10 -0700 From: John Gilmore Sender: dns-security-approval@neptune.tis.com Precedence: bulk > Is the release subject to the same DNS bug that has been > causing havoc across the Internet? All 4.9.5 releases include the fix. The problem was in 4.9.4-REL, fixed in 4.9.4-P1. The widespread problems occurred some time after the -P1 release was out, but before all the root servers had upgraded to -P1. John Received: from relay.hq.tis.com by neptune.TIS.COM id aa00506; 30 Aug 96 17:31 EDT Received: by relay.hq.tis.com; id RAA28258; Fri, 30 Aug 1996 17:34:40 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma028251; Fri, 30 Aug 96 17:34:16 -0400 Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA07538; Fri, 30 Aug 96 17:33:30 EDT Received: by relay.hq.tis.com; id RAA28242; Fri, 30 Aug 1996 17:34:10 -0400 Received: from marceau.fm.intel.com(132.233.247.8) by relay.tis.com via smap (V3.1.1) id xma028239; Fri, 30 Aug 96 17:33:46 -0400 Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.7.4/10.0i); Fri, 30 Aug 1996 21:36:05 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id OAA13713; Fri, 30 Aug 1996 14:35:43 -0700 (PDT) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Fri, 30 Aug 96 14:35:43 PDT Date: Fri, 30 Aug 96 14:16:00 PDT From: Viraj Bais Message-Id: To: dns-security-request@neptune.tis.com, dns-security@TIS.COM, gnu@toad.com Subject: Re: Announcement of DNS Security in production BIND tree Sender: dns-security-approval@neptune.tis.com Precedence: bulk Text item: I have not seen any Dynamic DNS changes from IBM or Intel in the bind-4.9.5-T3B version. Viraj Bais ______________________________ Reply Separator _________________________________ Subject: Announcement of DNS Security in production BIND tree Author: dns-security-request@neptune.hq.tis.com at SMTPGATE Date: 8/29/96 7:07 PM Paul Vixie has released a test version of BIND which contains some DNS Security features. The release is available now at ftp://ftp.vix.com/pub/bind/testing/bind-4.9.5-T3B.tar.gz. Only the existence of KEY and SIG records is implemented in this BIND. There is no cryptography implemented; the signatures are never checked. This permits keys and signatures to be stored and retrieved in a completely exportable version of BIND, which is part of the main production BIND evolution. The released code is partly based on IBM changes for Dynamic DNS, and is partly original with me. It was not based on TIS's version because of their export control concerns and restrictive copyrights (which have since been almost resolved). The State Department has approved TIS's request to export their cryptographic version of BIND. TIS is now waiting for final Commerce Dept. approval. When they receive it, I will work with them and Paul to merge their version into the production BIND sources, and to add further cryptographic code to the resolver, to provide production-quality, worldwide, end-to-end cryptovalidation of DNS resource records. In the meantime, TIS's release is useful for experimentation, and for generating offline KEY and SIG records (which can then be served to the world with the just-released production BIND server). I encourage all organizations who are interested in Secure DNS to upgrade their organization's production copy of BIND to Paul's latest release. This will facilitate Secure DNS testing and deployment. I have started a mailing list for people who are interested in deploying Secure DNS in production use. There is also for top-level domain service providers to work out their issues with Secure DNS. Send me email at postmaster@toad.com if you'd like to join either list. This is the first software release from my S/WAN (Secure Wide Area Network) project, whose ultimate goal is to provide transparent improvements to the privacy and security of all Internet communications. See http://www.cygnus.com/~gnu/swan.html. Thank you for supporting the ongoing securing of the Internet infrastructure. John Gilmore Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Message-ID: <9608300805.aa20509@neptune.TIS.COM> Precedence: bulk Sender: dns-security-approval@neptune.hq.tis.com From: John Gilmore Date: Thu, 29 Aug 1996 19:07:39 -0700 Subject: Announcement of DNS Security in production BIND tree To: dns-security@TIS.COM, gnu@toad.com Received: from neptune.tis.com by neptune.TIS.COM id aa20515; 30 Aug 96 8:09 EDT Received: by neptune.TIS.COM id aa20714; 30 Aug 96 8:24 EDT Received: from TIS.COM by marceau.fm.intel.com (8.7.4/10.0i); Fri, 30 Aug 1996 1 7:26:19 GMT Received: from marceau.fm.intel.com (marceau.fm.intel.com [132.233.247.8]) by fm mail.fm.intel.com (8.7.4/8.7.3) with ESMTP id KAA03099 for ; Fri, 30 Aug 1996 10:26:39 -0700 (PDT) Return-Path: dns-security-request@neptune.hq.tis.com From: Gertraud Unterreitmeier MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM Message-Id: <199609040924.LAA03630@hpheger4.nm.informatik.uni-muenchen.de> Subject: DOC files To: dns-security@TIS.COM Date: Wed, 4 Sep 1996 11:24:06 +0200 (MESZ) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: dns-security-approval@neptune.tis.com Precedence: bulk Hello, would it be possible to get only the files INSTALL_SEC and USAGE_SEC for installation and user instructions of your DNSSEC implementation also if I'm not a U.S. citizen. Gertraud Unterreitmeier. Message-Id: <9609132119.AA05773@tis.com> To: dns-security@TIS.COM Subject: Re: ANNOUNCE: TIS/DNSSEC Beta 1.3 is now available Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <26815.842649615.1@tis.com> Date: Fri, 13 Sep 1996 17:20:16 -0400 From: Olafur Gudmundsson Sender: dns-security-approval@neptune.tis.com Precedence: bulk We are please to announce that the second Beta release of TIS/DNSSEC Beta-1.3 is now available. This version is a implementation of the current DNSSEC draft and it is based on bind-4.9.4-p1, it uses RSAREF, but you need to retrieve a copy from RSA. This version is still export restricted. We are actively seeking beta testers. Feel free to test against our secure nameserver for zone sd-bogus.tis.com which is served from uranus.hq.tis.com. We are also making a DNSSEC enhanced version of DIG available, in executable form for popular platforms. This version of dig is extended to query sd-bogus and other secure servers. There are no export restrictions on the executables For information on how to acquire TIS/DNSSEC retrieve the file /pub/DNSSEC/README on the host ftp.tis.com via anonymous FTP, for further instruction on how the get the TIS/DNSSEC distribution. The new dig a sunos4.x executable versions are ftp:/ftp.tis.com/pub/DNSSEC/sdig.sunos4.gz Other versions will be made available as ftp:/ftp.tis.com/pub/DNSSEC/sdig..gz If you have any questions or problems please send a note to tisdnssec-support@tis.com. If you compile the new dig on a popular platform that we do not have an executable for please let us know. Enjoy, Olafur =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Olafur Gudmundsson ogud@tis.com (301)-854-5700(phone) (301)-854-5363 FAX You live only once, so enjoy it. Date: Sun, 15 Sep 1996 15:00:46 -0500 (CDT) From: BEZALEL GAVISH Subject: CFP - 5th Inter Conf on Telecomm Sys To: list1: ;, tis.com@TIS.COM Message-Id: <01I9IFQSQE3M8WX6ZK@ctrvax.Vanderbilt.Edu> X-Vms-To: IN%"list1" X-Vms-Cc: GAVISHB Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: dns-security-approval@neptune.tis.com Precedence: bulk TSM97CFP C A L L for P A P E R S 5th International Conference on Telecommunication Systems Modelling and Analysis March 20-23, 1997 Nashville, TN Sponsored by: American Telecommunications Systems Management Association BellSouth Telecommunications, Inc. IFIP Working Group 7.3 "Computer system modelling and performance evaluation" INFORMS Technical Section on Telecommunications INFORMS College of Information Systems The 5th International Conference on Telecommunication Systems - Modelling and Analysis will be held in Nashville on March 20-23, 1997. The conference will build on the tradition of the earlier conferences with a few changes in format due to the new conference location. The general idea is to limit the number of participants, concentrate on a few topics, present new problems and problem areas, encouraging informal interaction and exchanges of ideas. The objective is to advance the state of the modelling and analysis in telecommunications by stimulating research activity on new and important problems. The conference will be divided into segments with each segment devoted to a specific topic. This will allow for little conflict between segments. All papers will be screened by the Program Committee to ensure the quality of presentations. A decentralized paper handling process will be used. The Program Committee has been divided along geographical regions with a separate Program Subcommittee assigned to each region. Abstracts and papers should be submitted directly to the Program Committee Chair of the appropriate area. It is expected that this will expedite the paper review process. In response to suggestions made by last year's participants, social and cultural activities will be included in the 1997 agenda. The conference will be held at two sites, Thursday and Friday meetings will take place at the Tenessee Economic Development Center at the BellSouth Tower in downtown Nashville. The Saturday and Sunday meeting will be held at the Union Station hotel (see description at the end of the message). Lead Speakers and Keynote speakers include: Erol Gelenbe, Andrew Viterbi, Paul Kuehn. The Chairmen of the geographic Program Committees are: ---Australia, New Zealand and South East Asia: Prof. Richard Harris Department of Communication and Electronic Engineering Royal Melbourne Institute of Technology 723 Swanston Street Carlton, Victoria Australia, 3001 Phone : 61 3 9282 2450 (CATT), 61 3 9660 2457 (RMIT) Fax : 61 3 9282 2490 (CATT), 61 3 9660 1060 (RMIT) E-Mail : richard@catt.rmit.edu.au ---Europe: (except Scandinavia and Baltic states) Prof. Guy Pujolle Laboratoire PRiSM Universite de Versailles - Saint Quentin 45 avenue des Etats-Unis 78 035 Versailles Cedex FRANCE Phone : +33 (1) 39 25 40 61 Fax : +33 (1) 39 25 40 57 E-Mail : guy.pujolle@prism.uvsq.fr ---Europe: (Scandinavia and Baltic states) Dr. Johan M. Karlsson Department of Communication Systems Lund Institute of Technology P.O. Box 118 S-221 00 Lund Sweden E-Mail : johan@tts.lth.se ---North America: Prof. June S. Park Department of Management Sciences The University of Iowa 108 Pappajohn Business Administration Bldg. Iowa City, IA 52242-1000 USA Phone : 319-335-2087 Fax : 319-335-1956 E-Mail : jpark@scout-po.biz.uiowa.edu ---North East Asia: Prof. Yutaka Takahashi Graduate School of Information Science Nara Institute of Science and Technology Nara 630-01, Japan Phone : 81 74 372 5350 Fax : 81 74 372 5359 E-Mail : yutaka@is.aist-nara.ac.jp ---South and Central America: Dr. Ernesto Santibanez-Gonzalez Escuela de Ingenieria Industrial Universidad Catolica, Valparaiso Av. Brasil 2147 Valparaiso Chile Phone : 56 32 257331 Fax : 56 2 214823 E-Mail : esantiba@aix1.ucv.cl ---Chairman of the Economics track: Prof. William W. Sharkey Federal Communications Commission 1919 M Street Washington, DC 20554 USA Phone : 202-418-2743 Fax : 202-418-1413 E-Mail : wsharkey@fcc.gov ---All other geographic areas: Prof. Bezalel Gavish Owen Graduate School of Management Vanderbilt University Tel: 615-322-3659 401 21st Avenue South FAX: 615-343-7177 Nashville, TN 37203 Email: gavishb@ctrvax.vanderbilt.edu Listed below are some of the potential segments: -- Configuration of ATM networks -- Internet and its Impact on Commerce -- Internet and Intranet -- Standards -- Topological Design and Network Configuration Problems -- Design and Analysis of Local Access Networks and Outside Plant Problems -- Low Earth Orbit Satellite Communication Systems -- Cellular Systems and PCS Modelling and Configuration -- Time Dependent Expansion of Telecommunication Systems -- Designing Networks for Reliability and Availability -- Network Design Problems in Gigabit and Terabit Networks -- LAN, WAN Global Network Interconnection -- ATM, ISDN, BISDN Modeling and Analysis Issues -- Artificial Intelligence/Heuristics in Telecommunication Systems -- Group Decision Support Systems -- Quantitative Methods in Network Management -- Pricing and Economic Analysis of Telecommunications -- Impact of Telecommunications on Industrial Organization -- Performance Evaluation of Telecommunication Systems -- Distributed Computing and Distributed Data Bases -- Security and Privacy Issues in Telecommunications -- Virtual Reality, Multimedia and their Impact The Program Committee is open to any ideas you might have regarding additional topics or format of the conference. The intention is whenever possible, to limit the number of parallel sessions to two. The conference is scheduled over a weekend so as to reduce teaching conflicts for academic participants, enabling participants to take advantage of weekend hotel and airfare rates and of the many events that take place in the downtown area. Due to the limit on the number of participants early conference and hotel registration is recommended. The Union Station Hotel is the official hotel of the conference. To ensure your participation, please use the following steps: 1. Send to the appropriate Program Committee Chair by October 1, 1996, a paper (preferable), or titles and extended abstracts for potential presentations to be considered for the conference. Sending more than one extended abstract is encouraged, enabling the Program Committee to have a wider choice in terms of assigning talks to segments. Use E-mail to expedite the submission of titles and abstracts. 2. Use the forms at the end of this message to preregister for the conference and the hotal. Let us also know if you would like to have a formal duty during the conference as: Session Chair, or Discussant. 3. You will be notified by December 1, 1996, which abstract/s have been selected for the conference. Detailed instructions on how to prepare camera ready copies will be sent to authors of accepted presentations. January 30, 1997, is the deadline for sending a final version of the paper. Participants will receive copies of the collection of papers to be presented. All papers submitted to the conference will be considered for publication in the "Telecommunication Systems" Journal. The Program Committee looks forward to receiving your feedback/ideas. Feel free to volunteer any help you can offer. If you have suggestions for Segment Leaders (i.e., individuals who will have a longer time to give an overview/state of the art talk on their segment subject) please E-mail them to Prof Gavish. Also, if there are individuals whose participation you view as important, please send their names and E-mail addresses to the Program Committee Chairman, or forward to them a copy of this message. I look forward to a very successful conference. Sincerely yours, Bezalel Gavish ------------------------------------------------------------------------------- Cut Here ------------------------------------------------------------------------------- Fifth International Conference on Telecommunication Systems Modelling and Analysis REGISTRATION FORM Date: __________________ Dates: March 20, 1997 (afternoon) to March 23, 1997 Name: ________________________________________ Title: __________________ Affiliation: __________________________________________________________________ Address: __________________________________________________________________ __________________________________________________________________ Phone: ____________________________ FAX: _______________________________ E-mail: __________________________________________________________________ Potential Title of Paper(s): __________________________________________________ ____________________________________________________________________ I would like to Volunteer as Comments A Session Chair : Yes No ________________________________________________ A Discussant : Yes No ________________________________________________ Organize a Session: Yes No ________________________________________________ ________________________________________________ REGISTRATION RATES and DEADLINES Last Applica- Academic Industry Corporate ble Date Rate Rate Rate --------------- -------- -------- -------- 1. Preregistration Until Dec. 9, 1996 $ 400 $ 500 $1,300 2. Registration Until Jan. 15, 1997 $ 500 $ 600 $1,300 3. On Site Registration After Jan. 15, 1997 $ 600 $ 750 $1,500 As part of the conference registration dues you can become a member of the "American Telecommunication Systems Management Association" . Please mark an X in the following entry if you wish to become an ATSMA member. ____ Yes, I wish to become an ATSMA member. ____ No, I don't wish to become an ATSMA member. Mail your registration form and check to: Mrs. Dru Lundeng Owen Graduate School of Management Vanderbilt University 401 21st Avenue, South Nashville, TN 37203, USA The check should be endorsed to: ATSMA, Inc. Refund Policy: Half refund, for requests received by February 1, 1997. No refund after February 1, 1997. ----------------------------------------------------------------------------- If you have any questions regarding the conference, please contact Dru Lundeng at 615-322-3694 or through E-mail at lundeng@ctrvax.vanderbilt.edu. Hotel Reservation A block of rooms has been reserved at Union Station Hotel for the Conference participants. Please make your hotel arrangements early, to insure getting a room at the special conference rate. You will need to mention that you are a participant of the Telecommunication Systems Conference to receive the best price. Our advice is to make your reservations as soon as possible. Hotel rooms will be released from the Telecommunication Systems Conference blocks on February 15, 1997, so please be sure and reserve your rooms before February 15th. Union Station Hotel 1001 Broadway Nashville, TN 37203 Phone: 615-726-1001 or 1-800-331-2123 Fax: 615-742-3084 $99.00 Single or Double Occupancy Room $109.00 Triple or Quad Occupancy Room - Rates are subject to state and local tax, which is now 12.25 percent. ------------------------------------------------------------------------- Union Station Hotel Reservation Request Form Name of Conference: Telecommunication Systems Conference Arrival Date _________________ Departure Date __________________ Guest Name:__________________________________________________ Address :__________________________________________________ :__________________________________________________ Phone No. :__________________________________________________ A one night deposit should be enclosed to guarantee the reservation Payment Method: Check Check No.______________ Amount____________ Credit Card Type______________ No.____________________ Expiration Date____________ Type of Room: King or 2 Double Beds Smoking or Nonsmoking -------------------------------------------------------------------------- Union Station Hotel Description A Grand Heritage Hotel Features and Amenities In the heart of "Music City" stands a hotel with the personality of an intimate friend...Union Station Hotel. The heartbeat of Nashville has always been strongest at the Union Station. >From the grand opening in 1890 until the decline of rail travel in the 50s no other building in the city has been the site of more commercial activity and human drama. Nearly a century later, the Union Station Hotel, a National Historic Landmark, is again an integral part of life in Music City 124 guest rooms including 13 suites on seven levels are architecturally distinctive and capture the historic elegance of a bygone era. Stained glass, glittering gold leaf and newly silvered mirrors scatter reflections of an era which has endured for nearly a century. 4 conference rooms with over 10,000 square feet of flexible meeting and banquet space to accommodate groups of 5 to 200. * Arthur's Restaurant - gourmet dining, the recipient of the Mobil Travel Guide's Four Stars, Wine Spectator's Award of Excellence, and the Travel Holiday Award. * Broadway Bistro - casual dining open for lunch and dinner. Selected in the 1996 Zagat Survey as the city's best overall and best dining hotel. Heritage Executive Level with enhanced amenities ideal for the business and leisure traveler including concierge service, continental breakfast and evening cocktails Monday through Friday. * Valet parking. * Complimentary limo service in downtown Nashville. * Complimentary newspaper. * Blocks from downtown area, famed Music Row, Vanderbilt University and Convention Center. Recommended Airport: Nashville Metro Airport, 7 miles to the East. Transportation: Grayline Shuttle to the hotel. $8.00 one way, $14.00 round trip. Complimentary shuttle service within three mile radius of hotel for conference guests.  ------------------------------------------------------------------------------- Bezalel Gavish Owen Graduate School of Management Vanderbilt University Nashville, TN, 37203 Bitnet: GAVISHB@VUCTRVAX Internet: GAVISHB@CTRVAX.VANDERBILT.EDU Tel: (615) 322-3659 Home: (615) 370-0813 FAX: (615) 343-7177 ------------------------------------------------------------------------------- Received: from relay.hq.tis.com by neptune.TIS.COM id aa26417; 18 Sep 96 17:27 EDT Received: by relay.hq.tis.com; id RAA18722; Wed, 18 Sep 1996 17:31:25 -0400 Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma018715; Wed, 18 Sep 96 17:31:15 -0400 Received: from antares.hq.tis.com.tis.com by tis.com (4.1/SUN-5.64) id AA24540; Wed, 18 Sep 96 17:30:27 EDT Date: Wed, 18 Sep 96 17:30:27 EDT From: Olafur Gudmundsson Message-Id: <9609182130.AA24540@tis.com> Received: by antares.hq.tis.com.tis.com (4.1/SMI-4.1) id AA07127; Wed, 18 Sep 96 17:31:05 EDT To: dns-security@TIS.COM, ietf-announce@ietf.org, saag@TIS.COM Cc: bind-workers@vix.com Subject: ANNOUNCE: TIS/DNSSEC Beta 1.3.1 is now available worldwide Sender: dns-security-approval@neptune.tis.com Precedence: bulk We are pleased to announce that the third Beta release of TIS/DNSSEC Beta-1.3.1 is now available. This is exportable with the restrictions identified in the following paragraph. /* * Trusted Information Systems, Inc. has received approval from the * United States Government for export and reexport of TIS/DNSSEC * software from the United States of America under the provisions of * the Export Administration Regulations (EAR) General Software Note * (GSN) license exception for mass market software. Under the * provisions of this license, this software may be exported or * reexported to all destinations except for the embargoed countries of * Cuba, Iran, Iraq, Libya, North Korea, Sudan and Syria. Any export * or reexport of TIS/DNSSEC software to the embargoed countries * requires additional, specific licensing approval from the United * States Government. */ This version is a implementation of the current DNSSEC draft and it is based on bind-4.9.4-p1,it uses RSAREF for signature generation and verification, you need to retrieve your own copy from RSA. We are actively seeking beta testers. Feel free to test against our secure nameserver for zone sd-bogus.tis.com which is served from uranus.hq.tis.com. We are also making a DNSSEC enhanced version of DIG available, in executable form for popular platforms. This version of dig is extended to query sd-bogus and other secure servers. There are no export restrictions on the executables The distribution is available as ftp://ftp.tis.com/pub/DNSSEC/sec_bind494-b131.tar.gz Or you can access our web page at http://www.tis.com/docs/research/network/dns.html The new dig a sunos4.x executable versions are ftp://ftp.tis.com/pub/DNSSEC/sdig.sunos4.gz Other versions will be made available as ftp://ftp.tis.com/pub/DNSSEC/sdig..gz If you have any questions or problems please send a note to tisdnssec-support@tis.com. If you compile the new dig on a popular platform that we do not have an executable for please let us know. Enjoy, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Olafur Gudmundsson ogud@tis.com (301)-854-6889(phone) (301)-854-5363 FAX Received: from localhost by ietf.org id aa27950; 24 Sep 96 10:05 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@TIS.COM Cc: dns-security@TIS.COM From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnssec-update-02.txt Date: Tue, 24 Sep 1996 10:05:41 -0400 Message-Id: <9609241005.aa27950@ietf.org> Sender: dns-security-approval@neptune.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Security Working Group of the IETF. Title : Secure Domain Name System Dynamic Update Author(s) : D. Eastlake Filename : draft-ietf-dnssec-update-02.txt Pages : 15 Date : 09/23/1996 Domain Name System (DNS) protocol extensions have been defined to authenticate the data in DNS and provide key distribution services (draft-ietf-dnssec-secext-10.txt). DNS Dynamic Update operations have also been defined (draft-ietf-dnsind-dynDNS-*.txt>, but without a detailed description of strong security for the update operation. This draft describes how to use DNS digital signatures covering requests and data to secure updates and restrict them to those authorized to perform them as indicated by the updater's possession of cryptographic keys. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnssec-update-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-update-02.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dnssec-update-02.txt". NOTE: The mail server at ds.internic.net 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. For questions, please mail to Internet-Drafts@ietf.org 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@ds.internic.net" Content-Type: text/plain Content-ID: <19960923150731.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-update-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-update-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960923150731.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dns-security Wed Nov 6 13:52:27 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA04729 for dns-security-outgoing; Wed, 6 Nov 1996 13:46:29 -0500 (EST) Date: Wed, 6 Nov 1996 13:48:13 -0500 (EST) From: John Kelley Message-Id: <199611061848.NAA16006@clipper.hq.tis.com> To: dns-security@tis.com Subject: ANNOUNCEMENT -- New majordomo server Sender: owner-dns-security@ex.tis.com Precedence: list ANNOUNCEMENT All majordomo lists, including this one, that have been maintained on neptune.hq.tis.com, have been moved to portal.ex.tis.com. This has allowed us to upgrade our software and hardware to hopefully provide much better mailing list service. There may be a few rough spots during the transition and until all the pieces are fitted together. One major temporary problem is that the access to the current list archives is not available at this time. Another announcement will not be made when they are available, but the info file for each particular list will mention that they are back. Please send any problems you may see about the new server to majordomo-owner@ex.tis.com. Commands to the majordomo@neptune address will be forwarded to the new server for the forseeable future. For the most efficient response to commands or postings, it is recommended using the majordomo@ex.tis.com or @ex.tis.com addresses. Thank you for your patience in this matter. -TIS Majordomo Administrators From owner-dns-security Fri Nov 15 07:43:18 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA25692 for dns-security-outgoing; Fri, 15 Nov 1996 07:39:11 -0500 (EST) Message-Id: <199611151239.HAA25692@portal.ex.tis.com> To: dns-security@tis.com Subject: name compression Date: Thu, 14 Nov 1996 22:26:15 -0800 From: Paul A Vixie Sender: owner-dns-security@ex.tis.com Precedence: list in DNSSEC (5-August-96 version) we see: The "signer's name" field is the domain name of the signer generating the SIG RR. This is the owner of the public KEY RR that can be used to verify the signature. It is frequently the zone which contained the RR(s) being authenticated. The signer's name may be compressed with standard DNS name compression when being transmitted over the network. in RFC 1035 we see: The following RR definitions are expected to occur, at least potentially, in all classes. In particular, NS, SOA, CNAME, and PTR will be used in all classes, and have the same format in all classes. Because their RDATA format is known, all domain names in the RDATA section of these RRs may be compressed. ... Pointers can only be used for occurances of a domain name where the format is not class specific. If this were not the case, a name server or resolver would be required to know the format of all RRs it handled. As yet, there are no such cases, but they may occur in future RDATA formats. now, as it turns out, BIND does this wrong and i should not open the worm can. but i think it is fair to say that DNSSEC should not specify compression here. --BAA05077.848038975/relay.hq.tis.com-- From owner-dns-security Fri Nov 15 12:55:35 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA27294 for dns-security-outgoing; Fri, 15 Nov 1996 12:50:29 -0500 (EST) Date: Fri, 15 Nov 1996 12:19:40 -0500 (EST) From: "Donald E. Eastlake 3rd" To: Paul A Vixie Cc: dns-security@tis.com Subject: Re: name compression In-Reply-To: <199611151239.HAA25692@portal.ex.tis.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: list On Thu, 14 Nov 1996, Paul A Vixie wrote: > Date: Thu, 14 Nov 1996 22:26:15 -0800 > From: Paul A Vixie > To: dns-security@tis.com > Subject: name compression > > in DNSSEC (5-August-96 version) we see: > > The "signer's name" field is the domain name of the signer generating > the SIG RR. This is the owner of the public KEY RR that can be used > to verify the signature. It is frequently the zone which contained > the RR(s) being authenticated. The signer's name may be compressed > with standard DNS name compression when being transmitted over the > network. While it is true that this makes it non-cachable by security non-aware DNS implementaitons, don't BIND not cache RRs it doesn't know about anyway? > in RFC 1035 we see: > > The following RR definitions are expected to occur, at least > potentially, in all classes. In particular, NS, SOA, CNAME, and PTR > will be used in all classes, and have the same format in all classes. > Because their RDATA format is known, all domain names in the RDATA > section of these RRs may be compressed. > ... > Pointers can only be used for occurances of a domain name where the > format is not class specific. If this were not the case, a name server > or resolver would be required to know the format of all RRs it handled. > As yet, there are no such cases, but they may occur in future RDATA > formats. The SIG RR isn't class specific. Neither is KEY or NXT. They work fine for securing RRs of any class. So RFC 1035 would imply they can be compressed. On the other hand, I think RFC 1035 is way too conservative here. At the time, I believe, it was thought that there might be many classes, perhaps even some whose RR formats were not under IETF change control. That might have made keeping track of the formats of class specific RRs a nightmare. However, given that the IN class has turned out to be so totally dominant, it makes perfect sense to name compress any RR understood by all the DNS implementations out there, even if it is an IN class only RR. > now, as it turns out, BIND does this wrong and i should not open the worm can. > but i think it is fair to say that DNSSEC should not specify compression here. As per the above, I still think it should. > --BAA05077.848038975/relay.hq.tis.com-- Donald ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html From owner-dns-security Tue Nov 19 15:55:35 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA02030 for dns-security-outgoing; Tue, 19 Nov 1996 15:51:13 -0500 (EST) Date: Tue, 19 Nov 1996 15:50:23 -0500 (EST) From: "Donald E. Eastlake 3rd" To: Randy Bush Cc: namedroppers , dns-security@tis.com Subject: Re: dnsind dnssec joint meeting in San Jose In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk What about the TSIG draft? Donald On Wed, 16 Oct 1996, Randy Bush wrote: > Date: Wed, 16 Oct 96 15:18 PDT > From: Randy Bush > To: namedroppers > Cc: "James M. Galvin" > Subject: dnsind dnssec joint meeting in San Jose > > At the ADs' recommendation, we have scheduled a joint session with dnssec > for San Jose as follows: > > > Date: Fri, 11 Oct 1996 10:40:06 -0400 > To: Randy Bush > From: Marcia Beaulieu > Subject: SAN JOSE IETF: DNSIND/DNSSEC > Cc: "James M. Galvin" , kasten+iesg@ftp.com, > jburgan@baynetworks.com, jis@mit.edu > > This is to confirm one joint session for DNSIND/DNSSEC as follows: > > Friday, December 13 at 0900 > > If you plan to use the DNSSEC session on Wednesday at 0900 to hold this > meeting, please let me know. This meeting would be opposite rmonmib, rtfm, > tagsw-bof). > > Please remember to send us the agenda for the meeting so we can post it. > > Marcia > > > The sole agenda item of which I am aware is DynUpd and Donald's parallel > document. Please submit other agenda items to me. > > As I suspect that dnssec's Wednesday meeting has the same agenda, I am > hoping we can merge and save a session. James? > > Thanks. > > randy > ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html From owner-dns-security Wed Nov 20 01:23:15 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA02429 for dns-security-outgoing; Wed, 20 Nov 1996 01:21:25 -0500 (EST) Message-Id: Date: Tue, 19 Nov 96 22:22 PST From: randy@psg.com (Randy Bush) To: "Donald E. Eastlake 3rd" Cc: namedroppers , dns-security@tis.com Subject: Re: dnsind dnssec joint meeting in San Jose References: Sender: owner-dns-security@ex.tis.com Precedence: bulk > What about the TSIG draft? I intend to delay it until after we get o the chartered work of dnsind done o any incidentals which do not impinge on the chartered work done TSIG impinges on the chartered work and does not clearly help complete it. If I had been asked whether it should be published as a dnsind ID, as is supposed to be part of the process, I would have hesitated. Do you see discussion of it as needed to get dynamic update and secure dynamic update out of draft? randy From owner-dns-security Wed Nov 20 17:11:31 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA05272 for dns-security-outgoing; Wed, 20 Nov 1996 17:04:22 -0500 (EST) Date: Wed, 20 Nov 1996 14:06:28 -0800 (PST) X-btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: dns-security@tis.com From: paul@vix.com (Paul A Vixie) Subject: Re: dnsind dnssec joint meeting in San Jose Organization: Vixie Enterprises Message-ID: References: NNTP-Posting-Host: wisdom.home.vix.com In-reply-to: randy@psg.com's message of 19 Nov 1996 23:08:05 -0800 Xref: vixie local.mail.dns.security:418 Sender: owner-dns-security@ex.tis.com Precedence: bulk > Do you see discussion of it as needed to get dynamic update and secure > dynamic update out of draft? The way things have turned out, no. -- Paul Vixie La Honda, CA "Illegitimibus non carborundum." pacbell!vixie!paul From owner-dns-security Mon Nov 25 07:20:51 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA10561 for dns-security-outgoing; Mon, 25 Nov 1996 07:17:20 -0500 (EST) Date: Mon, 25 Nov 1996 07:17:20 -0500 (EST) From: owner-dns-security@ex.tis.com Message-Id: <199611251217.HAA10561@portal.ex.tis.com> To: namedroppers@internic.net Cc: dns-security@tis.com Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and draft-ietf-dnsind-clarify-02.txt) From: Havard.Eidnes@runit.sintef.no In-Reply-To: Your message of "Mon, 18 Nov 1996 15:41:07 -0500 (EST)" References: X-Mailer: Mew version 1.51 on Emacs 19.34.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Date: Sun, 24 Nov 1996 20:16:12 +0100 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id OAA10072 Sender: owner-dns-security@portal.ex.tis.com Precedence: bulk > Unfortunately, DNS Security makes all this a bit more complex. > > For example, you need to be able to have all of the security > RRs types (SIG, NXT, & KEY) present with a CNAME. And the > superzone's version of the KEY RR at a cut point is better than > the subzone's. Hm, let me see if I have understood this correctly. DNSSEC seems to specify that at a zone cut the parent zone contains an RR (e.g. KEY RR) with identical label, class and type as what can potentially be found in the child zone, but the two records have different data fields, different semantics, and that the RR from the parent is supposed to be considered "more credible" (or what else means "better") than the data from the child zone? I hope that I am not the only one feels uncomfortable with this. The way I understand it this would in effect create an RRset split over two different zones, which is in direct conflict with the clarify-02 draft (at least with my interpretation of it). Under DNSSEC, what other records have this property that they can be present both in the parent and the child zones (at a zone cut) and have different semantics attached to them dependent on where the data originates? SIG and NXT in addition to KEY? Are these the only ones? Can this be avoided? Cleanly? I thought a bit about the KEY RRs in conjunction with zone cuts, and the architectural purists among you can skip the rest of this paragraph... What about having the parent KEY RR stored with a different label in the parent zone (e.g. by adding "/pkey" or something like that to the label)? That way the name server for the parent zone can claim authority in the traditional manner for the KEY record, and you avoid having an RRset being "split" over two zones. (Ok, I have probably not understood the impact this might have on the NXT records.) I think that the broader issue here is "how strong a departure from existing practices should DNSSEC be allowed to impose", with the practical consequences from the decision being "how difficult will it be to gradually deploy DNSSEC into the DNS" (?). - Hevard From owner-dns-security Mon Nov 25 08:08:57 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA10632 for dns-security-outgoing; Mon, 25 Nov 1996 08:08:49 -0500 (EST) Date: Mon, 25 Nov 1996 08:08:49 -0500 (EST) From: Masataka Ohta Message-Id: <199611251156.UAA04363@necom830.hpcl.titech.ac.jp> Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and draft-ietf-dnsind-clarify-02.txt) To: Havard.Eidnes@runit.sintef.no Date: Mon, 25 Nov 96 20:56:24 JST Cc: namedroppers@internic.net, dns-security@tis.com In-Reply-To: <199611241916.UAA28839@vader.runit.sintef.no>; from "Havard.Eidnes@RUNIT.SINTEF.NO" at Nov 24, 96 8:16 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-dns-security@portal.ex.tis.com Precedence: bulk Havard; > > Unfortunately, DNS Security makes all this a bit more complex. > > > > For example, you need to be able to have all of the security > > RRs types (SIG, NXT, & KEY) present with a CNAME. And the > > superzone's version of the KEY RR at a cut point is better than > > the subzone's. > > Hm, let me see if I have understood this correctly. I'm afraid your attempt to persuade Donald will fail. Even if it had succeeded, there remains a problem that the glue information makes the packet size exceed 512 bytes. This is a problem of WG management. Long time ago, in some (Seatle?) DNSSEC meeting, there was a discussion and the WG agreements that: Cryptographically, glue informaiton in the parent zone gives no protection. For DNS compatibility, there should be no additional glue. Before and after the meeting, I repeatedly says Donald that he should remove it. But, he didn't. The chairman of the WG, James Galvin, also knows, but does not understand either, the issue. I finally gave up and abandoned the WG. The problems are: Donald does not know DNS well to understand subtle architecural principles of it. Donald is a bad editor not to reflect the WG consensus to the WG draft. James Galvin is a bad chair not to be able to remove Donald. They are not technical problems and I know technical discussion is meaningless until after the chair and the editor are replaced. Donald and James, do you want to voluntarily step down or, at least, let DNSIND modify the draft? Masataka Ohta From owner-dns-security Mon Nov 25 08:36:15 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA10701 for dns-security-outgoing; Mon, 25 Nov 1996 08:35:53 -0500 (EST) Date: Mon, 25 Nov 1996 08:39:06 -0500 (EST) From: Edward Lewis X-Sender: lewis@singsing.hq.tis.com To: owner-dns-security@tis.com cc: namedroppers@internic.net, dns-security@tis.com, Olafur Gudmundsson Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and In-Reply-To: <199611251217.HAA10561@portal.ex.tis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk On Mon, 25 Nov 1996 owner-dns-security@tis.com wrote: Pardon my ignorance, but I'm thrown be the headers. I hope this reply gets back to (at least) the real sender... > From: Havard.Eidnes@runit.sintef.no > Sender: owner-dns-security@portal.ex.tis.com > > Hm, let me see if I have understood this correctly. DNSSEC seems to > specify that at a zone cut the parent zone contains an RR (e.g. KEY > RR) with identical label, class and type as what can potentially be > found in the child zone, but the two records have different data > fields, different semantics, and that the RR from the parent is > supposed to be considered "more credible" (or what else means > "better") than the data from the child zone? In a nutshell, the "child" data is *always* more credible than the "parent" data. At a zone cut, the parent zone is authoritative for 1) the existence of the zone cut name, 2) for the existence of the zone cut, and 3) whether the child zone is secured or not secured by a zone key. The result of the parent's being authoritive for the existence of the name is that the parent has an NXT including the name. (For the sake of clarity, assume that we are not considering dynamic update.) A zone cut is signified by an NS RR set. What's in the NS RR set is not important here, but that an NS RR set is present. This gets complicated. The child zone is authoritative for the contents of the NS record. The NS record has two authoritative parts - it's existence and it's contents. As long as the parent has one NS record for the child, the child may hold as many as they wish - but this would constitute a configuration error. Any queryier should trust the child's data. (If the parent held NS record has a wrong nameserver, then there is a lame delegation and this problem needs fixing.) A secured child is signified by the parent's signing of a child's zone key. The zone key arrives "out of band" of the normal DNS data flow. (I.e., not via a recursive lookup or zone transfer.) The out of band transfer is needed because the key arrives unsigned. The parent signs the key and sends the signature back, also out of band - since there is no other mechanism for this "in band." > The way I understand it this would in effect create an RRset split > over two different zones, which is in direct conflict with the With one exception, this is not a problem. The exception involves the NXT RR set. As the name of the zone cut appears in two zones, there are two different NXT's, each pointing to a different next name (one each in the zone above and in the zone below the cut). In all other cases, the child's data is more credible. Care must be taken though, during zone transfers, not to eliminate the parent's signature of the zone key(s). That is not a credibility issue, however. > Under DNSSEC, what other records have this property that they can be > present both in the parent and the child zones (at a zone cut) and > have different semantics attached to them dependent on where the > data originates? SIG and NXT in addition to KEY? Are these the > only ones? Only the NXT data is different, but the semantics are the same. This is because the zones below and above the cut are different and have different "next" names. If there are any other conflicts, then there is a configuration error, or a old RR's haven't been refreshed yet (TTL hasn't expired yet). KEY and SIG RR's do not have different contents nor semantics on different sides of the zone cut. > Can this be avoided? Cleanly? I don't think anything is in need of being avoided cleanly. Given more consideration, dynamic update does not pose much of a problem, but I don't want to get into that here, as details are still being reviewed. > paragraph... What about having the parent KEY RR stored with a > different label in the parent zone (e.g. by adding "/pkey" or > something like that to the label)? That way the name server for the > parent zone can claim authority in the traditional manner for the > KEY record, and you avoid having an RRset being "split" over two > zones. (Ok, I have probably not understood the impact this might > have on the NXT records.) The parent zone has no authority over the zone key for a subzone. By signing it, the parent is recognizing that the child is a secured zone, and that's all the parent needs to know. The parent will have to give the child the SIG record for inclusion in the child's zone transfers. (The parent may keep the data around - the zone key and the signature, but this is for performance reasons. The name server implementing the parent zone may be asked for the key and signature and it can assume the data is kept is accurate. At some time, however, it might get the real data from the child - and it should be the same. This transfer might be a zone transfer because many times a parent zone's nameserver acts as a name server [primary or secondary] for the child too.) > I think that the broader issue here is "how strong a departure from > existing practices should DNSSEC be allowed to impose", with the > practical consequences from the decision being "how difficult will > it be to gradually deploy DNSSEC into the DNS" (?). > > - Hevard I think the only issue will be the out of band mechanisms for running delegated (child) zones. I don't forsee a significant impact of DNSSEC on the current mode of operations of DNS. Of course, there DNSSEC will result in more data being passed, and more activity to verify signatures, but DNS will still "look" like it used too. (I'm simplifying my argument here since the statement above is very general.) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: 301-854-5794 Email: lewis@tis.com From owner-dns-security Mon Nov 25 09:21:06 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA10899 for dns-security-outgoing; Mon, 25 Nov 1996 09:20:54 -0500 (EST) Date: Mon, 25 Nov 1996 09:20:11 -0500 (EST) From: "Donald E. Eastlake 3rd" To: Havard.Eidnes@runit.sintef.no Cc: namedroppers@internic.net, dns-security@tis.com Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and draft-ietf-dnsind-clarify-02.txt) In-Reply-To: <199611241916.UAA28839@vader.runit.sintef.no> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by portal.ex.tis.com id JAA10896 Sender: owner-dns-security@ex.tis.com Precedence: bulk On Sun, 24 Nov 1996 Havard.Eidnes@RUNIT.SINTEF.NO wrote: > Date: Sun, 24 Nov 1996 20:16:12 +0100 > From: Havard.Eidnes@RUNIT.SINTEF.NO > To: namedroppers@internic.net > Cc: dns-security@TIS.COM > Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and draft-ietf-dnsind-clarify-02.txt) > > > Unfortunately, DNS Security makes all this a bit more complex. > > > > For example, you need to be able to have all of the security > > RRs types (SIG, NXT, & KEY) present with a CNAME. And the > > superzone's version of the KEY RR at a cut point is better than > > the subzone's. > > Hm, let me see if I have understood this correctly. DNSSEC seems to > specify that at a zone cut the parent zone contains an RR (e.g. KEY > RR) with identical label, class and type as what can potentially be > found in the child zone, but the two records have different data > fields, different semantics, and that the RR from the parent is > supposed to be considered "more credible" (or what else means > "better") than the data from the child zone? Well I wouldn't say that. If the superzone is secure, it is mandatory for it to have at least one KEY RR at each cut point leaf node. And, if the zone is secure, everything in it is signed, including these cut point KEY RRs, NS RRs, etc. (It could be that the signed key merely certifies that the subzone is not secure.) The superior authenticity of the KEY in the superzone really comes from it being signed by the superzone. If the same KEY and SIG appear at the apex of the subzone, they are equally authentic. If the subzone administrator is careful to put the zone public key and it's authenticating signature from above in the subzone, then it is not clear that any change in the standard DNS authority strategy is required for KEY in this case. > I hope that I am not the only one feels uncomfortable with this. > The way I understand it this would in effect create an RRset split > over two different zones, which is in direct conflict with the > clarify-02 draft (at least with my interpretation of it). > > Under DNSSEC, what other records have this property that they can be > present both in the parent and the child zones (at a zone cut) and > have different semantics attached to them dependent on where the > data originates? SIG and NXT in addition to KEY? Are these the > only ones? I think that for all the security RRs, the subzone RRs can be aranged to be superset of the superzone's RRs given enough cooperation between the subzone and superzone administrators. > Can this be avoided? Cleanly? > > I thought a bit about the KEY RRs in conjunction with zone cuts, and > the architectural purists among you can skip the rest of this > paragraph... What about having the parent KEY RR stored with a > different label in the parent zone (e.g. by adding "/pkey" or > something like that to the label)? That way the name server for the > parent zone can claim authority in the traditional manner for the > KEY record, and you avoid having an RRset being "split" over two > zones. (Ok, I have probably not understood the impact this might > have on the NXT records.) I don't think there is a need for this. > I think that the broader issue here is "how strong a departure from > existing practices should DNSSEC be allowed to impose", with the > practical consequences from the decision being "how difficult will > it be to gradually deploy DNSSEC into the DNS" (?). I'm not sure how strong the correlation is between these. TIS has implemented DNSSEC in BIND and my understanding is that the intent is for those changes to be incorporated in the main version at some point. And I believe Microsoft is doing a DNS implementation and looking at DNSSEC. If both of these happen, then deplying DNSSEC at a site is just switching to a more recent version of the software. If you are asking about interoperability of secure and non-secure DNS servers, I believe this is fully covered in the DNSSEC draft. The only insurmountable problem is that you can't secure CNAME RRs retrieved fron a non-secure server. > - Håvard Donald ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html From owner-dns-security Mon Nov 25 09:27:55 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA10952 for dns-security-outgoing; Mon, 25 Nov 1996 09:27:53 -0500 (EST) From: Masataka Ohta Message-Id: <199611251415.XAA04706@necom830.hpcl.titech.ac.jp> Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and To: lewis@tis.com (Edward Lewis) Date: Mon, 25 Nov 96 23:15:39 JST Cc: owner-dns-security@tis.com, namedroppers@internic.net, dns-security@tis.com, ogud@tis.com In-Reply-To: ; X-Mailer: ELM [version 2.3 PL11] Sender: owner-dns-security@ex.tis.com Precedence: bulk Edward; > The result of the parent's being authoritive for the existence of the > name is that the parent has an NXT including the name. NXT is another bad design of Donald. Even though I'm the first to show how to authoritatively show that some domain does not exist, he modified it badly only to make the protocol incompatible to DNS. Masataka Ohta From owner-dns-security Mon Nov 25 12:47:28 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA11345 for dns-security-outgoing; Mon, 25 Nov 1996 12:46:26 -0500 (EST) Message-Id: Date: Mon, 25 Nov 96 09:48 PST From: randy@psg.com (Randy Bush) To: namedroppers@internic.net, dns-security@tis.com Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and draft-ietf-dnsind-clarify-02.txt) References: <199611241916.UAA28839@vader.runit.sintef.no> Sender: owner-dns-security@ex.tis.com Precedence: bulk Does this level of misunderstanding and complexity ring alarm bells in anybody's head other than mine? randy From owner-dns-security Mon Nov 25 13:29:50 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA11427 for dns-security-outgoing; Mon, 25 Nov 1996 13:29:34 -0500 (EST) Date: Mon, 25 Nov 1996 13:32:27 -0500 (EST) From: Edward Lewis X-Sender: lewis@singsing.hq.tis.com To: Randy Bush cc: namedroppers@internic.net, dns-security@tis.com Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and draft-ietf-dnsind-clarify-02.txt) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk On Mon, 25 Nov 1996, Randy Bush wrote: > Does this level of misunderstanding and complexity ring alarm bells in > anybody's head other than mine? Being new to this game, I don't know about the "misunderstanding" issue, but having spent some time hammering away at a program to apply signatures to a zone, I don't think complexity is a serious issue. There is inherently the issue of lame delegations - wherein the information concerning a delegation is different in the delegating zone and the delegated zone (i.e., above and below the zone cut). DNSSEC definitely does not complicate that issue, but does offer some assistance - with signed NS records from the delegated zone and a signed NXT in the delegating zone, the resolver can safely assume there is a delegation and can identify the correct data. If the data as signed is inaccurate, then bets are off. Although the specifications may appear to be leading to a complex solution, as we have been delving deeper into the details *IMHO* I believe we are working towards at least one workable and simple solution to both DNSSEC and DNSSEC w/Dynamic Update. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: 301-854-5794 Email: lewis@tis.com From owner-dns-security Mon Nov 25 15:19:28 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA11636 for dns-security-outgoing; Mon, 25 Nov 1996 15:19:00 -0500 (EST) Date: Mon, 25 Nov 1996 15:18:24 -0500 (EST) From: "Donald E. Eastlake 3rd" To: namedroppers@internic.net, dns-security@tis.com Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and In-Reply-To: <199611251156.UAA04363@necom830.hpcl.titech.ac.jp> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk On Mon, 25 Nov 1996, Masataka Ohta wrote: > Date: Mon, 25 Nov 1996 08:08:49 -0500 (EST) > From: Masataka Ohta > Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and > draft-ietf-dnsind-clarify-02.txt) > To: Havard.Eidnes@runit.sintef.no > Date: Mon, 25 Nov 96 20:56:24 JST > Cc: namedroppers@internic.net, dns-security@tis.com > In-Reply-To: <199611241916.UAA28839@vader.runit.sintef.no>; from > "Havard.Eidnes@RUNIT.SINTEF.NO" at Nov 24, 96 8:16 pm > X-Mailer: ELM [version 2.3 PL11] > Sender: owner-dns-security@portal.ex.tis.com > Precedence: bulk > > Havard; > > > > Unfortunately, DNS Security makes all this a bit more complex. > > > > > > For example, you need to be able to have all of the security > > > RRs types (SIG, NXT, & KEY) present with a CNAME. And the > > > superzone's version of the KEY RR at a cut point is better than > > > the subzone's. > > > > Hm, let me see if I have understood this correctly. > > I'm afraid your attempt to persuade Donald will fail. > > Even if it had succeeded, there remains a problem that the > glue information makes the packet size exceed 512 bytes. Under what circumstances? Say you are using 768 bit keys (the draft recommends somewhat shorter ones) and retrieve NS from foo.com where the answers are ns1.foo.com and ns2.foo.com with glue A records. My real quick calculation of the answer size is 395 byte: 24 for the header, 32 each for the two NSs, and, as additional info, 23 for each of the two As, 121 for the zone KEY for the subzone and 140 for the SIG signing the KEY for the subzone. (I ignored name compression.) True if there are multiple KEYs or multiple SIGs, you can easily exceed the current UDP packet size but the explicit and overwhelming consensus of the WG was for simplicity even if it produced longer answers. People seemed to think that other changes would ameriorate the DNS UDP packet size problem before DNSSEC was sufficiently wide spread that this would be a serious problem. > This is a problem of WG management. > > Long time ago, in some (Seatle?) DNSSEC meeting, there was a > discussion and the WG agreements that: > > Cryptographically, glue informaiton in the parent zone gives > no protection. I don't quite know what your are saying in the above sentence but, indeed, the DNSSEC draft was modified from earlier versions to specifically prohibit SIGs on NS and glue A records in a superzone at cut points. > For DNS compatibility, there should be no additional glue. I don't know exactly what you mean here. If you are talking about NXT, for example, the WG did not decide to toally redesign that. > Before and after the meeting, I repeatedly says Donald that he should > remove it. > > But, he didn't. > > The chairman of the WG, James Galvin, also knows, but does not > understand either, the issue. > > I finally gave up and abandoned the WG. > > The problems are: > > Donald does not know DNS well to understand subtle > architecural principles of it. I don't know DNs as well as some people. But I trust Bob Austein, Paul Vixie, and the folks as TIS who are implementing DNSSEC. > Donald is a bad editor not to reflect the WG consensus to > the WG draft. There may be some reasonable points of technical disagreement but this isn't one of them. My draft is *exactly* the working group consensus. I understand that you don't like the DNSSEC WG consensus. I understand that you think the consensus is fatally flawed techncially. But, as far as I can tell, a completely overwhelming consensus of the WG supported the current draft. I stand by my job a editor in reflcting WG consensus. > James Galvin is a bad chair not to be able to remove Donald. I'm not sure why he would want to remove me since I've done everything he asked of me. > They are not technical problems and I know technical discussion > is meaningless until after the chair and the editor are replaced. > > Donald and James, do you want to voluntarily step down or, > at least, let DNSIND modify the draft? If you would like to propose specific changes to the IETF Proposed Standard, I'd be happy to look at them. I never thought it was carved in stone and would expect some changes as more implementation experience is gained. > Masataka Ohta Donald ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html From owner-dns-security Mon Nov 25 15:27:30 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA11683 for dns-security-outgoing; Mon, 25 Nov 1996 15:27:29 -0500 (EST) Date: Mon, 25 Nov 1996 15:26:47 -0500 (EST) From: "Donald E. Eastlake 3rd" To: namedroppers@internic.net, dns-security@tis.com Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and In-Reply-To: <199611251415.XAA04706@necom830.hpcl.titech.ac.jp> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk There are a number of different ways to authenticate the non-existence of names. If I recall correcly, your technique had, for a zone of any size, an enormous pile of RRs with the zone name (or a smaller number of enourmous RRs) which would have had to be indexed by some new technique to find the right one to send back on a non-existent name query, your proposal had nothing about and didn't consider wildcards, and I also don't recall how your proposal handled non-existent types for existing, if at all. But maybe I don't remember correctly. Maybe your prospal didn't have any of these problems. It doesn't seem very relavent unless the Proposed Standard turns out to be a problem, does it? I know you are absolutely certain it is fatally flawed but so far your belief has not be bourne out in practice. As far as I can remember, the NXT proposal in my and Charlie Kaufman's draft was original work and was not produced by modifying your proposal and certainly neither it nor any other part of the DNSSEC Proposed Standard was motivated by a desire to be incompatible with classic DNS. However this also doens't seem very relevant since you are credited for contributing and I think it is part of the normal WG process for ideas to be combined. Donald On Mon, 25 Nov 1996, Masataka Ohta wrote: > Date: Mon, 25 Nov 96 23:15:39 JST > From: Masataka Ohta > To: Edward Lewis > Cc: owner-dns-security@tis.com, namedroppers@internic.net, > dns-security@tis.com, ogud@tis.com > Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and > > Edward; > > > The result of the parent's being authoritive for the existence of the > > name is that the parent has an NXT including the name. > > NXT is another bad design of Donald. Even though I'm the > first to show how to authoritatively show that some domain > does not exist, he modified it badly only to make the > protocol incompatible to DNS. > > Masataka Ohta > > > ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html From owner-dns-security Mon Nov 25 15:39:31 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA11722 for dns-security-outgoing; Mon, 25 Nov 1996 15:39:29 -0500 (EST) Message-Id: <199611252039.PAA11722@portal.ex.tis.com> Date: Mon, 25 Nov 1996 15:19:50 -0500 (EST) From: "Donald E. Eastlake 3rd" To: namedroppers@internic.net, dns-security@tis.com Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and draft-ietf-dnsind-clarify-02.txt) In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@portal.ex.tis.com Precedence: bulk Masataka Ohta has always proclaimed the Proposed Standard for DNS Security to be fatally flawed. However, when I repeated challenged him to produce an exact specific case where it would not work (other than those document plainly in the draft), he never did. Since the people actually implementing it at TIS, who have a Beta release out and available, and other DNS experts who have looked at it to various depths, have yet to find any unsolvable problems, I suggest we wait a bit for more implementation and interoperation experience. Donald On Mon, 25 Nov 1996, Randy Bush wrote: > Date: Mon, 25 Nov 96 09:48 PST > From: Randy Bush > To: namedroppers@internic.net, dns-security@tis.com > Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and draft-ietf-dnsind-clarify-02.txt) > > Does this level of misunderstanding and complexity ring alarm bells in > anybody's head other than mine? > > randy > ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html From owner-dns-security Mon Nov 25 17:27:08 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA11770 for dns-security-outgoing; Mon, 25 Nov 1996 17:26:07 -0500 (EST) Message-Id: <2.2.32.19961125222641.01677670@pop-sb.software.com> X-Sender: WrenP@pop-sb.software.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 25 Nov 1996 14:26:41 -0800 To: randy@psg.com (Randy Bush), namedroppers@internic.net, dns-security@tis.com From: Paul Wren Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and draft-ietf-dnsind-clarify-02.txt) Sender: owner-dns-security@ex.tis.com Precedence: bulk At 09:48 AM 11/25/96 PST, Randy Bush wrote: >Does this level of misunderstanding and complexity ring alarm bells in >anybody's head other than mine? > I had previously replied privately to Randy, not wanting to stomp on anybody's toes, and he suggested I cc the list. Okay. As the developer of a ground-up rewrite of a DNS server from the RFC's, I do find it worrisome that a number of very complex issues are arising that were definitely not apparent on a first, second, or third reading (for me) of the DNSSEC draft. Since it is a "proposed standard" document, that is problematic. And while Ohta is classically a trouble-maker, there are some level-headed comments as well that seem to be an issue. I agree that secure DNS is a must-have, and that security is a very complicated topic, but the interoperability of the Internet is not necessarily proven or supported by the statement that "TIS has a working BETA on top of BIND" and that "MS is working on it" as if those two are all that is required. (the second being a less-than-comforting thought to anyone without $1 billion in the bank) Note that my opinions are my own and all that... -- Paul W. From owner-dns-security Tue Nov 26 07:27:09 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA12772 for dns-security-outgoing; Tue, 26 Nov 1996 07:24:40 -0500 (EST) From: Masataka Ohta Message-Id: <199611260345.MAA06627@necom830.hpcl.titech.ac.jp> Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and To: dee@cybercash.com (Donald E. Eastlake 3rd) Date: Tue, 26 Nov 96 12:45:02 JST Cc: namedroppers@internic.net, dns-security@tis.com In-Reply-To: ; from "Donald E. Eastlake 3rd" at Nov 25, 96 3:26 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-dns-security@portal.ex.tis.com Precedence: bulk Donald; > There are a number of different ways to authenticate the non-existence of > names. If I recall correcly, your technique had, for a zone of any size, an > enormous pile of RRs with the zone name (or a smaller number of enourmous > RRs) which would have had to be indexed by some new technique to find the > right one to send back on a non-existent name query, your proposal had > nothing about and didn't consider wildcards, and I also don't recall how your > proposal handled non-existent types for existing, if at all. But maybe I > don't remember correctly. Maybe your prospal didn't have any of these > problems. >From the day one of my proposal, all the problems you mentioned was solved explicitely. See the following text: ZL (Zone List) data used to store sorted list of all the nodes in a zone. The information is necessary for protection against denial of service attacks, that is, if a node does not appear in certain ZLs, a negative response that a queried node does not exist is authenticated. The simplest way to authenticate negative answer that some data does not exist is to have an authenticated list of all the existing data. But, unless the number of existing data is expected to be small, as in the case with [RRD], listing up is inefficient. Especially, for a very large zone such as "com.", the size of the list is impractically large. So, existing data are sorted in a certain order and segmented appropriately into multiple ZL records. To authenticate the non-existence of a node, only a ZL RR containing the node (according to the sorting order) needs to be returned. To not to cause UDP size overflow, ZL RRs are intended to be returned as a partial RR in the additional section of a negative answer with truncation bit set. To authenticate a partial ZL RR, it is necessary to attach authentication signatures to individual ZL RRs. With wildcarding, actual authentication is a little more complicated and is discussed in section 5.3: "Resolver Algorithm". > It doesn't seem very relavent unless the Proposed Standard turns > out to be a problem, does it? It's your problem that it was not very relavent. I explained the problem several times by e-mail. > As far as I can remember, the NXT proposal in my and Charlie Kaufman's draft > was original work and was not produced by modifying your proposal and Your opinion before looking at my proposal was that negative authentication was impossible. > However this also > doens't seem very relevant since you are credited for contributing and I > think it is part of the normal WG process for ideas to be combined. That's fine if the ideas were combined. Masataka Ohta From owner-dns-security Tue Nov 26 07:27:09 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA12785 for dns-security-outgoing; Tue, 26 Nov 1996 07:25:40 -0500 (EST) From: Masataka Ohta Message-Id: <199611260447.NAA06809@necom830.hpcl.titech.ac.jp> Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and To: dee@cybercash.com (Donald E. Eastlake 3rd) Date: Tue, 26 Nov 96 13:47:27 JST Cc: namedroppers@internic.net, dns-security@tis.com X-Mailer: ELM [version 2.3 PL11] Sender: owner-dns-security@ex.tis.com Precedence: bulk Donald; > > I'm afraid your attempt to persuade Donald will fail. > > > > Even if it had succeeded, there remains a problem that the > > glue information makes the packet size exceed 512 bytes. > > Under what circumstances? Say you are using 768 bit keys (the draft > recommends somewhat shorter ones) and retrieve NS from foo.com where the > answers are ns1.foo.com and ns2.foo.com with glue A records. My real quick > calculation of the answer size is 395 byte: 24 for the header, 32 each for > the two NSs, and, as additional info, 23 for each of the two As, 121 for the > zone KEY for the subzone and 140 for the SIG signing the KEY for the subzone. > (I ignored name compression.) The problem is that the delegation packets are already full of A and NS records. But, it actually, is not a problem becasue we don't need any signature in the delegation, which was the WG consensus. > > Cryptographically, glue informaiton in the parent zone gives > > no protection. > > I don't quite know what your are saying in the above sentence but, > indeed, the DNSSEC draft was modified from earlier versions to > specifically prohibit SIGs on NS and glue A records in a superzone at cut > points. What? SIGs? Draft-ietf-dnssec-secext-10.txt still insists that: 2.3.4 Special Considerations at Delegation Points In general, there must be a zone KEY RR for the subzone in the superzone and the copy signed in the superzone is controlling. which is wrong. The glue KEY RR is useless. The following text of mine should be helpful to understand this cryptographical issue: No NSIG records are provided for non-authoritative data for a zone such as referral information. Thus, if a name server is compromised or its IP address is used by an attacker, it is possible to implant false referral information to a resolver. Still, as child zones have its own information, ZSIG (Zone SIGnature) described later, to authenticate themselves, the attacked resolver can detect that the referral information is bogus. The result is no worse than a simple denial of service attack by compromising name servers of the parent zone. That is, it is not necessary nor meaningful to try to authenticate referral NSes or glue A records for child zones. Masataka Ohta From owner-dns-security Tue Nov 26 08:40:48 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA13234 for dns-security-outgoing; Tue, 26 Nov 1996 08:40:27 -0500 (EST) Date: Tue, 26 Nov 1996 08:43:34 -0500 (EST) From: Edward Lewis X-Sender: lewis@singsing.hq.tis.com To: Masataka Ohta cc: "Donald E. Eastlake 3rd" , namedroppers@internic.net, dns-security@tis.com Subject: RE: ZL's (was Re: DNSSEC and split ...) In-Reply-To: <199611260345.MAA06627@necom830.hpcl.titech.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk On Tue, 26 Nov 1996, Masataka Ohta wrote: > ZL (Zone List) ... > authenticated. The simplest way to authenticate negative answer > that some data does not exist is to have an authenticated list of > all the existing data. But, unless the number of existing data is ... > inefficient. Especially, for a very large zone such as "com.", > the size of the list is impractically large. So, existing data > are sorted in a certain order and segmented appropriately into > multiple ZL records. To authenticate the non-existence of a node, ... This is very, very similar to the NXT record. Not that I am implying any "stealing" of ideas is evident - I do not know the history, nor as an engineer care to dwell on any of the issues relating to that. ZL's - assuming this is a ZL RR which holds all of the names, and presumable RR sets, in a zone or a subset of a zone - seem isomorphic to NXT RRs. By explicitly stating what is present, what is not stated can be assumed to be non-existant. Both ZL's and NXT's require an ordering of the zone's domain names and a grouping of all domain names together (at least at some point in the signing process) - which is a performance bear. I've written the code to do this and it is a bear. (Bear => a very annoyingly large problem.) Note: the ZL would not necessarily require an ordering of all names in a zone if it always was kept whole. But, for .COM, this is not practical. If all the names were listed - and all RR set too - then a linear search is all that would be needed. But then looking for a non-existant .COM name would be akin to an AXFR of .COM. Fortunately, there are few unclaimed names in .COM anymore ;) - sorry couldn't resist. Note note: notice "linear search." Try that on .COM. However, there are three facets of the NXT RR which IMHO give it an advantage over what I see here about ZL's. First, performance. An NXT return only has to send one domain name and a bit field representing what is at the owner. A ZL of N names would then be N times (on average) as long. This sucks bandwidth and processing time at the resolver. Second, denial of service. NXT's make denying access harder. An interloper would have to record more NXT's than ZL's to cover a zone to deny the existence of names and RR sets added later and/or added/deleted via (dynamic) updates. Third, generation. An NXT can be created as soon as I know, for a domain name, all of it's RR's, the signers for the RR's, the delegation points in the zone, and the next name in the zone. For a ZL, I would need to retain multiple copies of this until I fill the ZL. In other words, as I make my final run down a sorted zone I can see a domain name, process it and make the NXT and move on. With ZL's I need to hold a bunch more stuff in memory. Again the term "bear of a problem" comes to mind. The only ways I can see to improve on the concept of the NXTs is to either create a dynamically signed "no, (fill in blank) doesn't exist" response, defend against replay attacks, and/or add revokation of RR's to DNS. The first two are more or less could be covered by transaction signatures, the latter ain't gonna happen (easily). -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: 301-854-5794 Email: lewis@tis.com From owner-dns-security Tue Nov 26 08:56:24 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA13378 for dns-security-outgoing; Tue, 26 Nov 1996 08:56:22 -0500 (EST) Date: Tue, 26 Nov 1996 08:59:13 -0500 (EST) From: Edward Lewis X-Sender: lewis@singsing.hq.tis.com To: Masataka Ohta cc: "Donald E. Eastlake 3rd" , namedroppers@internic.net, dns-security@tis.com Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and In-Reply-To: <199611260447.NAA06809@necom830.hpcl.titech.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk On Tue, 26 Nov 1996, Masataka Ohta wrote: > What? SIGs? Draft-ietf-dnssec-secext-10.txt still insists that: > > 2.3.4 Special Considerations at Delegation Points > > In general, there must be a zone KEY RR for the subzone in the > superzone and the copy signed in the superzone is controlling. > > which is wrong. The glue KEY RR is useless. Not exactly useless - having information is never useless. IMHO - and this is a very subtle point - is that the presence of the KEY RR is not as security significant as the SIG RR that signs the KEY, which is signed by the "superzone." I am not supporting an effort to chsnge that text, but in reality, it's the signature of the key that is more significant. (There's always that issue in the wings: what happens when a delgating zone is not secured by a zone key, but the delgated zone is? No need to get into that now, it's just in the back of my mind...maybe that issue will go away.) > > The following text of mine should be helpful to understand this > cryptographical issue: > > No NSIG records are provided for non-authoritative data for a zone > such as referral information. Thus, if a name server is > compromised or its IP address is used by an attacker, it is > possible to implant false referral information to a resolver. (What are NSIG's? SIGs over NS RRs?) If the delegated zone is secure, then there will be a signed (by delegating zone) key present for the delegated zone. A false NS record could lead to a denial of service *but* the resolver would be able to detect that the attack was happening because there would be no verifyable signature for the false NS record - unless the signature was forged due to a compromise of the zone key (delegator or delgatee). Being able to avoid denial of service is not a reasonable expectation - being able to detect and respond to them is. The resolver can become suspicious, possibly resulting in an out of band call to the human running the zone under attack... > Still, as child zones have its own information, ZSIG (Zone > SIGnature) described later, to authenticate themselves, the > attacked resolver can detect that the referral information is > bogus. The result is no worse than a simple denial of service > attack by compromising name servers of the parent zone. That is, > it is not necessary nor meaningful to try to authenticate referral > NSes or glue A records for child zones. I'm sorry, I guess I don't understand your point. Are you arguing for or against signing delegation point records? You're last two paragraphs seem to contradict each other. I don't think it's the resolver that's under attack, but the zone... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: 301-854-5794 Email: lewis@tis.com From owner-dns-security Tue Nov 26 09:08:28 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA13433 for dns-security-outgoing; Tue, 26 Nov 1996 09:08:22 -0500 (EST) Date: Tue, 26 Nov 1996 09:07:44 -0500 (EST) From: "Donald E. Eastlake 3rd" To: dns-security@tis.com Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and In-Reply-To: <199611260345.MAA06627@necom830.hpcl.titech.ac.jp> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk Masataka, Your description is about as I remember it, a huge pile of stuff all under the zone name. How do you authenticate the non-existence of a type at an existing name under your scheme? Donald On Tue, 26 Nov 1996, Masataka Ohta wrote: > Date: Tue, 26 Nov 96 12:45:02 JST > From: Masataka Ohta > To: "Donald E. Eastlake 3rd" > Cc: namedroppers@internic.net, dns-security@tis.com > Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and > > "Donald E. Eastlake 3rd" at Nov 25, 96 3:26 pm > X-Mailer: ELM [version 2.3 PL11] > Sender: owner-dns-security@portal.ex.tis.com > Precedence: bulk > > Donald; > > > There are a number of different ways to authenticate the non-existence of > > names. If I recall correcly, your technique had, for a zone of any size, an > > enormous pile of RRs with the zone name (or a smaller number of enourmous > > RRs) which would have had to be indexed by some new technique to find the > > right one to send back on a non-existent name query, your proposal had > > nothing about and didn't consider wildcards, and I also don't recall how your > > proposal handled non-existent types for existing, if at all. But maybe I > > don't remember correctly. Maybe your prospal didn't have any of these > > problems. > > >From the day one of my proposal, all the problems you mentioned was > solved explicitely. > > See the following text: > > ZL (Zone List) > > data used to store sorted list of all the nodes in a zone. The > information is necessary for protection against denial of service > attacks, that is, if a node does not appear in certain ZLs, a > negative response that a queried node does not exist is > authenticated. The simplest way to authenticate negative answer > that some data does not exist is to have an authenticated list of > all the existing data. But, unless the number of existing data is > expected to be small, as in the case with [RRD], listing up is > inefficient. Especially, for a very large zone such as "com.", > the size of the list is impractically large. So, existing data > are sorted in a certain order and segmented appropriately into > multiple ZL records. To authenticate the non-existence of a node, > only a ZL RR containing the node (according to the sorting order) > needs to be returned. To not to cause UDP size overflow, ZL RRs > are intended to be returned as a partial RR in the additional > section of a negative answer with truncation bit set. To > authenticate a partial ZL RR, it is necessary to attach > authentication signatures to individual ZL RRs. With wildcarding, > actual authentication is a little more complicated and is > discussed in section 5.3: "Resolver Algorithm". > > ... > > Masataka Ohta ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html From owner-dns-security Tue Nov 26 09:55:14 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA13653 for dns-security-outgoing; Tue, 26 Nov 1996 09:54:27 -0500 (EST) From: Masataka Ohta Message-Id: <199611261446.XAA08136@necom830.hpcl.titech.ac.jp> Subject: RE: ZL's (was Re: DNSSEC and split ...) To: lewis@tis.com (Edward Lewis) Date: Tue, 26 Nov 96 23:46:41 JST Cc: mohta@necom830.hpcl.titech.ac.jp, dee@cybercash.com, namedroppers@internic.net, dns-security@tis.com In-Reply-To: ; X-Mailer: ELM [version 2.3 PL11] Sender: owner-dns-security@ex.tis.com Precedence: bulk Edward; > This is very, very similar to the NXT record. Not that I am implying > any "stealing" of ideas is evident - It's OK to copy my idea. Note also that, as far as I know, the idea is NOT patent protected. > I do not know the history, nor > as an engineer care to dwell on any of the issues relating to that. The history is that, I explained by e-mail how to authenticate the non-existence of domains expecting to be picked up by Donald. I, also, continueously explained why Donald's draft is unnecessarily incomatible to the DNS architecture. But, nothing were reflected. So, I wrote my own. > By explicitly stating what is present, what is not stated can be > assumed to be non-existant. Both ZL's and NXT's require an ordering > of the zone's domain names Of course. > and a grouping of all domain names together > (at least at some point in the signing process) - which is a performance > bear. I've written the code to do this and it is a bear. I can't understand your point here. Each ZL RR's are signed separately. With B-tree like splitting and merging, deletions and additions of nodes can be done with a few ZL RRs near the node locally without affecting the rest of the ZL RRs. > Note note: notice "linear search." Try that on .COM. That's why ZL RRs are sorted to be useful for binary serach. > However, there are three facets of the NXT RR which IMHO give it an > advantage over what I see here about ZL's. I'm afraid you misunderstand the Internet. > First, performance. An NXT return only has to send one domain name and > a bit field representing what is at the owner. A ZL of N names would then > be N times (on average) as long. This sucks bandwidth and processing > time at the resolver. What? You can always make N 1. The reason why N can be larger than 1 is for better performance than NXT. As DNS RR headers are *LENGTHY*, it is inefficient for nameservers to have non-existence authentication separately for each node. This sucks memory of name servers and bandwidth and processing time for zone transfer. And, for usual transfer, it's a single UDP packet with less than 512 bytes of size with A LOT OF header overhead. As you know, on the Internet, it does not matter so much whether a packet is 200 byte long or 300. Moreover, a single ZL can be negatively cached to reduce bandwidth and processing power consumption. Thus, it is, IMO, beneficial to not to make N 1. You may disagree to set N 1. > Second, denial of service. NXT's make denying access harder. An > interloper would have to record more NXT's than ZL's to cover a zone > to deny the existence of names and RR sets added later and/or > added/deleted via (dynamic) updates. First, see above. You can always make N 1 if you don't mind performance loss. Second, ZL does not protect RR sets. There is separate mechanism for it. Third, it is unlikely that the interloper want to attack the zone as a whole. A single NXT or ZL RR is enough to fake that a target domain name does not exist. Forth, if you do want to attack a zone as a whole, you can collect as much NXT or ZL as you want by making simple queries on the zone about non-existent names. Fifth, the semantics of DNS, including secure DNS, is that the users must accept a fact that it may receive data with older versions. > Third, generation. An NXT can be created as soon as I know, for a domain > name, all of it's RR's, the signers for the RR's, the delegation points > in the zone, and the next name in the zone. Really? ZL needs a domain name only and is better, then. > For a ZL, I would need to retain > multiple copies of this until I fill the ZL. What is "this"? What do you mean "until I fill"? > In other words, as I make > my final run down a sorted zone I can see a domain name, process it and > make the NXT and move on. What is the "my final run"? If you think you must sign NXT as a whole, it is a problem of NXT. > With ZL's I need to hold a bunch more stuff > in memory. With ZL, I need to hold an existing domain names only. And, B-tree (or B+ or whatever) like algorithm is always applicable for local modification. > Again the term "bear of a problem" comes to mind. So, NXT has the "bear of a problem". > The only ways I can see to improve on the concept of the NXTs is to > either create a dynamically signed "no, (fill in blank) doesn't exist" > response, defend against replay attacks, No. Secondary servers won't know the secret keys. > and/or add revokation of RR's > to DNS. ZL and revokation of RR's is unrelated. Revocation of domain names is what I was thinking to add as a possible improvement but dropped. > The first two are more or less could be covered by transaction > signatures, No, it isn't covered. Nameservers are unreliable. > the latter ain't gonna happen (easily). It's easy. But, it's expensive, which is why I didn't make it included. Masataka Ohta From owner-dns-security Tue Nov 26 10:19:15 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA13842 for dns-security-outgoing; Tue, 26 Nov 1996 10:19:04 -0500 (EST) Date: Tue, 26 Nov 1996 10:22:03 -0500 (EST) From: Edward Lewis X-Sender: lewis@singsing.hq.tis.com To: Masataka Ohta cc: mohta@necom830.hpcl.titech.ac.jp, dee@cybercash.com, namedroppers@internic.net, dns-security@tis.com Subject: RE: ZL's (was Re: DNSSEC and split ...) In-Reply-To: <199611261446.XAA08136@necom830.hpcl.titech.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk On Tue, 26 Nov 1996, Masataka Ohta wrote: > I'm afraid you misunderstand the Internet. ;) I'm afraid I don't understand ZL's. Perhaps I misinterpreted your description. How about trying this to clear things up for me. Please, show me the (textual version of the) zone after ZL's are added for the following two zones. Please include whatever mechanism you propose to cover the RR sets for a given existing name. $ORIGIN zone. $SIGNER zone. @ SOA (SOA stuff) NS (NS stuff) KEY (KEY stuff) d NS (NS sutff) MX (MX stuff) KEY (KEY stuff) b MX (MX stuff) c TXT (TXT stuff) MX (MX stuff) a A (A stuff) e A (A stuff) a A (A stuff) ; yes, twice b A (A stuff) ;end and $ORIGIN d.zone. $SIGNER d.zone. @ SOA (SOA stuff) NS (NS stuff) NS (NS stuff) KEY (KEY stuff) x TXT (TXT stuff) w A (A stuff) y A (A stuff) ;end Nothing tricky about this example, I just want to see the simple version of your concept in plain ol' ISO-8859-1. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: 301-854-5794 Email: lewis@tis.com From owner-dns-security Tue Nov 26 10:40:14 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA13943 for dns-security-outgoing; Tue, 26 Nov 1996 10:40:10 -0500 (EST) Message-Id: <9611261541.AA15251@sol.hq.tis.com> To: Paul Wren Cc: ogud@tis.com, namedroppers@internic.net, dns-security@tis.com Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and draft-ietf-dnsind-clarify-02.txt) In-Reply-To: Your message of "Mon, 25 Nov 1996 14:26:41 PST." <2.2.32.19961125222641.01677670@pop-sb.software.com> Date: Tue, 26 Nov 1996 10:41:33 -0500 From: Olafur Gudmundsson Sender: owner-dns-security@ex.tis.com Precedence: bulk Paul Wren writes: > As the developer of a ground-up rewrite of a DNS server from the RFC's, I do > find it worrisome that a number of very complex issues are arising that were > definitely not apparent on a first, second, or third reading (for me) of the > DNSSEC draft. Since it is a "proposed standard" document, that is > problematic. And while Ohta is classically a trouble-maker, there are some > level-headed comments as well that seem to be an issue. I agree that there are issues that are not clear in the draft, but please understand the following: 1. This is the first time people are actualy securing a distributed database which has distributed authority (on the scale of DNS) 2. Donald and Charlie are writing the specs in their spare time. 3. Number of people have (including myself) have contributed many suggestions to the authors on how to make the document better, but it is not perfect. 4. DNS operating practice is different from the RFC's, see current ID's on dns-clarify, dns-names 5. DNS specs (1034, 1035) are not clear on many points, 6. DNS is being enhanced (dynamic update) and that design makes it harder to design security model. (we are close to one). 7. Not enough people have come forward with constructive suggestions, but there has been plenty of mud thrown around. 8. Unfortunately, in the realm of TCP/IP and the internet, rigid compliance with written documentation is rare. If you were to implement TCP rigidly, you would not be interoperable with many current versions (including commercial ones). This is an artifact of the open process and "rough consensus." It's not perfect, but it ordinarily "gets the job done." I expect that interoperabilty tests will point out number of things that need to be specified better, these changes will be incorporated before DNSSEC goes to full standard. Also, as we progress we may discover better ways to certain things. Please continue to forward your questions/comments to dns-security@tis.com. Olafur From owner-dns-security Tue Nov 26 11:11:53 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA14155 for dns-security-outgoing; Tue, 26 Nov 1996 11:11:33 -0500 (EST) From: Masataka Ohta Message-Id: <199611261605.BAA08436@necom830.hpcl.titech.ac.jp> Subject: RE: ZL's (was Re: DNSSEC and split ...) To: lewis@tis.com (Edward Lewis) Date: Wed, 27 Nov 96 1:05:33 JST Cc: mohta@necom830.hpcl.titech.ac.jp, dee@cybercash.com, namedroppers@internic.net, dns-security@tis.com In-Reply-To: ; X-Mailer: ELM [version 2.3 PL11] Sender: owner-dns-security@ex.tis.com Precedence: bulk Edward; > On Tue, 26 Nov 1996, Masataka Ohta wrote: > > I'm afraid you misunderstand the Internet. > > ;) > > I'm afraid I don't understand ZL's. Perhaps I misinterpreted > your description. > > How about trying this to clear things up for me. Please, show > me the (textual version of the) zone after ZL's are added for > the following two zones. The generic form is: ZL ... For the first zone, it can be: zone. ZL zone. zone. 6 zone. a.zone. b.zone. c.zone. d.zone. e.zone. or it can be: zone. ZL zone. ab.zone. 2 zone. a.zone. zone. ZL ab.zone. d.zone. 2 b.zone. c.zone. zone. ZL d.zone. zone. 2 d.zone. e.zone. For the second zone, it can be: zone. ZL zone. zone. 4 zone. w.zone. x.zone. y.zone. > Please include whatever mechanism > you propose to cover the RR sets for a given existing name. While it possible, the result is boring. If you insist that I should, could you please do it with NXT first? First, let me explain in English. > a A (A stuff) > e A (A stuff) > a A (A stuff) ; yes, twice No problem. Each node (NOT including referral one) has (MD5?) digest of all RRs of the node, which then, is signed. For details, see the attached text on RRD. BTW, I'll ask Cynthia to publish my expired Internet Draft again. The name of the draft was: and will be If you want to see it immediately, feel free to ask me privately. Masataka Ohta RRD (RR Digest) Digest value of all the data with a certain RR type in a secure node. [RRD] RRs have the following syntax ( and are omitted throughout the document): [RRD] where [RRD] is the RR name of RRD, is the digest of all the resource records of type of node . is the original TTL value of the records. is a 16 bit quantity, is a 32 bit quantity, is of variable length. When computing , records are represented in binary form in DNS packet without domain name compression. If there are multiple records of the same , they are sorted with dictionary order, comparing the first bytes first with unsigned arithmetic. When verifying the digest of received data in resolvers and name servers, TTL field of the records, which should be decreased already, should be replaced with (original TTL). When caching authenticated data, name servers and resolvers should confirm that the TTL in the answer packet does not exceed the value in RRD data. A node, in general, has multiple [RRD] record for each RR type the node has. But, it is impossible and unnecessary to cover s of [RRD] [NSIG] and [ZSIG]. Still, it is necessary to have [RRD] of such s as protection against denial service attacks, that is, to authenticate negative response of non existing RR types. An [RRD] record for [NSIG] or [ZSIG] RR has the field of length zero. To compute of [RRD] RR type itself, the field of the record itself is first considered to have zero length (including length field of the record) and later replaced with the actual digest length and value. From owner-dns-security Tue Nov 26 11:55:28 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA14378 for dns-security-outgoing; Tue, 26 Nov 1996 11:55:11 -0500 (EST) Date: Tue, 26 Nov 1996 11:57:57 -0500 (EST) From: Edward Lewis X-Sender: lewis@singsing.hq.tis.com To: Masataka Ohta cc: mohta@necom830.hpcl.titech.ac.jp, dee@cybercash.com, namedroppers@internic.net, dns-security@tis.com Subject: RE: ZL's (was Re: DNSSEC and split ...) In-Reply-To: <199611261605.BAA08436@necom830.hpcl.titech.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk On Wed, 27 Nov 1996, Masataka Ohta wrote: > While it possible, the result is boring. If you insist that I > should, could you please do it with NXT first? I would like to see the whole "boring" result, but fair enough, here is my version of the examples after running through a signer. NOTE: this is hand generated. I hope there are no typo-level mistakes. (Why didn't I use my signer app you ask. It's kinda stalled awaiting ironing out some issues with the algorithm.) Here's the example: $ORIGIN zone. $SIGNER zone. @ SOA (SOA stuff) NS (NS stuff) KEY (KEY stuff) d NS (NS stuff) MX (MX stuff) KEY (KEY stuff) b MX (MX stuff) c TXT (TXT stuff) MX (MX stuff) a A (A stuff) e A (A stuff) a A (A stuff) ; yes, twice b A (A stuff) ;end and $ORIGIN d.zone. $SIGNER d.zone. @ SOA (SOA stuff) NS (NS stuff) NS (NS stuff) KEY (KEY stuff) x TXT (TXT stuff) w A (A stuff) y A (A stuff) ;end Here's the result: $SIGNER zone. zone. SOA (SOA stuff) zone. SIG (SOA & stuff) zone. SIG (AXFR & stuff) zone. NS (NS stuff) zone. SIG (NS & stuff) zone. KEY (KEY stuff) zone. SIG (KEY & stuff) zone. NXT a.zone. SOA NS KEY SIG NXT zone. SIG (NXT & stuff) a.zone. A (A stuff) a.zone. A (A stuff) ; yes, twice a.zone. SIG (A & stuff) a.zone. NXT b.zone. A SIG NXT a.zone. SIG (NXT & stuff) b.zone. A (A stuff) b.zone. SIG (A & stuff) b.zone. MX (MX stuff) b.zone. SIG (MX & stuff) b.zone. NXT c.zone. A MX SIG NXT b.zone. SIG (NXT & stuff) c.zone. TXT (TXT stuff) c.zone. SIG (TXT & stuff) c.zone. MX (MX stuff) c.zone. SIG (MX & stuff) c.zone. NXT d.zone. MX TXT SIG NXT c.zone. SIG (NXT & stuff) d.zone. NS (NS stuff) d.zone. MX (MX stuff) ; misplaced d.zone. KEY (KEY stuff) d.zone. SIG (KEY & stuff) d.zone. NXT zone. NS MX KEY SIG NXT ; MX is debateable (*) d.zone. SIG (NXT & stuff) ; end and d.zone. SOA (SOA stuff) d.zone. SIG (SOA & stuff) d.zone. SIG (AXFR & stuff) d.zone. NS (NS stuff) d.zone. NS (NS stuff) d.zone. SIG (NS & stuff) d.zone. KEY (KEY stuff) d.zone. SIG (KEY & stuff) d.zone. NXT a.zone. SOA NS KEY SIG NXT d.zone. SIG (NXT & stuff) x.d.zone. TXT (TXT stuff) x.d.zone. SIG (TXT & stuff) x.d.zone. NXT y.d.zone. TXT SIG NXT x.d.zone. SIG (NXT & stuff) y.d.zone. A (A stuff) y.d.zone. SIG (A & stuff) y.d.zone. NXT z.d.zone. A SIG NXT y.d.zone. SIG (NXT & stuff) z.d.zone. A (A stuff) z.d.zone. SIG (A & stuff) z.d.zone. NXT d.zone. A SIG NXT z.d.zone. SIG (NXT & stuff) ; end (*) The only debateable item here is whether the MX record for d.zone. should be in the zone.'s NXT record. The spec says yes, I'm examining that for the case listed - i.e., the MX record only appears where it is glue, and not in the authoritative version. Note: the NXT record for d.zone. two versions, one in each zone. This was mentioned in my first response to this thread. I'd like to see the complete example using ZL's and RRD's and whatever else is proposed. I have trouble understanding your prose (yeah, a fault of mine), and would be able to gain a better understanding if I saw the example worked out to completion. (After all, if a simple case can't be worked out by hand, writing the code is going to be impossible!) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: 301-854-5794 Email: lewis@tis.com From owner-dns-security Tue Nov 26 14:30:52 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA14836 for dns-security-outgoing; Tue, 26 Nov 1996 14:30:32 -0500 (EST) Date: Tue, 26 Nov 1996 14:30:00 -0500 (EST) From: "Donald E. Eastlake 3rd" To: namedroppers@internic.net, dns-security@tis.com Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and In-Reply-To: <199611260447.NAA06809@necom830.hpcl.titech.ac.jp> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk On Tue, 26 Nov 1996, Masataka Ohta wrote: > Date: Tue, 26 Nov 96 13:47:27 JST > From: Masataka Ohta > To: "Donald E. Eastlake 3rd" > Cc: namedroppers@internic.net, dns-security@tis.com > Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and > > Donald; > > > > I'm afraid your attempt to persuade Donald will fail. > > > > > > Even if it had succeeded, there remains a problem that the > > > glue information makes the packet size exceed 512 bytes. > > > > Under what circumstances? Say you are using 768 bit keys (the draft > > recommends somewhat shorter ones) and retrieve NS from foo.com where the > > answers are ns1.foo.com and ns2.foo.com with glue A records. My real quick > > calculation of the answer size is 395 byte: 24 for the header, 32 each for > > the two NSs, and, as additional info, 23 for each of the two As, 121 for the > > zone KEY for the subzone and 140 for the SIG signing the KEY for the subzone. > > (I ignored name compression.) > > The problem is that the delegation packets are already full of > A and NS records. The rules are set up so that if the KEY/SIG don't fit in the additional info section, they are dropped and you can get them with a separate retrieval. They are given lower priority than the glue A records for inclusion as additional info. > But, it actually, is not a problem becasue we don't need any signature > in the delegation, which was the WG consensus. The working group consensus, which is embodied in the Proposed Standard, was to drop signatures on the NS and A records in the superzone. There is at least one case that absolutely requires signed information about the subzone in the superzone. Assume some subzone that is insecure and which not been modifed to include any security related info. There will clearly be many of these for some time to come. Obviously RRs from such zones can be forged, since they are not signed. If you depend on queries to the subzone to tell if it is secure, anyone can forge an insecure subzone even though the real subzone is secure. So this information that the subzone is insecure must be in the secure superzone. In the Proposed Standard, this is encoded into the KEY RR. > > > Cryptographically, glue informaiton in the parent zone gives > > > no protection. > > > > I don't quite know what your are saying in the above sentence but, > > indeed, the DNSSEC draft was modified from earlier versions to > > specifically prohibit SIGs on NS and glue A records in a superzone at cut > > points. > > What? SIGs? Draft-ietf-dnssec-secext-10.txt still insists that: Why are you saying "What?"? SIGs on NS and glue A RRs in the superzone are specifically prohibited in the Proposed Standard. SIGs on KEY and NXT are not affected by prohibiting them on NS and glue A RRs. > 2.3.4 Special Considerations at Delegation Points > > In general, there must be a zone KEY RR for the subzone in the > superzone and the copy signed in the superzone is controlling. > > which is wrong. The glue KEY RR is useless. See above. To securely permit the case of an insecure unmodified subzone, something that I think we have to allow for some time, the KEY RR in the superzone that securely states that the subzone is insecure is essential. > The following text of mine should be helpful to understand this > cryptographical issue: > > No NSIG records are provided for non-authoritative data for a zone > such as referral information. Thus, if a name server is > compromised or its IP address is used by an attacker, it is > possible to implant false referral information to a resolver. > > Still, as child zones have its own information, ZSIG (Zone > SIGnature) described later, to authenticate themselves, the > attacked resolver can detect that the referral information is > bogus. The result is no worse than a simple denial of service > attack by compromising name servers of the parent zone. That is, > it is not necessary nor meaningful to try to authenticate referral > NSes or glue A records for child zones. That's fine for NS and glue A. But the key information for a secure subzone must be signed by the superzone and the fact that an insecure subzone is insecure must be not only signed by the superzone but must also be present in the superzone, at least during the substantial transition period when there are many insecure umodified zones. > Masataka Ohta Donald ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html From owner-dns-security Tue Nov 26 17:56:52 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA15256 for dns-security-outgoing; Tue, 26 Nov 1996 17:55:34 -0500 (EST) From: Masataka Ohta Message-Id: <199611262254.HAA09553@necom830.hpcl.titech.ac.jp> Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and To: dee@cybercash.com (Donald E. Eastlake 3rd) Date: Wed, 27 Nov 96 7:54:15 JST Cc: namedroppers@internic.net, dns-security@tis.com In-Reply-To: ; from "Donald E. Eastlake 3rd" at Nov 26, 96 2:30 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-dns-security@ex.tis.com Precedence: bulk Donald; > > The problem is that the delegation packets are already full of > > A and NS records. > > The rules are set up so that if the KEY/SIG don't fit in the additional info > section, they are dropped and you can get them with a separate retrieval. While you are wrong in several points, first of all, there is no such separate retrieval possible. Masataka Ohta From owner-dns-security Tue Nov 26 18:14:42 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA15292 for dns-security-outgoing; Tue, 26 Nov 1996 18:14:40 -0500 (EST) From: Masataka Ohta Message-Id: <199611262311.IAA09616@necom830.hpcl.titech.ac.jp> Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and To: lewis@tis.com (Edward Lewis) Date: Wed, 27 Nov 96 8:11:42 JST Cc: mohta@necom830.hpcl.titech.ac.jp, dee@cybercash.com, namedroppers@internic.net, dns-security@tis.com In-Reply-To: ; from "Edward Lewis" at Nov 26, 96 8:59 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-dns-security@ex.tis.com Precedence: bulk > > In general, there must be a zone KEY RR for the subzone in the > > superzone and the copy signed in the superzone is controlling. > > > > which is wrong. The glue KEY RR is useless. > > Not exactly useless - having information is never useless. Having informationless bunch of bytes is harmful. > > IMHO - and this is a very subtle point - is that the presence of the KEY > RR is not as security significant as the SIG RR that signs the KEY, which > is signed by the "superzone." Neither KEY nor SIG are necessary. > (What are NSIG's? SIGs over NS RRs?) Node SIGs. > Being able to avoid denial of service is not a reasonable expectation - being > able to detect and respond to them is. The resolver can become suspicious, > possibly resulting in an out of band call to the human running the zone > under attack... That's why neither KEY nor SIG are necessary. > > Still, as child zones have its own information, ZSIG (Zone > > SIGnature) described later, to authenticate themselves, the > > attacked resolver can detect that the referral information is > > bogus. The result is no worse than a simple denial of service > > attack by compromising name servers of the parent zone. That is, > > it is not necessary nor meaningful to try to authenticate referral > > NSes or glue A records for child zones. > > I'm sorry, I guess I don't understand your point. Are you arguing for or > against signing delegation point records? Against, of course. > You're last two paragraphs seem > to contradict each other. The forgery of glue is only as harmful as the no referral response. In both case, we can't reach the child zone. Masataka Ohta From owner-dns-security Tue Nov 26 18:41:17 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA15332 for dns-security-outgoing; Tue, 26 Nov 1996 18:41:05 -0500 (EST) From: Masataka Ohta Message-Id: <199611262342.IAA09749@necom830.hpcl.titech.ac.jp> Subject: RE: ZL's (was Re: DNSSEC and split ...) To: lewis@tis.com (Edward Lewis) Date: Wed, 27 Nov 96 8:41:47 JST Cc: mohta@necom830.hpcl.titech.ac.jp, dee@cybercash.com, namedroppers@internic.net, dns-security@tis.com In-Reply-To: ; from "Edward Lewis" at Nov 26, 96 11:57 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-dns-security@ex.tis.com Precedence: bulk > > While it possible, the result is boring. If you insist that I > > should, could you please do it with NXT first? I'm sorry but I found it impossible becasue your first example is invalid. > $ORIGIN zone. > $SIGNER zone. > @ SOA (SOA stuff) > NS (NS stuff) > KEY (KEY stuff) > d NS (NS stuff) > MX (MX stuff) > KEY (KEY stuff) The referral point "d", can not have MX. > (*) The only debateable item here is whether the MX record > for d.zone. should be in the zone.'s NXT record. There is no debatable item. Your example is simply wrong. The second one is: $ORIGIN d.zone. @ SOA (SOA stuff) NS (NS stuff) NS (NS stuff) x TXT (TXT stuff) w A (A stuff) y A (A stuff) $ORIGIN d.zone. @ SOA (SOA stuff) NS (NS stuff) NS (NS stuff) ZA (Zone Key) ZSIG(Signature by Parent) NSIG(Signature by d.zone.) RRD (SOA) RRD (NS) RRD (ZA) RRD (ZSIG) RRD (NSIG) RRD (RRD) ZL (ZL stuff) x TXT (TXT stuff) NSIG(Signature by d.zone.) RRD (TXT) RRD (RRD) w A (A stuff) NSIG(Signature by d.zone.) RRD (A) RRD (RRD) y A (A stuff) NSIG(Signature by d.zone.) RRD (A) RRD (RRD) Masataka Ohta From owner-dns-security Tue Nov 26 19:03:10 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA15366 for dns-security-outgoing; Tue, 26 Nov 1996 19:02:35 -0500 (EST) Date: Tue, 26 Nov 1996 19:05:44 -0500 (EST) From: Edward Lewis X-Sender: lewis@singsing.hq.tis.com To: Masataka Ohta cc: mohta@necom830.hpcl.titech.ac.jp, dee@cybercash.com, namedroppers@internic.net, dns-security@tis.com Subject: RE: ZL's (was Re: DNSSEC and split ...) In-Reply-To: <199611262342.IAA09749@necom830.hpcl.titech.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk On Wed, 27 Nov 1996, Masataka Ohta wrote: > > > While it possible, the result is boring. If you insist that I > > > should, could you please do it with NXT first? > > I'm sorry but I found it impossible becasue your first > example is invalid. > > > d NS (NS stuff) > > MX (MX stuff) > > KEY (KEY stuff) > > The referral point "d", can not have MX. Then omit the offending record and show me how your proposal works. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: 301-854-5794 Email: lewis@tis.com From owner-dns-security Wed Nov 27 07:32:05 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA16043 for dns-security-outgoing; Wed, 27 Nov 1996 07:30:57 -0500 (EST) Date: Wed, 27 Nov 1996 07:33:50 -0500 (EST) From: Edward Lewis X-Sender: lewis@singsing.hq.tis.com To: Masataka Ohta cc: mohta@necom830.hpcl.titech.ac.jp, dee@cybercash.com, namedroppers@internic.net, dns-security@tis.com Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and In-Reply-To: <199611262311.IAA09616@necom830.hpcl.titech.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk On Wed, 27 Nov 1996, Masataka Ohta wrote: > Having informationless bunch of bytes is harmful. Please go on. I don't think the correct A record for a/the nameserver of a delegation point is neither information-less, nor is having correct information harmful. > Neither KEY nor SIG are necessary. ... > That's why neither KEY nor SIG are necessary. Please explain. > In both case, we can't reach the child zone. How do you propose to fix this? The problem of lame delegations is a problem for all of DNS. DNSSEC cannot solve this problem, this is a problem larger than the scope of the DNS work. There are five threats to DNS operations even with DNSSEC. (I'm considering the concept here, not any implementation - bugs in which would probably cause more vulerabilities.) 1) the signature of the zone adminisitrator is forged This is not a problem for DNSSEC to solve. This is a problem for the crypto algorithm and the site policies on handling the keys. 2) the data entered by the zone admins up to the root is incorrect Human error cannot be completely removed, although it can be lessened through sanity checks. 3) the out-of-band coordination is not secured The passing of the unsigned zone key between zone administrators is an operations policy issue. Delegations themselves should only occur between consenting administrators. 4) the name servers are compromised via non-DNS means This is host security, and is addressed by at least one other draft (DNS server requirements). 5) data is retired prior to the expiration of the last TTL This is in the nature of DNS. DNSSEC could require all TTLs be set to 0, but that is unacceptable for performance reasons. Adding an expiration time to older RR's would end backwards compatibility. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: 301-854-5794 Email: lewis@tis.com From owner-dns-security Wed Nov 27 08:52:39 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA16552 for dns-security-outgoing; Wed, 27 Nov 1996 08:51:56 -0500 (EST) Date: Wed, 27 Nov 1996 08:54:55 -0500 (EST) From: Edward Lewis X-Sender: lewis@singsing.hq.tis.com To: Masataka Ohta cc: mohta@necom830.hpcl.titech.ac.jp, dee@cybercash.com, namedroppers@internic.net, dns-security@tis.com Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and In-Reply-To: <199611271328.WAA12110@necom830.hpcl.titech.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk I'm terribly confused. Are you typing "adding security to DNS is useless?" based on the lame delegation dilemma? Or are you saying that only a simple appraoch to DNSSEC should be persued? If that is so, why are you participating in this list? Why do you have an "alternative" proposal? (Which I still don't understand - the [completed] example will be a big help to me.) On the contrary... If you believe that adding security to DNS is useful, then how do you propose to signify a delegation of signing authority? Make it implicit in the delegation NS record? If so, are you implying that there shall be just one signer for each zone? Please help me understand your position. I know that there is some personal conflict here and my asking questions may seem like an arguement, but I am merely curious about your proposal. I appologize for having difficulty understanding your writing. It is unfortunate that I have not learned Japanese. On Wed, 27 Nov 1996, Masataka Ohta wrote: > Edward; > > The problem of denial of service attack related to lame delegation > is unsolvable. > > That is, it's wrong to to make secure DNS complex, trying to solve > the problem. > Masataka Ohta -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: 301-854-5794 Email: lewis@tis.com From owner-dns-security Wed Nov 27 09:01:24 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA16635 for dns-security-outgoing; Wed, 27 Nov 1996 09:01:23 -0500 (EST) From: Masataka Ohta Message-Id: <199611271328.WAA12110@necom830.hpcl.titech.ac.jp> Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and To: lewis@tis.com (Edward Lewis) Date: Wed, 27 Nov 96 22:28:04 JST Cc: mohta@necom830.hpcl.titech.ac.jp, dee@cybercash.com, namedroppers@internic.net, dns-security@tis.com In-Reply-To: ; X-Mailer: ELM [version 2.3 PL11] Sender: owner-dns-security@ex.tis.com Precedence: bulk Edward; > The problem of lame delegations is a problem for all of DNS. > DNSSEC cannot solve this problem, this is a problem larger > than the scope of the DNS work. The problem of denial of service attack related to lame delegation is unsolvable. That is, it's wrong to to make secure DNS complex, trying to solve the problem. > > That's why neither KEY nor SIG are necessary. > > Please explain. See above. You explained by yourself. Masataka Ohta From owner-dns-security Wed Nov 27 09:05:37 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA16661 for dns-security-outgoing; Wed, 27 Nov 1996 09:05:35 -0500 (EST) From: Masataka Ohta Message-Id: <199611271406.XAA12222@necom830.hpcl.titech.ac.jp> Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and To: lewis@tis.com (Edward Lewis) Date: Wed, 27 Nov 96 23:05:56 JST Cc: mohta@necom830.hpcl.titech.ac.jp, dee@cybercash.com, namedroppers@internic.net, dns-security@tis.com In-Reply-To: ; from "Edward Lewis" at Nov 27, 96 8:54 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-dns-security@ex.tis.com Precedence: bulk Edward; > I'm terribly confused. You are. > Are you typing "adding security > to DNS is useless?" No. I typed: That is, it's wrong to to make secure DNS complex, trying to solve the problem. > Or are you saying that only a simple appraoch to DNSSEC > should be persued? As you can see. > Why do you have an "alternative" proposal? The title of my ID is "Simple Secure DNS". > If you believe that adding security to DNS is useful, then > how do you propose to signify a delegation of signing > authority? Hint: I never tried to solve the lame delegation dilemma. But, actually, I have already shown you the answer with ZA RR in child zone. So, why do you think you need additional boring example? Masataka Ohta From owner-dns-security Wed Nov 27 09:24:14 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA16714 for dns-security-outgoing; Wed, 27 Nov 1996 09:24:12 -0500 (EST) Date: Wed, 27 Nov 1996 09:27:01 -0500 (EST) From: Edward Lewis X-Sender: lewis@singsing.hq.tis.com To: Masataka Ohta cc: mohta@necom830.hpcl.titech.ac.jp, dee@cybercash.com, namedroppers@internic.net, dns-security@tis.com Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and In-Reply-To: <199611271406.XAA12222@necom830.hpcl.titech.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk On Wed, 27 Nov 1996, Masataka Ohta wrote: > > I'm terribly confused. > You are. If you understand that, then enlighten me. Insults get me nowhere. > As you can see. As I can see what? I am having trouble with your writing, I am verifying your comments so that I don't misinterpret you as I did when comparing your ZL to NXT's. > > Why do you have an "alternative" proposal? > The title of my ID is "Simple Secure DNS". I asked "why" not "what." And remember, I am new to this. I cannot find this ID. You've not given me any evidence that your approach is better or significantly different from the current approach. > Hint: I never tried to solve the lame delegation dilemma. > > But, actually, I have already shown you the answer with ZA RR > in child zone. There was no lame delegation in the example, just a loose MX record. Is that what you mean by a lame delegation? I interpret "lame delegation" as being an incorrect NS record. If your approach doesn't handle lame delgations, why did you critisize DNSSEC for not handling it? > So, why do you think you need additional boring example? I would like to see the whole answer so I can judge for myself. I would like to see how you handle the delegation point and the multiple RR's in a set. Besides, I took the time to show my completed response. Please be fair. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: 301-854-5794 Email: lewis@tis.com From owner-dns-security Sun Dec 1 15:51:19 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA20348 for dns-security-outgoing; Sun, 1 Dec 1996 15:47:30 -0500 (EST) Message-Id: Date: Sun, 1 Dec 96 12:49 PST From: randy@psg.com (Randy Bush) To: Olafur Gudmundsson Cc: Paul Wren , namedroppers@internic.net, dns-security@tis.com Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and draft-ietf-dnsind-clarify-02.txt) References: <2.2.32.19961125222641.01677670@pop-sb.software.com> <9611261541.AA15251@sol.hq.tis.com> Sender: owner-dns-security@ex.tis.com Precedence: bulk > Please continue to forward your questions/comments to dns-security@tis.com. Olafur, I think it is useful for interoperatability issues to be on dnsind and dnssec public wg lists. randy From owner-dns-security Tue Dec 3 07:24:38 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA23495 for dns-security-outgoing; Tue, 3 Dec 1996 07:21:25 -0500 (EST) Date: Mon, 2 Dec 1996 23:55:12 -0500 (EST) Message-Id: <199612030455.XAA02636@patty.cs.columbia.edu> From: "Maggie M. Lee" To: dns-security@tis.com Subject: secure dns Sender: owner-dns-security@ex.tis.com Precedence: bulk Hi, I heard that secure dns has been released. I checked tis' home page but couldn't find it. Would you mind telling me where I can find a copy please? Thanks. Maggie Lee From owner-dns-security Tue Dec 3 10:20:15 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA24095 for dns-security-outgoing; Tue, 3 Dec 1996 10:19:28 -0500 (EST) Date: Tue, 3 Dec 1996 10:18:50 -0500 (EST) From: "Donald E. Eastlake 3rd" To: "Maggie M. Lee" Cc: dns-security@tis.com Subject: Re: secure dns In-Reply-To: <199612030455.XAA02636@patty.cs.columbia.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk Try http://www.tis.com/docs/research/network/dns.html for info on the TIS Beta implementation. Donald On Mon, 2 Dec 1996, Maggie M. Lee wrote: > Date: Mon, 2 Dec 1996 23:55:12 -0500 (EST) > From: Maggie M. Lee > To: dns-security@tis.com > Subject: secure dns > > > Hi, > > I heard that secure dns has been released. I checked tis' home page > but couldn't find it. Would you mind telling me where I can find a > copy please? Thanks. > > Maggie Lee ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html From owner-dns-security Tue Dec 3 12:45:17 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA24365 for dns-security-outgoing; Tue, 3 Dec 1996 12:43:30 -0500 (EST) Date: Tue, 3 Dec 1996 12:06:00 -0500 (EST) Message-Id: <199612031706.MAA04310@patty.cs.columbia.edu> From: "Maggie M. Lee" To: dee@cybercash.com CC: dns-security@tis.com In-reply-to: (dee@cybercash.com) Subject: Re: secure dns Sender: owner-dns-security@ex.tis.com Precedence: bulk Don, Thanks a lot. I have read your internet-drafts on Secure DNS. They are very good. Maggie From owner-dns-security Tue Dec 3 13:28:08 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA24477 for dns-security-outgoing; Tue, 3 Dec 1996 13:27:00 -0500 (EST) X-Lotus-FromDomain: IBM RESEARCH From: "Padmaja Rao" To: dns-security@tis.com Message-ID: <852563F5:00653030.00@watngi01.watson.ibm.com> Date: Tue, 3 Dec 1996 13:27:50 -0400 Subject: Re: secure dns Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=xvsNQCmgEPnAoUDSCeArDNj4dQkJNrPaxHD7cBTLXhtlarHr70uV6x5a" Sender: owner-dns-security@ex.tis.com Precedence: bulk --0__=xvsNQCmgEPnAoUDSCeArDNj4dQkJNrPaxHD7cBTLXhtlarHr70uV6x5a Content-type: text/plain; charset=us-ascii Hi, Does anyone know if the final version (release) of this code will be available as public domain code. Padma ------ To: maggie @ cs.columbia.edu cc: dns-security @ tis.com (bcc: Padmaja Rao/Watson/IBM Research) From: dee @ cybercash.com Date: 12/03/96 10:18:50 AM Subject: Re: secure dns --0__=xvsNQCmgEPnAoUDSCeArDNj4dQkJNrPaxHD7cBTLXhtlarHr70uV6x5a Try http://www.tis.com/docs/research/network/dns.html for info on the TIS Beta implementation. Donald On Mon, 2 Dec 1996, Maggie M. Lee wrote: > Date: Mon, 2 Dec 1996 23:55:12 -0500 (EST) > From: Maggie M. Lee > To: dns-security@tis.com > Subject: secure dns > > > Hi, > > I heard that secure dns has been released. I checked tis' home page > but couldn't find it. Would you mind telling me where I can find a > copy please? Thanks. > > Maggie Lee ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html --0__=xvsNQCmgEPnAoUDSCeArDNj4dQkJNrPaxHD7cBTLXhtlarHr70uV6x5a-- From owner-dns-security Wed Dec 4 04:16:39 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA25556 for dns-security-outgoing; Wed, 4 Dec 1996 04:15:03 -0500 (EST) Message-Id: <1.5.4.32.19961204091731.006cee5c@gatekeeper.grolier.fr> X-Sender: merlin@gatekeeper.grolier.fr X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 04 Dec 1996 10:17:31 +0100 To: dns-security@tis.com From: Thomas Merlin Subject: MacOS Sender: owner-dns-security@ex.tis.com Precedence: bulk Hello, I'm not sure this is the correct mailing list, but I was wondering if MacOS was a reliable solution for a secure web site. (Our web site has to be very-very-very-very-secure.) Thanks for your feedback, Best regards, Tom. From owner-dns-security Wed Dec 4 09:43:36 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA26483 for dns-security-outgoing; Wed, 4 Dec 1996 09:41:46 -0500 (EST) Date: Wed, 4 Dec 1996 09:41:22 -0500 (EST) From: "Donald E. Eastlake 3rd" To: Thomas Merlin Cc: dns-security@tis.com Subject: Re: MacOS In-Reply-To: <1.5.4.32.19961204091731.006cee5c@gatekeeper.grolier.fr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk This mailing list is for disucssion of Domain Name System security. The DNS is the system that lets you look up things like grolier.fr and find out what IP address handles email sent to that name, etc. This mailing list has nothing to do with particular operating systems. Maybe you should try www-talk@w3.org. (But my personal impression is that MacOS is a very popular and secure web server platform.) I have also received a private email message asking if dns-security will enable you to restrict web access to certain users. DNS security as such has little to do with web server security. Of course, in some sense, security is only as good as the weakest link and DNS security helps out anything that uses the DNS, including web access: The primary goal of DNS Security is "data origin authentication", that is, with appropriate configuration, assurance that data retrieved from a secure DNS zone is the authentic data intended by the zone master. For example, it could assure that the A (or AAAA) record retrieved with the IP address for your web server name is the address data actually inserted by the owner of your DNS zone so people are at least, hopefully, trying your address instead of some other address. While this is important, it has very little to do with protecting your web server once the user manages to get packets to it. It also turns out that DNS Security provides a convenient secure key distribution mechanism. This key distribution mechanism could be used as the basis for SSL or IPSEC like secure communications between a browser and a web server. That is begining to get at web access security since it could also be used as the basis for secure client identity, but it would require a lot more mechanism in addition to DNS security to provide that. Donald On Wed, 4 Dec 1996, Thomas Merlin wrote: > Date: Wed, 04 Dec 1996 10:17:31 +0100 > From: Thomas Merlin > To: dns-security@tis.com > Subject: MacOS > > Hello, > > I'm not sure this is the correct mailing list, but I was wondering if MacOS > was a reliable solution for a secure web site. (Our web site has to be > very-very-very-very-secure.) > > Thanks for your feedback, > > Best regards, > > Tom. > > ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html From owner-dns-security Thu Dec 5 07:31:11 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA28271 for dns-security-outgoing; Thu, 5 Dec 1996 07:30:19 -0500 (EST) Date: Thu, 5 Dec 1996 07:30:19 -0500 (EST) From: owner-dns-security@ex.tis.com Message-Id: <199612051230.HAA28271@portal.ex.tis.com> To: "Donald E. Eastlake 3rd" cc: Havard.Eidnes@runit.sintef.no, namedroppers@internic.net, dns-security@tis.com, gnu@toad.com Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and draft-ietf-dnsind-clarify-02.txt) In-reply-to: Date: Wed, 04 Dec 1996 14:58:31 -0800 From: John Gilmore Sender: owner-dns-security@portal.ex.tis.com Precedence: bulk I think this is just a clarification from last week's discussion. > The superior authenticity of the KEY in the superzone > really comes from it being signed by the superzone. If the same KEY and > SIG appear at the apex of the subzone, they are equally authentic. To restate the above in simpler terms: What is critical in providing a certification chain authenticating each domain is that a SIG record, whose signer is the parent domain, exists to cover the domain's KEY record. Whether this record is served by the parent domain (as glue) or by the child domain (as authoritative), or both, is irrelevant to the certification chain. However, to preserve the integrity of DNS caching, glue records should always match the authoritative data. This argues against having parent domains provide KEY records for domains which do not implement DNSSEC (unless the child domains also provide the same null KEY record). It also argues against having different SIG KEY records in the parent and child zones (one signed by the parent, the other by the child). Instead, the child should serve both SIG records. The parent can choose to offer none, one, or both as glue. John From owner-dns-security Thu Dec 5 08:40:40 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA28390 for dns-security-outgoing; Thu, 5 Dec 1996 08:40:19 -0500 (EST) From: Samuli Mattila Message-Id: <199612051153.NAA20042@pallo.cs.hut.fi> Subject: key revokation in DNSSEC To: dns-security@tis.com Date: Thu, 5 Dec 1996 13:52:58 +0200 (EET) Cc: zam@iki.fi, Jarmo.Kaikkonen@hut.fi X-Mailer: ELM [version 2.4ME+ PL27 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-dns-security@ex.tis.com Precedence: bulk Hello all. A slight problem here with DNSSEC: We are implementing a generic public key encryptation scheme authentication layer, that supports RSA, ECC, ElGamal and LUC. This service layer uses smartcards (CSU) for decryptation and signing and DNSSEC for key distribution. It is highly unclear to me how key revokation is works in DNSSEC. Supposed that one of the secret keys is exposed, (or card losed in our case) and the exposed key is cached to various DNSSEC-servers (assuming TTL is too long), how do we tell all servers that some key is canceled? Is there some builtin revokation list broadcast? All suggestions are welcome. -- Samuli Mattila From owner-dns-security Thu Dec 5 09:09:55 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA28488 for dns-security-outgoing; Thu, 5 Dec 1996 09:09:47 -0500 (EST) Date: Thu, 5 Dec 1996 09:09:20 -0500 (EST) From: "Donald E. Eastlake 3rd" To: John Gilmore Cc: namedroppers@internic.net, dns-security@tis.com Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and draft-ietf-dnsind-clarify-02.txt) In-Reply-To: <199612051243.HAA24610@rs1.internic.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk John,, For some time we will have zones that are not secure and have not been modified in any way for security. Such zones will not have a signed null KEY RR or, indeed, any KEY or security RR. It is essential to be able to securely know that such a zone is insecure. Otherwise, someone wanting to spoof a zone will just pretend that it's an insecure zone that has not been modified in any way for security. The manner in which the DNSSEC Proposed Standard achieves this essential secure knowledge that a zone is insecure is by having a null KEY RR in the superzone signed by the superzone. It does not matter to DNSSEC what the state of the DNS authority bit is when this RR is retrieved. If you drop this from the superzone you have to introduce this secure information somewhere else in the superzone. You can't put it in the subzone without requiring every DNS zone is existence to be modified, which seems impractical to me. Thus I agree with most of what you say except that in the case of an insecure subzone the supezone *must* provide a null KEY RR. Donald On Wed, 4 Dec 1996, John Gilmore wrote: > Date: Wed, 04 Dec 1996 14:58:31 -0800 > From: John Gilmore > To: "Donald E. Eastlake 3rd" > Cc: Havard.Eidnes@RUNIT.SINTEF.NO, namedroppers@internic.net, > dns-security@TIS.COM, gnu@toad.com > Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and draft-ietf-dnsind-clarify-02.txt) > > I think this is just a clarification from last week's discussion. > > > The superior authenticity of the KEY in the superzone > > really comes from it being signed by the superzone. If the same KEY and > > SIG appear at the apex of the subzone, they are equally authentic. > > To restate the above in simpler terms: > > What is critical in providing a certification chain authenticating > each domain is that a SIG record, whose signer is the parent domain, > exists to cover the domain's KEY record. > > Whether this record is served by the parent domain (as glue) or by the > child domain (as authoritative), or both, is irrelevant to the > certification chain. > > However, to preserve the integrity of DNS caching, glue records should > always match the authoritative data. > > This argues against having parent domains provide KEY records for > domains which do not implement DNSSEC (unless the child domains also > provide the same null KEY record). It also argues against having > different SIG KEY records in the parent and child zones (one signed > by the parent, the other by the child). Instead, the child should serve > both SIG records. The parent can choose to offer none, one, or both > as glue. > > John > ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html From owner-dns-security Thu Dec 5 09:49:59 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA28557 for dns-security-outgoing; Thu, 5 Dec 1996 09:48:19 -0500 (EST) Date: Thu, 5 Dec 1996 09:50:14 -0500 (EST) From: Edward Lewis X-Sender: lewis@singsing.hq.tis.com To: "Donald E. Eastlake 3rd" cc: John Gilmore , namedroppers@internic.net, dns-security@tis.com Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and draft-ietf-dnsind-clarify-02.txt) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk On Thu, 5 Dec 1996, Donald E. Eastlake 3rd wrote: > > Thus I agree with most of what you say except that in the case of an > insecure subzone the supezone *must* provide a null KEY RR. I disagree that there is a need to "must provide." Before I get into this headscratching example, let me say that I am not opposed to the "must" requirement's presence in the specification. It's implementable. I am merely trying to show there is no technical reason for it being present. (And thus, philosophically I guess I'm against it's presence.) (I hope this example is correct...if not, it exposes a weakness in understanding on my part. Please correct me...) Here is an example in which I think providing a null key is not helpful. The synopsis is that a parent zone is not the signer of the child's KEY RR. This could occur between a TLD (e.g., .COM and PSI) and a registrant in the TLD (e.g., zy23.com). In the example, "top." is the TLD, "bottom.top." is the delegated zone. Here is the inital state. In parent zone: $ORIGIN top. @ SOA ... ... KEY 33025 { Zone signing } ... bottom NS ns.bottom.top. KEY 256 { Null zone key } SIG KEY ... by top. ... ... In bottom.top.: $ORIGIN bottom.top. @ SOA ... ... KEY 33025 { Zone signing } ;;;;; a contradiction! SIG KEY ... by someone.else ... ... ns A 10.6.83.17 SIG A ...by bottom.top. ... ... bottom.top. is using "someone.else." to sign their zone key. This may not (ever) be known to top. Afterall, it is probably not running recursively. Now, if somehow this is inserted into top. "illegally" a secure zone would be "hijacked." ns.bottom.top. A 199.32.35.132 ; added to top.'s cache This nameserver (at 199.32.35.132) would be able to pull this off using non-secured DNS. It may even be able to pull it off as a secured DNS if it dupes "another.signer." to hold it's key - and "another.signer." is a trusted holder. The problem is that the top. zone should be authoritative for 1) the existence of the delegations NS and KEY records and 2) any SIG and NXT records it adds. The top zone is NOT authoritative for the contents of either the NS or KEY records, nor for the existence nor contents of any other records in the delegation. Having the null KEY RR means the parent is creating a record (and its contents) "outside its authority." And then it has the gall ;) to sign it! Without the null KEY RR, this is also possible, this situation is not caused by the presence of the null KEY RR. However, I don't see an advantage to having it. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: 301-854-5794 Email: lewis@tis.com From owner-dns-security Thu Dec 5 09:52:52 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA28592 for dns-security-outgoing; Thu, 5 Dec 1996 09:52:48 -0500 (EST) Date: Thu, 5 Dec 1996 09:52:33 -0500 (EST) From: "Donald E. Eastlake 3rd" To: Samuli Mattila Cc: dns-security@tis.com, zam@iki.fi, Jarmo.Kaikkonen@hut.fi Subject: Re: key revokation in DNSSEC In-Reply-To: <199612051153.NAA20042@pallo.cs.hut.fi> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk The original DNSSEC proposal by myself and Charlie Kaufman had a key revocation scheme but the overwhelming consensus of the WG was to leave that out for now. Key validity is generally determined by the expiration time in the SIG authenticating the KEY, not the TTL which is only a chache consistency mechanism. For the algorithm 1 DNSSEC keys, the idea to have fairly short expiration times, perhaps a couple of days, and just not worry about revocation for now. It's not like a long lived certificate system where things are valid for months or years. If you are using private algorithms or whatever, you could encode revocation information in KEY RRs if you wanted. Donald On Thu, 5 Dec 1996, Samuli Mattila wrote: > Date: Thu, 5 Dec 1996 13:52:58 +0200 (EET) > From: Samuli Mattila > To: dns-security@tis.com > Cc: zam@iki.fi, Jarmo.Kaikkonen@hut.fi > Subject: key revokation in DNSSEC > > Hello all. > > A slight problem here with DNSSEC: > > We are implementing a generic public key encryptation scheme > authentication layer, that supports RSA, ECC, ElGamal and LUC. > This service layer uses smartcards (CSU) for decryptation and > signing and DNSSEC for key distribution. > > It is highly unclear to me how key revokation is works in DNSSEC. > Supposed that one of the secret keys is exposed, (or card losed > in our case) and the exposed key is cached to various DNSSEC-servers > (assuming TTL is too long), how do we tell all servers that some > key is canceled? > > Is there some builtin revokation list broadcast? > > All suggestions are welcome. > > > -- Samuli Mattila > > > ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html From owner-dns-security Thu Dec 5 10:02:56 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA28645 for dns-security-outgoing; Thu, 5 Dec 1996 10:02:49 -0500 (EST) Date: Thu, 5 Dec 1996 10:02:03 -0500 (EST) From: "Donald E. Eastlake 3rd" To: Edward Lewis Cc: namedroppers@internic.net, dns-security@tis.com Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and draft-ietf-dnsind-clarify-02.txt) In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk Ed, Your example seems to have little to do with what I was saying. (1) I was considering the normal general case where you were working your way down from root. If you have prior knowledge of a zone's key or if the zone is cross certified by someone whose key you trust, then you should trust the zone as secure. (2) I spoke only of the case of an unmodified insecure zone. In that case only, I said you *must* have a secure indication in the superzone that this subzone is insecure, otherwise someone tracing down from root can be spoofed into thinking they have stepped into an insecure zone. Your example is of a secure zone. It is has been modified from an insecure zone by the addition of security RRs. My "must" did not apply to secure zones. Donald On Thu, 5 Dec 1996, Edward Lewis wrote: > Date: Thu, 5 Dec 1996 09:50:14 -0500 (EST) > From: Edward Lewis > To: "Donald E. Eastlake 3rd" > Cc: John Gilmore , namedroppers@internic.net, > dns-security@tis.com > Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and draft-ietf-dnsind-clarify-02.txt) > > On Thu, 5 Dec 1996, Donald E. Eastlake 3rd wrote: > > > > Thus I agree with most of what you say except that in the case of an > > insecure subzone the supezone *must* provide a null KEY RR. > > I disagree that there is a need to "must provide." Before I get into > this headscratching example, let me say that I am not opposed to the > "must" requirement's presence in the specification. It's implementable. > I am merely trying to show there is no technical reason for it being > present. (And thus, philosophically I guess I'm against it's presence.) > > (I hope this example is correct...if not, it exposes a weakness in > understanding on my part. Please correct me...) > > Here is an example in which I think providing a null key is not helpful. > The synopsis is that a parent zone is not the signer of the child's KEY > RR. This could occur between a TLD (e.g., .COM and PSI) and a registrant > in the TLD (e.g., zy23.com). > > In the example, "top." is the TLD, "bottom.top." is the delegated zone. > Here is the inital state. > > In parent zone: > > $ORIGIN top. > @ SOA ... > ... > KEY 33025 { Zone signing } > ... > bottom NS ns.bottom.top. > KEY 256 { Null zone key } > SIG KEY ... by top. ... > ... > > In bottom.top.: > > $ORIGIN bottom.top. > @ SOA ... > ... > KEY 33025 { Zone signing } ;;;;; a contradiction! > SIG KEY ... by someone.else ... > ... > ns A 10.6.83.17 > SIG A ...by bottom.top. ... > ... > > bottom.top. is using "someone.else." to sign their zone key. This may not > (ever) be known to top. Afterall, it is probably not running recursively. > > Now, if somehow this is inserted into top. "illegally" a secure zone > would be "hijacked." > > ns.bottom.top. A 199.32.35.132 ; added to top.'s cache > > This nameserver (at 199.32.35.132) would be able to pull this off using > non-secured DNS. It may even be able to pull it off as a secured DNS if > it dupes "another.signer." to hold it's key - and "another.signer." is a > trusted holder. > > The problem is that the top. zone should be authoritative for 1) the > existence of the delegations NS and KEY records and 2) any SIG and NXT > records it adds. The top zone is NOT authoritative for the contents of > either the NS or KEY records, nor for the existence nor contents of any > other records in the delegation. > > Having the null KEY RR means the parent is creating a record (and its > contents) "outside its authority." And then it has the gall ;) to sign it! > > Without the null KEY RR, this is also possible, this situation is not > caused by the presence of the null KEY RR. However, I don't see an > advantage to having it. > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis Trusted Information Systems > Phone: 301-854-5794 Email: lewis@tis.com > > ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html From owner-dns-security Thu Dec 5 10:34:02 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA28795 for dns-security-outgoing; Thu, 5 Dec 1996 10:33:48 -0500 (EST) Date: Thu, 5 Dec 1996 10:35:36 -0500 (EST) From: Edward Lewis X-Sender: lewis@singsing.hq.tis.com To: "Donald E. Eastlake 3rd" cc: namedroppers@internic.net, dns-security@tis.com Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and draft-ietf-dnsind-clarify-02.txt) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk On Thu, 5 Dec 1996, Donald E. Eastlake 3rd wrote: > Your example seems to have little to do with what I was saying. "Seems" is correct. Sorry about not being clear... Considering the assumptions that everyone is following the specification, the presence of the null KEY RR indicated a non-secured delegated zone. I see that. The absence of any KEY RR results in not knowing what to expect of the delegated zone's security. My understanding of that is why I am not vehemently opposed to the requirement. But in considering the operational scenarios, in which mistakes and outright malicious attacks occur, the presence of the null KEY RR is no more helpful than having no KEY RR at a delegation point. This is what my example is trying to illustrate. Consider a delegating zone that (early on) does not offer to sign KEY RR's for it's clients, but is running the secure DNS extenstions. For the registry's clients that are running secure DNS with a zone key, the null KEY (inserted as required by the delegator) is incorrect. Another situation may occur during the switch to secure DNS. A client of a registry may "forget" to tell the registry that it is using someone else to sign it's zone keys. (I have worked at places with incorrect network contact information in the whois database. Network management - as opposed to adminisitrators - seem to forget to update such information.) Yet another situation is the malicious polluting of the parent by a rogue administrator (or other means). This is the situation in which the parent is overstepping it's bounds by creating the contents for which it does not have authority. (This only works for the null KEY RR - it's the only RR that a secure resolver expects to get from the parent and the parent's KEY to verify.) The bottom line is that in theory, the null KEY RR authoritatively and correctly indicates a non-secured delegation. But in practice, this gives too much(?) power to the delegating zone over the delegation. (Would you want a TLD aministration to be able to hold your zone at "null KEY point" over some issue? ;) ) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: 301-854-5794 Email: lewis@tis.com From owner-dns-security Thu Dec 5 16:46:41 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA29500 for dns-security-outgoing; Thu, 5 Dec 1996 16:43:59 -0500 (EST) Message-Id: <9612052145.AA20433@sol.hq.tis.com> To: "Padmaja Rao" Cc: ogud@tis.com, dns-security@tis.com Subject: Re: secure dns In-Reply-To: Your message of "Tue, 03 Dec 1996 13:27:50 -0400." <852563F5:00653030.00@watngi01.watson.ibm.com> Date: Thu, 05 Dec 1996 16:45:53 -0500 From: Olafur Gudmundsson Sender: owner-dns-security@ex.tis.com Precedence: bulk "Padmaja Rao" writes: > > --0__=xvsNQCmgEPnAoUDSCeArDNj4dQkJNrPaxHD7cBTLXhtlarHr70uV6x5a > Content-type: text/plain; charset=us-ascii > > > > Hi, > Does anyone know if the final version (release) of this code will be > available as public domain code. When it gets migrared into the standard bind distribution. There will be at least one more release of the TIS code soon after IETF, to bring it up to bind-4.9.5. Olafur From owner-dns-security Thu Dec 5 22:06:41 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA29917 for dns-security-outgoing; Thu, 5 Dec 1996 22:05:54 -0500 (EST) From: Masataka Ohta Message-Id: <199612060248.LAA13527@necom830.hpcl.titech.ac.jp> Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and draft-ietf-dnsind-clarify-02.txt) To: lewis@tis.com (Edward Lewis) Date: Fri, 6 Dec 96 11:48:35 JST Cc: dee@cybercash.com, gnu@toad.com, namedroppers@internic.net, dns-security@tis.com In-Reply-To: ; from "Edward Lewis" at Dec 5, 96 9:50 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-dns-security@ex.tis.com Precedence: bulk > > Thus I agree with most of what you say except that in the case of an > > insecure subzone the supezone *must* provide a null KEY RR. > > I disagree that there is a need to "must provide." Before I get into > this headscratching example, let me say that I am not opposed to the > "must" requirement's presence in the specification. It's implementable. As long as you don't call the implementation DNS, it would be implementable. > I am merely trying to show there is no technical reason for it being > present. (And thus, philosophically I guess I'm against it's presence.) Agreed. The null KEY RR gives mere half cooked and half broken protection against unimportant denial of service. In the real world applications, it is useless to securely know that some lookup is insecure. The only meaningful protection agaist denial of service attacks is to securely know that some node does not exist, which can be performed by ZL RRs without introducing glue related complications. Masataka Ohta From owner-dns-security Fri Dec 6 02:07:58 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA00021 for dns-security-outgoing; Fri, 6 Dec 1996 02:06:12 -0500 (EST) Date: Thu, 5 Dec 1996 23:08:27 -0800 (PST) X-btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: dns-security@tis.com From: paul@vix.com (Paul A Vixie) Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and draft-ietf-dnsind-clarify-02.txt) Organization: Vixie Enterprises Message-ID: References: NNTP-Posting-Host: wisdom.home.vix.com In-reply-to: lewis@tis.com's message of 5 Dec 1996 08:32:19 -0800 Xref: vixie local.mail.dns.security:460 Sender: owner-dns-security@ex.tis.com Precedence: bulk There's a limit to how much we ought to change the fundamental underlayment of DNS just to provide security. I don't like type-covered since it means some RRsets are no longer denoted by a tuple. But Donald explained to me why this was necessary and I could not think of a better way either. In the case of parent-vs-child SIGs, the answer is clearer by far: the zone's servers are authoritative for the zone, the parent has NS RRs only, and the zone needs to be resigned with the parent's key when it changes. If this means an out of band protocol needs to be specified to make zone signatures work, I hope that someone here will get started on that really soon. -- Paul Vixie La Honda, CA "Illegitimibus non carborundum." pacbell!vixie!paul From owner-dns-security Fri Dec 6 05:34:02 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id FAA00146 for dns-security-outgoing; Fri, 6 Dec 1996 05:32:41 -0500 (EST) Message-ID: <32A7F8B7.794BDF32@inria.fr> Date: Fri, 06 Dec 1996 11:43:03 +0100 From: Shabou Malek Organization: INRIA X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 4.1.3_U1 sun4m) MIME-Version: 1.0 To: dns-security@tis.com Subject: request for information Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-dns-security@ex.tis.com Precedence: bulk i work in INRIA (france) on dynamicUpdate and security of the dns and i am looking of technical documentation of the bind (vixie release and tis release) (fonctions and API) shabou malek From owner-dns-security Sat Dec 7 01:43:03 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA02136 for dns-security-outgoing; Sat, 7 Dec 1996 01:41:26 -0500 (EST) From: Masataka Ohta Message-Id: <199612070642.PAA01999@necom830.hpcl.titech.ac.jp> Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and draft-ietf-dnsind-clarify-02.txt) To: paul@vix.com (Paul A Vixie) Date: Sat, 7 Dec 96 15:42:00 JST Cc: dns-security@tis.com In-Reply-To: ; from "Paul A Vixie" at Dec 5, 96 11:08 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-dns-security@ex.tis.com Precedence: bulk Paul; > There's a limit to how much we ought to change the fundamental underlayment > of DNS just to provide security. I don't like type-covered since it means > some RRsets are no longer denoted by a tuple. But Donald > explained to me why this was necessary and I could not think of a better way > either. You should have asked me. While things like is necessary, it is possible to reduce the size of the RR with , which means that, most of the case, all the RRs with confortably fits in a single 512 byte message. To do so, let the RR with have digest (16 or 20 byte long), not signature (64~256 byte long). For example, with the following RR RRD the length of an RR without the name is only 32 (with MD5 digest) or 36 (with SHA digest) bytes long. The digest values themselves, then, digested and signed only once per a node. That is, you can put more than 10 RRs in a single UDP packet. Masataka Ohta From owner-dns-security Mon Dec 9 12:17:01 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA05501 for dns-security-outgoing; Mon, 9 Dec 1996 12:13:27 -0500 (EST) Message-Id: <2.2.32.19961209171504.006832cc@popsrvr.hq.tis.com> X-Sender: ogud@popsrvr.hq.tis.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 09 Dec 1996 12:15:04 -0500 To: Samuli Mattila , dns-security@tis.com From: Olafur Gudmundsson Subject: Re: key revokation in DNSSEC Cc: zam@iki.fi, Jarmo.Kaikkonen@hut.fi Sender: owner-dns-security@ex.tis.com Precedence: bulk At 01:52 PM 12/5/96 +0200, Samuli Mattila wrote: >Hello all. > >A slight problem here with DNSSEC: > >It is highly unclear to me how key revokation is works in DNSSEC. >Supposed that one of the secret keys is exposed, (or card losed >in our case) and the exposed key is cached to various DNSSEC-servers >(assuming TTL is too long), how do we tell all servers that some >key is canceled? Short answer, you can not !! DNSSEC does not have KEY revocation, KEYs expire when the accompanying Signature expires (based on the expiration thime in the signature). If you need to be able to remove keys rapidly you keep your zone TTL and expiration times low. This on the other hand forces you to resign your zone freqently. There is no way that DNS can be modified in a way that originating zone can purge data from all caching servers that may contain the data. DNSSEC has accepted the fact that TTL is the lower and most often the upper bound on how long revoked KEYS stay around. Malicious servers can continue to return the revoked KEY until its Signature expires. The question is who will ask the malicious server. The operational guideline should be to keep your TTL value > >Is there some builtin revokation list broadcast? No > >All suggestions are welcome. Keep your TTLs low and resign Store all KEYs you possibly want to revoke below your zone apex (zone name). Olafur =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Olafur Gudmundsson ogud@tis.com 3060 Washington Road 301-854-5700 Glenwood MD 21738 301-854-5363 From owner-dns-security Mon Dec 9 13:43:13 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA05737 for dns-security-outgoing; Mon, 9 Dec 1996 13:40:44 -0500 (EST) From: Samuli Mattila Message-Id: <199612091843.UAA04093@pallo.cs.hut.fi> Subject: key revocation (continued) In-Reply-To: <2.2.32.19961209171504.006832cc@popsrvr.hq.tis.com> from Olafur Gudmundsson at "Dec 9, 96 12:15:04 pm" To: ogud@tis.com (Olafur Gudmundsson) Date: Mon, 9 Dec 1996 20:43:09 +0200 (EET) Cc: dns-security@tis.com, zam@iki.fi X-Mailer: ELM [version 2.4ME+ PL27 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-dns-security@ex.tis.com Precedence: bulk > Short answer, you can not !! As you are well aware there is a huge demand for a key exchange server on the market. If you are implementing such a server, why make it crippled? We at HUT are doing a research on smartcards and a pilot-version of a layer that allows third party software to use PK-encryption for authentication, and we use DNSSEC for key exchange. Soon Finnish government will pass a law that allows smartcards (CSU) as a personal ID (Sweden is not far behind), later the rest of Europe will most propably follow. And I'd be most surprised if US will not make it's own twisted version of this (they tend to do that). Supposedly every person will have a key pair, so we need a good scheme for key exchange. DNSSEC might as well be this server, if key revocation problem is corrected. At this capacity one day TTL or similar cludge is not a very classy sollution. Why DNSSEC? It is already widely accepted, although not perfect. If every country and organisation selects their own commersial sollution (which are surprisingly not compatible) for key exchange, this will drag down communication security for years. You are in the position to set the standards, why not make right at the first time? Even a promise to add key revocation scheme lateron would make miracles to DNSSEC's reliability. ps. This is just feedback and my personal opinion on this matter, and I am deliverably leaving cryptographic policies out of this. -- Samuli Mattila From owner-dns-security Mon Dec 9 13:58:27 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA05876 for dns-security-outgoing; Mon, 9 Dec 1996 13:56:36 -0500 (EST) X-Sender: galvin@pop.east.commerce.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 9 Dec 1996 14:01:28 -0500 To: namedroppers@internic.net, dns-security@ex.tis.com From: "James M. Galvin" Subject: DNSSEC/DNSIND joint meeting WEDNESDAY Sender: owner-dns-security@ex.tis.com Precedence: bulk The joint meeting of the DNSSEC and DNSIND working groups has been moved to the WEDNESDAY morning slot currently occupied by DNSSEC. The joint meeting on the agenda scheduled for friday has been CANCELLED. The only item on the agenda is Secure Dynamic Update. Other topics will be permitted if time permits. See y'all there! Jim ---------------------------------------------------------------------------- James M. Galvin galvin@commerce.net CommerceNet +1 410.203.2707 3209-A Corporate Court FAX +1 410.203.2709 Ellicott City, MD 21042 http://www.commerce.net/ http://www.eff.org/blueribbon http://www.eff.org/goldkey From owner-dns-security Mon Dec 9 16:17:36 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA06464 for dns-security-outgoing; Mon, 9 Dec 1996 16:16:43 -0500 (EST) X-Sender: mccoy@hesiod.communities.com Message-Id: In-Reply-To: <199612091843.UAA04093@pallo.cs.hut.fi> References: <2.2.32.19961209171504.006832cc@popsrvr.hq.tis.com> from Olafur Gudmundsson at "Dec 9, 96 12:15:04 pm" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 9 Dec 1996 13:18:55 -0800 To: Samuli Mattila From: Jim McCoy Subject: Re:key revocation (continued) Cc: dns-security@tis.com Sender: owner-dns-security@ex.tis.com Precedence: bulk Samuli Mattila writes [regarding Key revocation...] >> Short answer, you can not !! > >As you are well aware there is a huge demand for a key exchange server >on the market. If you are implementing such a server, why make it crippled? Because the problem you are trying to solve is not the one which this initiative is working on fixing. You need to check in on the work of the PKI and SPKI working groups. DNSSEC is intended to secure the DNS namespace, not provide general public key infrastructure. jim From owner-dns-security Tue Dec 10 11:39:51 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA08243 for dns-security-outgoing; Tue, 10 Dec 1996 11:36:05 -0500 (EST) Message-Id: <2.2.32.19961210163813.00682bc8@popsrvr.hq.tis.com> X-Sender: ogud@popsrvr.hq.tis.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 10 Dec 1996 11:38:13 -0500 To: Samuli Mattila From: Olafur Gudmundsson Subject: Re: key revocation (continued) Cc: dns-security@tis.com Sender: owner-dns-security@ex.tis.com Precedence: bulk At 08:43 PM 12/9/96 +0200, you wrote: > >> Short answer, you can not !! > >As you are well aware there is a huge demand for a key exchange server on the >market. If you are implementing such a server, why make it crippled? It is not crippled, it is designed to fit within the existing DNS schema, which relies on timers for data refreshing. In the original DNSSEC draft there was an KEY revocation schema, but there where number of problems, including that it was deemed hard/impossible to implement and we where not sure that it could get rid of KEYs that had expired. Thus the working group agreed that the current expiration mechanism was sufficient for DNS purposes. ( I will take my fair credit for having the key revocation schema deleted from the draft). Instead of screeming "DNSSEC is crippled" please take a few minutes to clearly state your operating "requirements" including timing and reliabiltity. Maybe we can figure out a way to map those "requirements" so that DNS will treat the keys in a way that will give you operationally behavior that is similar to what you would get from a system that has explicit key revocation built into it. > >We at HUT are doing a research on smartcards and a pilot-version of a layer >that allows third party software to use PK-encryption for authentication, and >we use DNSSEC for key exchange. > >Soon Finnish government will pass a law that allows smartcards (CSU) as a personal ID (Sweden is not far behind), later the rest of Europe will most propably follow. And I'd be most surprised if US will not make it's own twisted version of this (they tend to do that). People here in the US are largely against ID cards, so we will see what happens > >Supposedly every person will have a key pair, so we need a good scheme for key >exchange. DNSSEC might as well be this server, if key revocation problem is >corrected. At this capacity one day TTL or similar cludge is not a very classy >sollution. KISS (keep it simple .......) If DNSSEC schema works why do you care if it is "classy" ? DNS is not designed for KEY exchange it is designed for making public data available. It is accepted that some of the data in the DNS distributed database is inconsistent. If your application can not tolerate the loose consistency of DNS, under any circumstances you should not use DNS. > >Why DNSSEC? It is already widely accepted, although not perfect. If every >country and organisation selects their own commersial sollution (which are >surprisingly not compatible) for key exchange, this will drag down >communication security for years. > >You are in the position to set the standards, why not make right at the first >time? Even a promise to add key revocation scheme lateron would make miracles >to DNSSEC's reliability. IF you or someone is willing to figure out how to do key revocation schema for DNSSEC that does not break DNS at the same time, please go ahead and submit a draft to the working group. I would be happy to help. >-- Samuli Mattila > > Olafur Gudmundsson ogud@tis.com =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Olafur Gudmundsson ogud@tis.com 3060 Washington Road 301-854-5700 Glenwood MD 21738 301-854-5363 From owner-dns-security Wed Dec 11 07:56:37 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA10144 for dns-security-outgoing; Wed, 11 Dec 1996 07:55:00 -0500 (EST) Message-ID: <32AE7AD0.2781E494@inria.fr> Date: Wed, 11 Dec 1996 10:11:44 +0100 From: Shabou Malek Organization: INRIA X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 4.1.3_U1 sun4m) MIME-Version: 1.0 To: dns-security@tis.com Subject: help for subscription Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-dns-security@ex.tis.com Precedence: bulk does any one known how to subscribe in bind-workers mailling list A+ From owner-dns-security Thu Dec 12 15:35:55 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA04848 for dns-security-outgoing; Thu, 12 Dec 1996 15:30:39 -0500 (EST) From: Samuli Mattila Message-Id: <199612122032.WAA05171@pallo.cs.hut.fi> Subject: Re: key revocation (continued) In-Reply-To: <2.2.32.19961210163813.00682bc8@popsrvr.hq.tis.com> from Olafur Gudmundsson at "Dec 10, 96 11:38:13 am" To: ogud@tis.com (Olafur Gudmundsson) Date: Thu, 12 Dec 1996 22:32:58 +0200 (EET) Cc: dns-security@tis.com, zam@iki.fi X-Mailer: ELM [version 2.4ME+ PL27 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-dns-security@ex.tis.com Precedence: bulk > ogud@tis.com (Olafur Gudmundsson) wrote: > IF you or someone is willing to figure out how to do key revocation schema > for DNSSEC that does not break DNS at the same time, please go ahead and > submit a draft to the working group. A friend of mine told me that there has been already a lot of discussion on subject "short lived certificates vs. crl" (unfortunately I have missed it). I'am not particulary forth crl's, but the scheme has various good sides. The answer to this dilemma propably lies somewhere in the middleground. In my opinion DNSSEC should also support crl, allthough it is not trivial to implement a good key revocation schema. Why? Because would make DNSSEC a more generic sollution, even to the problems yet to come. Now supposedly we are in a situation where every person has a key-pair (or a few) and we use DNSSEC for key exchange. If we use 1 day certificates, the traffic would propably prove troublesome. Let us take a trusted 3rd party as a key rovocation server (KRS), to whom all the threathened keys are reported to. KRS would be subject to all revocation queries (atleast from DNSSEC). Instead of making 1 days certificates the DNSSEC would now sign keys for one month. DNSSEC would also be obligated to make a revocation-list-query to KRS once per day, where it asks for latest ( 1 month ) revocation list. This list should then be stored and cache- and key list consistency checked accordingly. DNSSEC could also pass this revocation list forth on a clients query. Wether a system chooses to use this revocation list scheme is entirely up to it, nevertheless this option should be available. The optimum time values (as 1 day or 1 month here) should be calculated by simulation. As you may realise, I really didn't give this a much thought (due lack of free time), but the sollution might be something like this. -- Samuli Mattila From owner-dns-security Fri Dec 13 12:15:37 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA01021 for dns-security-outgoing; Fri, 13 Dec 1996 12:15:10 -0500 (EST) Message-ID: <32B1918F.446B9B3D@inria.fr> Date: Fri, 13 Dec 1996 18:25:35 +0100 From: Shabou Malek Organization: INRIA X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 4.1.3_U1 sun4m) MIME-Version: 1.0 To: dns-security@tis.com Subject: dynamic update Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-dns-security@ex.tis.com Precedence: bulk i have tried to compile secdns with ALLOW_UPDATE option but i didn'i succed. an error occures in res_mkquery saying: res_mkquery.c:200: `UPDATEM' undeclared (first use this function) A+ From owner-dns-security Fri Dec 13 13:14:06 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA02186 for dns-security-outgoing; Fri, 13 Dec 1996 13:12:26 -0500 (EST) Message-Id: Date: Fri, 13 Dec 96 10:14 PST From: randy@psg.com (Randy Bush) To: namedroppers , dnssec Subject: draft minutes for Joint DNSSEC/DNSIND WG Meeting Sender: owner-dns-security@ex.tis.com Precedence: bulk The DNSSEC and DNSIND working groups met jointly. The agenda was as follows: Introductions Implementation Status Documents draft-ietf-dnsind-dynDNS-11.txt draft-ietf-dnssec-update-02.txt Although it had been announced on the mailing list, Trusted Information Systems (TIS) announced the global (i.e. exportable!) availability of their DNSSEC implementation; it has been approved for export in source code form. Note, the source code does not include the cryptographic functions. These are available separately in the US by acquiring RSAREF and outside the US by acquiring RSAEURO. John Gilmore was thanked for his expertise and advice in assisting TIS during the export application process. TIS reported that their implementation of DNSSEC is currently being integrated with the latest version of bind. The completion of this will permit bind to be distributed with support for secure DNS. In parallel they have begun implementing the secure dynamic update specifications. John Gilmore reported that support for SIG and KEY records is in the current production release of BIND (4.9.5). This support allows the RR's to be published and queried, but does no crypto validation. You can generate these records using the offline signer in TIS's beta release. The same support, plus additional support for NXT records is already in BIND 8.x, and I am actively working on merging the rest of TIS's DNSSEC into it. Two of the root/com servers are running 4.9.5 and could publish keys and signatures (the rest will have to upgrade to make it possible for the IANA or the InterNIC to publish keys or signature). Paul Vixie reported that the latest version of bind currently supports the latest version of dynamic update without security. In closing, the working group was asked if there were any serious technical objections to the advancement of the two principal documents before them. The dynamic udpate document (dnsind-dynDNS) is in IETF Last Call pending the advancement of the secure dynamic update document (dnssec-update). A technical issue was raised in the secure dynamic update draft (dnssec-update) as to the incompleteness of the specification of reverse key lookups. It was decided to defer the issue to the mailing list and to move that section of the document to a separate document, likely after advancement. With the one editorial change it was the consensus of the working groups to submit the secure dynamic update draft (dnssec-update) to the IESG to be considered for publication as a Proposed Standard. All discussion of future work of the working groups was deferred to their respective mailing lists and the meeting adjourned. From owner-dns-security Fri Dec 13 13:26:14 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA02486 for dns-security-outgoing; Fri, 13 Dec 1996 13:26:06 -0500 (EST) X-Sender: galvin@pop.east.commerce.net (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 13 Dec 1996 12:42:41 -0500 To: namedroppers@internic.net, dns-security@tis.com From: "James M. Galvin" Subject: draft Joint DNSSEC/DNSIND Meeting Minutes Sender: owner-dns-security@ex.tis.com Precedence: bulk Enclosed below are the draft minutes for our joint meeting. Comments, corrections, and questions are solicited until wednesday, December 18, at which time they will be submitted for inclusion in the proceedings. Enjoy. -------- The DNSSEC and DNSIND working groups met jointly on wednesday, December 11. The agenda was as follows: Introductions Implementation Status Documents draft-ietf-dnsind-dynDNS-11.txt draft-ietf-dnssec-update-02.txt Although it has been announced on the mailing list for some time, Trusted Information Systems (TIS) announced the global availability of their DNSSEC implementation; it has been approved for export in source code form. Note, the source code does not include the cryptographic functions. These are available separately in the US by acquiring RSAREF and outside the US by acquiring RSAEURO. John Gilmore was thanked for his expertise and advice in assisting TIS during the export application process. TIS reported that their implementation of DNSSEC is currently being integrated with the latest version of bind. The completion of this will permit bind to be distributed with support for secure DNS. In parallel they have begun implementing the secure dynamic update specifications. John Gilmore reported that support for SIG and KEY records is in the current production release of BIND (4.9.5). This support allows the RR's to be published and queried, but does no cryptographic validation. You can generate these records using the offline signer in TIS's beta release. The same support, plus additional support for NXT records is already in BIND 8.x, and he is actively working on merging the rest of TIS's DNSSEC into it. In addition, two of the root/com servers are running 4.9.5 and could publish keys and signatures (the rest will have to upgrade to make it possible for the IANA or the InterNIC to publish keys or signature). Paul Vixie reported that the latest version of bind currently supports the latest version of dynamic update without security. In closing, the working group was asked if there were any serious technical objections to the advancement of the two principal documents before them. The dynamic udpate document (dnsind-dynDNS) is in IETF Last Call pending the advancement of the secure dynamic update document (dnssec-update). A technical issue was raised in the secure dynamic update draft (dnssec-update) as to the incompleteness of the specification of reverse key lookups. It was decided to defer the issue to the mailing list and to move that section of the document to a separate document. With the one editorial change it was the consensus of the working groups to submit the secure dynamic update draft (dnssec-update) to the IESG to be considered for publication as a Proposed Standard. All discussion of future work of the working groups was deferred to their respective mailing lists and the meeting adjourned. ---------------------------------------------------------------------------- James M. Galvin galvin@commerce.net CommerceNet +1 410.203.2707 3209-A Corporate Court FAX +1 410.203.2709 Ellicott City, MD 21042 http://www.commerce.net/ http://www.eff.org/blueribbon http://www.eff.org/goldkey From owner-dns-security Sat Dec 14 03:14:07 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA19665 for dns-security-outgoing; Sat, 14 Dec 1996 03:12:18 -0500 (EST) Date: Sat, 14 Dec 1996 00:15:02 -0800 (PST) X-btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: dns-security@tis.com From: paul@vix.com (Paul A Vixie) Subject: Re: dynamic update Organization: Vixie Enterprises Message-ID: References: <32B1918F.446B9B3D@inria.fr> NNTP-Posting-Host: wisdom.home.vix.com In-reply-to: malek.shabou@inria.fr's message of 13 Dec 1996 10:05:32 -0800 Xref: vixie local.mail.dns.security:473 Sender: owner-dns-security@ex.tis.com Precedence: bulk ALLOW_UPDATE is old stuff, unrelated to DNS UPDATE. It's gone in BIND 8.1. -- Paul Vixie La Honda, CA "Illegitimibus non carborundum." pacbell!vixie!paul From owner-dns-security Wed Dec 18 03:33:22 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA04327 for dns-security-outgoing; Wed, 18 Dec 1996 03:29:09 -0500 (EST) From: Masataka Ohta Message-Id: <199612180830.RAA08722@necom830.hpcl.titech.ac.jp> Subject: Re: draft Joint DNSSEC/DNSIND Meeting Minutes To: galvin@commerce.net (James M. Galvin) Date: Wed, 18 Dec 96 17:29:56 JST Cc: namedroppers@internic.net, dns-security@tis.com In-Reply-To: ; from "James M. Galvin" at Dec 13, 96 12:42 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-dns-security@ex.tis.com Precedence: bulk James M. Galvin; > Enclosed below are the draft minutes for our joint meeting. Comments, > corrections, and questions are solicited until wednesday, December 18, at > which time they will be submitted for inclusion in the proceedings. > A technical issue was raised in the secure dynamic update draft > (dnssec-update) as to the incompleteness of the specification of reverse > key lookups. Wrong. The issue is not on some imcomplete specification. The issue is purely technical that it is impossible to perform reverse DNS lookups with hashed values. The issue is a serious technical defect. > It was decided to defer the issue to the mailing list and to > move that section of the document to a separate document. > > With the one editorial change it was the consensus of the working groups to > submit the secure dynamic update draft (dnssec-update) to the IESG to be > considered for publication as a Proposed Standard. I reconsider your proposal (as you gave the WGs only 5 seconds at the meeting to consider your proposal, it is difficult to call your proposal WG consensus). I now think that, as the issue raised is serious technical defect, it is impossible to call the change "one editorial change" and that one more WG last call is inevitable after the change. Masataka Ohta From owner-dns-security Wed Dec 18 21:36:47 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA11363 for dns-security-outgoing; Wed, 18 Dec 1996 21:35:04 -0500 (EST) X-Sender: galvin@pop.east.commerce.net Message-Id: In-Reply-To: <199612180830.RAA08722@necom830.hpcl.titech.ac.jp> References: ; from "James M. Galvin" at Dec 13, 96 12:42 pm Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 18 Dec 1996 21:38:51 -0500 To: Masataka Ohta From: "James M. Galvin" Subject: Re: draft Joint DNSSEC/DNSIND Meeting Minutes Cc: namedroppers@internic.net, dns-security@tis.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id VAA11360 Sender: owner-dns-security@ex.tis.com Precedence: bulk At 3:29 AM -0500 12/18/96, Masataka Ohta wrote: >> A technical issue was raised in the secure dynamic update draft >> (dnssec-update) as to the incompleteness of the specification of reverse >> key lookups. > >Wrong. The issue is not on some imcomplete specification. Please tell me what words you want me to use and I'll do that. >> With the one editorial change it was the consensus of the working groups to >> submit the secure dynamic update draft (dnssec-update) to the IESG to be >> considered for publication as a Proposed Standard. > >I reconsider your proposal (as you gave the WGs only 5 seconds at the >meeting to consider your proposal, it is difficult to call your proposal >WG consensus). > >I now think that, as the issue raised is serious technical defect, >it is impossible to call the change "one editorial change" and >that one more WG last call is inevitable after the change. Whether or not the issue is a "serious technical defect", it is an editorial change to remove it from the document and thus exclude it from consideration. It would be a technical change only if the removal of the functionality resulted in a protocol that could not perform correctly. Jim ---------------------------------------------------------------------------- James M. Galvin galvin@commerce.net CommerceNet +1 410.203.2707 3209-A Corporate Court FAX +1 410.203.2709 Ellicott City, MD 21042 http://www.commerce.net/ http://www.eff.org/blueribbon http://www.eff.org/goldkey From owner-dns-security Wed Dec 18 22:32:15 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA11658 for dns-security-outgoing; Wed, 18 Dec 1996 22:32:08 -0500 (EST) From: Masataka Ohta Message-Id: <199612190333.MAA10948@necom830.hpcl.titech.ac.jp> Subject: Re: draft Joint DNSSEC/DNSIND Meeting Minutes To: galvin@east.commerce.net (James M. Galvin) Date: Thu, 19 Dec 96 12:33:01 JST Cc: mohta@necom830.hpcl.titech.ac.jp, namedroppers@internic.net, dns-security@tis.com In-Reply-To: ; from "James M. Galvin" at Dec 18, 96 9:38 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-dns-security@ex.tis.com Precedence: bulk > >> A technical issue was raised in the secure dynamic update draft > >> (dnssec-update) as to the incompleteness of the specification of reverse > >> key lookups. > > > >Wrong. The issue is not on some imcomplete specification. > > Please tell me what words you want me to use and I'll do that. It should be: A serious technical flaw was found in the secure dynamic update draft (dnssec-update) as to the impossibility of hierarchical lookup of reverse key domain with *HASHED* key value. Though the DNSSEC chair proposed an extensive change to the draft, not enough time was assigned for the discussion and there was no consensus formed. > >> With the one editorial change it was the consensus of the working groups = > to > >> submit the secure dynamic update draft (dnssec-update) to the IESG to be > >> considered for publication as a Proposed Standard. > > > >I reconsider your proposal (as you gave the WGs only 5 seconds at the > >meeting to consider your proposal, it is difficult to call your proposal > >WG consensus). > > > >I now think that, as the issue raised is serious technical defect, > >it is impossible to call the change "one editorial change" and > >that one more WG last call is inevitable after the change. > > Whether or not the issue is a "serious technical defect", it is an > editorial change to remove it from the document and thus exclude it from > consideration. Are you joking? Any change is, of course, editorial. The problem is whether it is a simple and pure editorial change or not. Reconstruction of the document into two is already not simple. And, as one of the two can not proceed as is, it is a techical change. > It would be a technical change only if the removal of the functionality > resulted in a protocol that could not perform correctly. Not. The removal of some functionality is always a technical change. And, the question to be asked is that whether the removal, the technical change, needs some othere change for the entire specificaiton to make the specification work correctly, efficiently, meaningfully or ... Masataka Ohta From owner-dns-security Thu Dec 19 04:15:49 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA13280 for dns-security-outgoing; Thu, 19 Dec 1996 04:13:35 -0500 (EST) From: Masataka Ohta Message-Id: <199612190914.SAA11550@necom830.hpcl.titech.ac.jp> Subject: Re: draft Joint DNSSEC/DNSIND Meeting Minutes To: sra@epilogue.com (Rob Austein) Date: Thu, 19 Dec 96 18:13:51 JST Cc: mohta@necom830.hpcl.titech.ac.jp, galvin@east.commerce.net, namedroppers@internic.net, dns-security@tis.com, sra@epilogue.com In-Reply-To: <9612190351.aa06085@rurha-pente.epilogue.com>; from "Rob Austein" at Dec 19, 96 3:51 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-dns-security@ex.tis.com Precedence: bulk Rob; > Sorry, it wasn't James that proposed changing the draft, it was me. You personally communicated with several people at the front chairs in very weak voice and it's James who said it to the WG. > As I recall, you had two objections to the secure update draft: > > 1) It's much more complicated than you think is necessary. You misunderstand my first point. But, it's OK. > 2) The reverse key mapping tree. You're right about this being > flawed, Then, how could James say that: James> A technical issue was raised in the secure dynamic update draft James> (dnssec-update) as to the incompleteness of the specification of reverse James> key lookups. ???? The draft minute above means that your personal opinion was not understood by James and the WG. Hence, there is no WG consensus. > but as Donald pointed out, it's not an essential part of > the secure update mechanism, in fact it's totally unrelated and > should have been in a separate document all along. Did he? If it is so, I'm afraid Donald is making fool of himself that he can't write a proper document. That's a serious problem. And, no one can say that the resulting separated document can be good enough so that another round is absolutely necessary. So, if Donald actually said "should have been in a separate document all along", I'd like to propose replace the editor of the draft before making ANY editorial change. Anyway, there was not enough time given to judge whether the Donald's point was valid. Hence, there is no WG consensus. > At this point, I think the urgent need is to get some real field > experience with these protocols. That's not a valid reason to break procedural rules. > If they're flawed, I have faith that > the users (and the press, et al) will tell us so, perhaps with some > help from you. If? Haven't we agreed that it flawed? > But we've been designing this stuff for four years. So, we can wait for another four years (actually, it's less than four weeks, I'm AFRAID). > It's time to kick the protocols into the pool and see if they float. Let's move forward to throw flawed protocols away. Masataka Ohta From owner-dns-security Thu Dec 19 04:25:07 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA13335 for dns-security-outgoing; Thu, 19 Dec 1996 04:25:05 -0500 (EST) From: Masataka Ohta Message-Id: <199612190926.SAA11581@necom830.hpcl.titech.ac.jp> Subject: Re: key revocation (continued) To: ogud@tis.com (Olafur Gudmundsson) Date: Thu, 19 Dec 96 18:26:02 JST Cc: zam@niksula.hut.fi, dns-security@tis.com In-Reply-To: <2.2.32.19961210163813.00682bc8@popsrvr.hq.tis.com>; from "Olafur Gudmundsson" at Dec 10, 96 11:38 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-dns-security@ex.tis.com Precedence: bulk > >> Short answer, you can not !! > > > >As you are well aware there is a huge demand for a key exchange server on > the >market. If you are implementing such a server, why make it crippled? > > It is not crippled, It is crippled. > it is designed to fit within the existing DNS schema, > which relies on timers for data refreshing. The existing DNS schema is friendly to key revocation. > In the original DNSSEC draft It is the original DNSSEC draft which does not fit within the existing DNs schema, which is all the source of problems. > there was an KEY revocation schema, but there > where number of problems, including that it was deemed hard/impossible to > implement > and we where not sure that it could get rid of KEYs that had expired. It is possible, easy and simple to have secure DNS with key revocation capability. Masataka Ohta From owner-dns-security Thu Dec 19 07:53:03 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA14575 for dns-security-outgoing; Thu, 19 Dec 1996 07:51:06 -0500 (EST) To: Masataka Ohta cc: "James M. Galvin" , namedroppers@internic.net, dns-security@tis.com, sra@epilogue.com Subject: Re: draft Joint DNSSEC/DNSIND Meeting Minutes In-Reply-To: Message from Masataka Ohta dated "Thu, 19 Dec 96 12:33:01 +0200" <199612190333.MAA10948@necom830.hpcl.titech.ac.jp> References: <199612190333.MAA10948@necom830.hpcl.titech.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 19 Dec 1996 03:51:02 -0500 From: Rob Austein Message-ID: <9612190351.aa06085@rurha-pente.epilogue.com> Sender: owner-dns-security@ex.tis.com Precedence: bulk Ohta-san, Sorry, it wasn't James that proposed changing the draft, it was me. As I recall, you had two objections to the secure update draft: 1) It's much more complicated than you think is necessary. Not a surprising objection, you've diligently made essentially the same claim about the entire Eastlake-Kaufman DNSSEC architecture ever since it was proposed. You may even be right, but the WG came to "rough" consensus (meaning everybody but you either agreed or stood mute) quite some time ago, so this issue is basicly moot unless implementation and/or deployment experience proves your case. 2) The reverse key mapping tree. You're right about this being flawed, but as Donald pointed out, it's not an essential part of the secure update mechanism, in fact it's totally unrelated and should have been in a separate document all along. Hence my proposal, to move the reverse key mapping stuff into its own document. Unless you're claiming that the reverse mapping tree is an inseparable part of the secure update mechanism, I think that James is correct in calling this an "editorial change". At this point, I think the urgent need is to get some real field experience with these protocols. If they're flawed, I have faith that the users (and the press, et al) will tell us so, perhaps with some help from you. But we've been designing this stuff for four years. Another round of design at this point is unlikely to improve anything. It's time to kick the protocols into the pool and see if they float. --Rob From owner-dns-security Thu Dec 19 09:53:58 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA15402 for dns-security-outgoing; Thu, 19 Dec 1996 09:52:21 -0500 (EST) Date: Thu, 19 Dec 1996 09:50:06 -0500 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9612190950.ZM12623@seawind.bellcore.com> In-Reply-To: Masataka Ohta "Re: key revocation (continued)" (Dec 19, 6:26pm) References: <199612190926.SAA11581@necom830.hpcl.titech.ac.jp> X-Mailer: Z-Mail (3.2.1 10oct95) To: Masataka Ohta Subject: Re: key revocation (continued) Cc: dns-security@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-dns-security@ex.tis.com Precedence: bulk >> it is designed to fit within the existing DNS schema, >> which relies on timers for data refreshing. > >The existing DNS schema is friendly to key revocation. Well, let me cast a voice of support for the existing draft. I have some experience with the key revocation problem, based on our attempt to make X.509 key revocation work in the European Password project. To put it briefly, the revocation list approach is a lazy dog. It is a dog because it impose extra treatment each time you check a key. You have to go fetch the revocation list, check that it is the last one, etc. The impact on performances is by no means small. It is a lazy dog because it just cannot be guaranteed to work. There are umpteen denial of service type attacks that can be mounted so you will not have access to the most recent revocation list. You will then be faced with a choice to either take risks or wait forever. On the other hand, the current DNS security approach allows you to contain the risk by limiting the time validity of a given key. Managers will be aware, precisely because there is no revocation mechanism, that validty dates should be left short. That is, IMHO, a good design. -- Christian Huitema From owner-dns-security Thu Dec 19 10:42:01 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA15737 for dns-security-outgoing; Thu, 19 Dec 1996 10:41:44 -0500 (EST) Message-Id: <199612191544.KAA00110@itivax.fv.com> X-Mailer: exmh version 1.6.9 8/22/96 To: namedroppers@internic.net, dns-security@tis.com From: Steve Simmons Subject: Re: draft Joint DNSSEC/DNSIND Meeting Minutes Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 19 Dec 1996 10:44:30 -0500 Sender: owner-dns-security@ex.tis.com Precedence: bulk While I realize that concensus != voting, I'm nonetheless going to break my silence and vote for the separation of the issues. As someone said, it's time to throw the baby into the pool and see if it swims. From owner-dns-security Thu Dec 19 11:33:32 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA16070 for dns-security-outgoing; Thu, 19 Dec 1996 11:32:46 -0500 (EST) X-Sender: lewis@pop.hq.tis.com Message-Id: In-Reply-To: <199612191544.KAA00110@itivax.fv.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 18 Dec 1996 11:39:55 -0500 To: namedroppers@internic.net, dns-security@tis.com From: Edward Lewis Subject: Stirring the fire of consensus (was Re: draft...Minutes) Cc: lewis@tis.com Sender: owner-dns-security@ex.tis.com Precedence: bulk At 10:44 AM -0500 12/19/96, Steve Simmons wrote: >my silence and vote for the separation of the issues. As someone said, >it's time to throw the baby into the pool and see if it swims. Skimming RFC2026, Proposed Standards are stable, have made design choices, been reviewed, and are deemed valuable. IMHO these drafts meet these criteria. That RFC also goes on to say that further experience may result in a change or retraction of the spec. As an implementor of this already, I anticipate some changes. The drafts are not ready for Draft Standard - there aren't multiple interoperable implementations yet - much less Internet Standards. I can't see how anyone would want to delay moving the documents forward. Even Masataka Ohta! If there is a weakness in the specification, it will become more apparent as independent folks try to implement and deploy it. Relax - this only the first step towards a casting in concrete. Currently I am implementing in a near vacuum, and I'm not smart enough to do this. (Just myself and one other at this location, I only hear rumors of others working on the code too.) Ohta has already noted that: > On Tue, 26 Nov 1996, Masataka Ohta wrote: > > I'm afraid you misunderstand the Internet. Obviously he would support getting far more knowledgeable folks than I to join in. I welcome others to try their hand at the implementation - something a Proposed Standard RFC would presumably encourage. I'd certainly like to hear other's interpretation of the details in the specification. BTW, I do include Ohta's comment about me in total sarcasm. I do so understand all of the Internet: OSI, Ada, *and* Appletalk! ;) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: 301-854-5794 Email: lewis@tis.com From owner-dns-security Thu Dec 19 19:18:34 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA18723 for dns-security-outgoing; Thu, 19 Dec 1996 19:15:49 -0500 (EST) From: Masataka Ohta Message-Id: <199612200015.JAA13083@necom830.hpcl.titech.ac.jp> Subject: Re: draft Joint DNSSEC/DNSIND Meeting Minutes To: scs@aa.fv.com (Steve Simmons) Date: Fri, 20 Dec 96 9:14:56 JST Cc: namedroppers@internic.net, dns-security@tis.com In-Reply-To: <199612191544.KAA00110@itivax.fv.com>; from "Steve Simmons" at Dec 19, 96 10:44 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-dns-security@ex.tis.com Precedence: bulk > While I realize that concensus != voting, Whichever you might want, we need the WG thoroughly understand the issue. > I'm nonetheless going to break > my silence and vote for the separation of the issues. For the separation of the issues? So far, there is no one against it. But, the question is whether THE TECHNICAL CHANGE is possible and 1still keeps the protocol(s) correct, efficient, satisfiable, meaningful, operational etc. No understanding, no voting nor consensus. Right? And you are the living evidence second to James, the chair, that there is no understanding. Masataka Ohta From owner-dns-security Thu Dec 19 19:23:34 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA18769 for dns-security-outgoing; Thu, 19 Dec 1996 19:22:18 -0500 (EST) From: Masataka Ohta Message-Id: <199612200023.JAA13127@necom830.hpcl.titech.ac.jp> Subject: Re: key revocation (continued) To: huitema@bellcore.com (Christian Huitema) Date: Fri, 20 Dec 96 9:23:12 JST Cc: mohta@necom830.hpcl.titech.ac.jp, dns-security@tis.com In-Reply-To: <9612190950.ZM12623@seawind.bellcore.com>; from "Christian Huitema" at Dec 19, 96 9:50 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-dns-security@ex.tis.com Precedence: bulk Cristian; > >> it is designed to fit within the existing DNS schema, > >> which relies on timers for data refreshing. > > > >The existing DNS schema is friendly to key revocation. > Well, let me cast a voice of support for the existing draft. I have some > experience with the key revocation problem, based on our attempt to make > X.509 key revocation work in the European Password project. To put it > briefly, the revocation list approach is a lazy dog. It seems to me that you are assuming that X.509 has done its job perfectly well. You also assumes that DNS is not a lazy dog. Are you so sure that your assumptions are sound? > It is a dog because it impose extra treatment each time you check a key. > You have to go fetch the revocation list, check that it is the last one, > etc. The impact on performances is by no means small. What's wrong with you is that you "check that it is the last one". What we need to check, according to the lazy nature of "THE EXISTING DNS SCHEMA" is that the revocation list is "reasonably recent". And, "how recent" is determined zone by zone. That's all. Still, it's better than frequently resigining everything. > It is a lazy dog because it just cannot be guaranteed to work. When dealing with a lazy dog such as DNS, be lazy, check lazily. That's the exsiting DNS schema. > On the other hand, the current DNS security approach allows you to contain > the risk by limiting the time validity of a given key. Managers will be > aware, precisely because there is no revocation mechanism, that validty > dates should be left short. That is, IMHO, a good design. The problem without CRL is that resigning must be so frequent, which is an operational problem. It is not realistic to re-sign all the zones under ".com" everyday. Masataka Ohta From owner-dns-security Sat Dec 21 02:44:33 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA28938 for dns-security-outgoing; Sat, 21 Dec 1996 02:40:42 -0500 (EST) From: Masataka Ohta Message-Id: <199612210742.QAA01170@necom830.hpcl.titech.ac.jp> Subject: Re: Stirring the fire of consensus (was Re: draft...Minutes) To: lewis@tis.com (Edward Lewis) Date: Sat, 21 Dec 96 16:41:45 JST Cc: namedroppers@internic.net, dns-security@tis.com, lewis@tis.com In-Reply-To: ; from "Edward Lewis" at Dec 18, 96 11:39 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-dns-security@ex.tis.com Precedence: bulk Edward; > I can't see how anyone would want to delay moving the documents forward. > Even Masataka Ohta! The forward direction for bad specifications are, of course, disposal of them. Masataka Ohta From owner-dns-security Tue Dec 24 10:33:35 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA20894 for dns-security-outgoing; Tue, 24 Dec 1996 10:31:27 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce cc: dns-security@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnssec-update-03.txt Date: Tue, 24 Dec 1996 09:47:15 -0500 Message-ID: <9612240947.aa07239@ietf.org> Sender: owner-dns-security@ex.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Security Working Group of the IETF. Title : Secure Domain Name System Dynamic Update Author(s) : D. Eastlake Filename : draft-ietf-dnssec-update-03.txt Pages : 13 Date : 12/23/1996 Domain Name System (DNS) protocol extensions have been defined to authenticate the data in DNS and provide key distribution services (draft-ietf-dnssec-secext-10.txt). DNS Dynamic Update operations have also been defined (draft-ietf-dnsind-dynDNS-*.txt>, but without a detailed description of security for the update operation. This draft describes how to use DNSSEC digital signatures covering requests and data to secure updates and restrict updates to those authorized to perform them as indicated by the updater's possession of cryptographic keys. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnssec-update-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-update-03.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dnssec-update-03.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19961223140142.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-update-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-update-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961223140142.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dns-security Tue Dec 24 12:02:51 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA21284 for dns-security-outgoing; Tue, 24 Dec 1996 12:01:41 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <9612190950.ZM12623@seawind.bellcore.com> References: Masataka Ohta "Re: key revocation (continued)" (Dec 19, 6:26pm) <199612190926.SAA11581@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 24 Dec 1996 12:03:20 -0500 To: huitema@bellcore.com (Christian Huitema) From: Stephen Kent Subject: Re: key revocation (continued) Cc: dns-security@tis.com Sender: owner-dns-security@ex.tis.com Precedence: bulk Christian, I think you overstate the case against CRLs. With intelligent caching (using the next issue date contained in a CRL), one can probably have adequate confidence in the recency of a CRL for many applications without constantly fetching CRLs. Your characterization of the shortcomings of CRLS is accurate for the worst case, but the Internet works well with many solutions that would be horrible in worsty case scenarios. Note that the alternative, short cert lifetimes, trades frequent fetching of CRLs for frequent fetching of certs. Since a given CRL typically covers many certs, this is not necessarily a great tradeoff in practice. Moreover, the model of a short lifetime certs, can be implemented in X.509, on a per cert basis. So, if a CA believes that a particular group of certificates deserve to have short validity intervals for use in an access control (vs. non-repudiation) context, one can make the system work that way. Steve