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