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