From owner-dns-security Mon Dec 1 22:52:43 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA03581 for dns-security-outgoing; Mon, 1 Dec 1997 22:48:31 -0500 (EST) X-Authentication-Warning: allmalt.cs.uwm.edu: xwang owned process doing -bs Date: Mon, 1 Dec 1997 21:59:25 -0600 (CST) From: "Steven(Xunhua) Wang" cc: dns-security@tis.com In-Reply-To: <199711282133.QAA29981@dcl.MIT.EDU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk >From the DNS Security Extension draft, it seems that for a zone, an outside resolver only needs to trust the Zone Manager, not the DNS servers, for that zone(but the outside resolver can get the public key certificate signed by the Zone). So, the draft recommends that Zone secret key be kept off-line, while DNS servers' keys can be kept for on-line(for DNS zone transfer). I wonder: If there are several DNS servers for a zone, we can distribute the Zone secret Key among these servers. Of course, keeping them off-line is a good idea for security, but inconvenient for management and zone resign. Employing Threshold Cryptography(note threshold cryptography should be differentiated from the threshold scheme), such as threshold RSA, we can reach this goal. Of course, you can say that this is out of the scope of the draft. Xunhua From owner-dns-security Wed Dec 3 13:31:21 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA16064 for dns-security-outgoing; Wed, 3 Dec 1997 13:26:13 -0500 (EST) Message-Id: <199712031832.NAA25022@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: dns-security@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-dnssec-secext2-02.txt Date: Wed, 03 Dec 1997 13:32:04 -0500 Sender: owner-dns-security@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Security Working Group of the IETF. Title : Domain Name System Security Extensions Author(s) : D. Eastlake Filename : draft-ietf-dnssec-secext2-02.txt Pages : 49 Date : 02-Dec-97 Extensions to the Domain Name System (DNS) are described that provide data integrity and authentication 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 also be provided even through non-security aware DNS servers in many cases. The extensions provide for the storage of authenticated public keys in the DNS. This storage of keys can support general public key distribution services 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 and requests. This document incorporates feedback from early implementors and potential users on RFC 2065. 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-secext2-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-secext2-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dnssec-secext2-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: <19971202161344.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-secext2-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-secext2-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971202161344.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dns-security Wed Dec 3 18:22:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA17798 for dns-security-outgoing; Wed, 3 Dec 1997 18:21:17 -0500 (EST) To: dns-security@tis.com Subject: to get DNSSafe from RSA? X-Mailer: Mew version 1.91 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19971203153122C.doi@sfc.wide.ad.jp> Date: Wed, 03 Dec 1997 15:31:22 -0800 From: Yusuke DOI X-Dispatcher: imput version 970918 Lines: 36 Sender: owner-dns-security@ex.tis.com Precedence: bulk Hi, DNS-wizards. I'm Yusuke DOI, now working on my own implementation of DynDNS and I'm now looking forward for DNSSec/Update. I found that phrase about DNSSafe on the web(www.rsa.com) Where do I get it? DNSsafe is available from the Internet Software Consortium (www.isc.org) as part of the BIND protocol distribution (BIND is a part of DNS). The ISC has for years provided free source code to the industry for implementing BIND, DHCP and other protocols. The ISC will provide all updates and support directly. but that document shows no other way than waiting BIND. I hope beta release will be pretty soon. BTW, can I use DNSSafe bundled with BIND for my implementation? I think there can be some contract between ISC and RSA. Or shall I use some other implementations? like RSAREF(oh I can't export it!) or something used in PGP? I think it's too troublesome for me to make my own implementation with PKCS#1. I'll go to this IETF but I don't have any implementation that I can show you... I think I must make it next time... :[ Regards, Yusuke DOI -- E-mail: doi@sfc.wide.ad.jp WIDE Project Mosquitonet Project Keio Univ. Murai Lab. Stanford Univ. From owner-dns-security Thu Dec 4 04:36:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA21033 for dns-security-outgoing; Thu, 4 Dec 1997 04:34:17 -0500 (EST) Date: Thu, 4 Dec 1997 04:45:24 -0500 (EST) From: "Donald E. Eastlake 3rd" To: "Steven(Xunhua) Wang" Cc: dns-security@tis.com Subject: Re: your mail In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk This looks like the middle of a conversation where I haven't seen the previous messages... On Mon, 1 Dec 1997, Steven(Xunhua) Wang wrote: > Date: Mon, 1 Dec 1997 21:59:25 -0600 (CST) > From: Steven(Xunhua) Wang > Cc: dns-security@tis.com > > >From the DNS Security Extension draft, it seems that for a zone, an > outside resolver only needs to trust the Zone Manager, not the DNS > servers, for that zone(but the outside resolver can get the public key > certificate signed by the Zone). So, the draft recommends that Zone > secret key be kept off-line, while DNS servers' keys can be kept for > on-line(for DNS zone transfer). I wonder: I'm not sure what you are talking about when you say "certificate" above... Keep in mind that you might also get DNS data from a cache so you really want the zone manager signature to go long with the data. Any of the various kinds of private keys potentially involved can be kept on line if you want. But unless you need to do real time signatures with them, it is more secure to keep them off line. Everything in a zone transfer is secured by public key signatures derived from the zone manager except NS and glue A/AAAA records at delegation points, which are non-authoritative. It is only if you want to secure them also that you need to use DNS transaction security which depends on having either the server private key (if you are using SIG) or the server/resolver shared secret key (if you are using TSIG) on line. > If there are several DNS servers for a zone, we can distribute the > Zone secret Key among these servers. Of course, keeping them off-line > is a good idea for security, but inconvenient for management and zone > resign. Employing Threshold Cryptography(note threshold > cryptography should be differentiated from the threshold scheme), > such as threshold RSA, we can reach this goal. Of course, you can > say that this is out of the scope of the draft. I assume you mean the zone private (not secret) key. You only resign the zone one place, even if you do it on line at the primary server and dynamic updates also only happen at the primary server. I can't see why, even if you decide to have the zone manager key on-line, you would ever have it on more than one machine... Again, I'm not exactly sure what you are talking about. Most cases where I have seen "threshold cryptography" used, they were refering to some sort of "n of m" voting scheme which sounds like you are trying to do away with the single primary server concept currently in DNS. Indeed, the goal of the dnssec working group was to secure the existing DNS, not to make that sort of fundamental change. > Xunhua Donald ===================================================================== Donald E. Eastlake 3rd +1 978-287-4877(tel) dee@cybercash.com 318 Acton Street +1 978-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.privacy.org/ipc From owner-dns-security Thu Dec 4 07:35:03 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA21924 for dns-security-outgoing; Thu, 4 Dec 1997 07:33:18 -0500 (EST) Message-Id: <3.0.5.32.19971203163925.00947ae0@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 03 Dec 1997 16:39:25 -0800 To: dns-security@tis.com From: Paul Hoffman / IMC Subject: DNSConnect to Test Interoperability of Advanced DNS Features Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-dns-security@ex.tis.com Precedence: bulk Greetings. This is a one-time announcement of an interoperability event that the dnssec folks may be interested in. Please excuse the interruption. IMC will host DNSConnect 1, an interoperability event that is aimed at the many new DNS technologies that have been recently deployed. Like IMC's MailConnect and DirConnect events, DNSConnect will be a technical testing event whose main goal is to help companies assure interoperability of their software. The one-day event will take place January 27, 1998, in San Jose, California. It will cover three advanced areas of the DNS that are now being implemented: * Dynamic DNS * Secure DNS * DHCP DNS interactions Full information on the event is available at . --Paul Hoffman, Director --Internet Mail Consortium From owner-dns-security Thu Dec 4 11:47:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA23414 for dns-security-outgoing; Thu, 4 Dec 1997 11:45:27 -0500 (EST) X-Authentication-Warning: allmalt.cs.uwm.edu: xwang owned process doing -bs Date: Thu, 4 Dec 1997 10:55:22 -0600 (CST) From: "Steven(Xunhua) Wang" To: "Donald E. Eastlake 3rd" cc: dns-security@tis.com Subject: Re: your mail In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk On Thu, 4 Dec 1997, Donald E. Eastlake 3rd wrote: > This looks like the middle of a conversation where I haven't seen the > previous messages... > > On Mon, 1 Dec 1997, Steven(Xunhua) Wang wrote: > > > Date: Mon, 1 Dec 1997 21:59:25 -0600 (CST) > > From: Steven(Xunhua) Wang > > Cc: dns-security@tis.com > > > > >From the DNS Security Extension draft, it seems that for a zone, an > > outside resolver only needs to trust the Zone Manager, not the DNS > > servers, for that zone(but the outside resolver can get the public key > > certificate signed by the Zone). So, the draft recommends that Zone > > secret key be kept off-line, while DNS servers' keys can be kept for > > on-line(for DNS zone transfer). I wonder: > > I'm not sure what you are talking about when you say "certificate" > above... Sorry for the misunderstanding! I mean the public key. > Keep in mind that you might also get DNS data from a cache so you really > want the zone manager signature to go long with the data. Yes, I know. Thanks for the reminding! > Any of the various kinds of private keys potentially involved can be kept > on line if you want. But unless you need to do real time signatures with > them, it is more secure to keep them off line. Everything in a zone > transfer is secured by public key signatures derived from the zone > manager except NS and glue A/AAAA records at delegation points, which are > non-authoritative. It is only if you want to secure them also that you > need to use DNS transaction security which depends on having either the > server private key (if you are using SIG) or the server/resolver shared > secret key (if you are using TSIG) on line. > > > If there are several DNS servers for a zone, we can distribute the > > Zone secret Key among these servers. Of course, keeping them off-line > > is a good idea for security, but inconvenient for management and zone > > resign. Employing Threshold Cryptography(note threshold > > cryptography should be differentiated from the threshold scheme), > > such as threshold RSA, we can reach this goal. Of course, you can > > say that this is out of the scope of the draft. > > I assume you mean the zone private (not secret) key. You are right. When we talk about public key, the 'secret' key should be refered to the private key, right?(maybe I am wrong again, sorry for that). > You only resign the > zone one place, even if you do it on line at the primary server and > dynamic updates also only happen at the primary server. I can't see why, > even if you decide to have the zone manager key on-line, you would ever > have it on more than one machine... > > Again, I'm not exactly sure what you are talking about. Most cases where > I have seen "threshold cryptography" used, they were refering to some > sort of "n of m" voting scheme which sounds like you are trying to do > away with the single primary server concept currently in DNS. I mean that resigning off-line REGULARLY for a zone manager may be boring. This process can be done automatically. Of course, keeping the Zone private key on line in a single place, for example in the server, may be dangerous(we even have no need to trust the DNS server). A solution is that the zone private key can be distributed among DNS servers using threshold cryptography(what each server has is not a copy of the zone private key, but a secret share; the main difference between threshold cryptography and threshold scheme is that you have NO need to recover the zone private key during the whole zone resigning process). Yes, I mean multiple name servers here. So, this is out of the scope of the drafts, right? > Indeed, > the goal of the dnssec working group was to secure the existing DNS, not > to make that sort of fundamental change. Sorry for that. Forget about it. From owner-dns-security Fri Dec 5 13:10:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA01556 for dns-security-outgoing; Fri, 5 Dec 1997 13:05:45 -0500 (EST) X-Sender: lewis@pop.hq.tis.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 5 Dec 1997 13:16:08 -0500 To: dns-security@tis.com From: Edward Lewis Subject: A draft pseudo-announcement Cc: lewis@tis.com Sender: owner-dns-security@ex.tis.com Precedence: bulk The secrateriat should be announcing the following draft, but I haven't seen a message yet...(it's on their servers though): ftp://ietf.org/internet-drafts/draft-lewis-dnssig-authorization-00.txt I guess I should paste a copy of the abstract here - but I'm too lazy ;). The draft is about the relationship of KEYs to RRsets in the verification process. I.e., a verififcation is good if the crypto-op is good AND you trust that the key used is trustworthy enough to speak for the data. The draft also outlines steps used in secure resolution (based on an implementation). -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: +1 301-854-5794 Email: lewis@tis.com "Serenity now, insanity later" -- Lloyd Braun Opinions expressed are property of my evil twin, not my employer. From owner-dns-security Fri Dec 5 14:03:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA02162 for dns-security-outgoing; Fri, 5 Dec 1997 14:03:44 -0500 (EST) Message-Id: <199712051808.NAA18955@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org cc: dns-security@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-lewis-dnssig-authorization-00.txt Date: Fri, 05 Dec 1997 13:08:34 -0500 Sender: owner-dns-security@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : DNSSEC Signature and Data Verification Semantics Author(s) : O. Gudmundsson, E. Lewis Filename : draft-lewis-dnssig-authorization-00.txt Pages : 12 Date : 04-Dec-97 This draft discusses authorization models for DNSSEC that can be used to determine the relationship of a KEY RR and a DNS RRset in the validation process. Is this key trusted to sign for this data? Is this data trusted because it was signed by this key? This draft defines a number of different policies that can be used and what the signing authority of keys are in each. This draft also addresses what steps are recommended in the secure DNS resolution process and how the authorization policy is put to use. The ideas and definitions expressed here are based on the authors experience in implementing a reference secure resolver. 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-lewis-dnssig-authorization-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-lewis-dnssig-authorization-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-lewis-dnssig-authorization-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: <19971204163650.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lewis-dnssig-authorization-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-lewis-dnssig-authorization-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971204163650.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dns-security Fri Dec 5 16:39:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA03581 for dns-security-outgoing; Fri, 5 Dec 1997 16:38:51 -0500 (EST) Reply-To: James M Galvin To: dns-security@ex.tis.com Subject: Draft Agenda for Meeting, Tue, Dec 9, 1pm-2pm MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11890.881357415.1@commerce.net> Date: Fri, 05 Dec 1997 16:30:15 -0500 From: James M Galvin Message-ID: <9712051530.aa11894@lists.Commerce.Net> Sender: owner-dns-security@ex.tis.com Precedence: bulk Speaking as Chair of the Secure DNS Working Group: Just in case you haven't noticed, there is a meeting scheduled for the Secure DNS Working Group on Tuesday, December 9, from 1pm-2pm. Yes, it is only a one hour meeting but our meetings have historically been short and, well, given the lack of activity on the mailing list I don't expect this to be different. We have a lot of documents on the table. It's time to move them up! So, I figure one of two things is true: either the documents are fine and should move up or people need a reason to check if the documents are fine. Here's your reason. I'm declaring "Working Group Last Call" on several of our documents, starting today, Dec 5, and ending in two weeks, friday, Dec 19. I will send a separate note for each document to this list; please respond to the appropriate message if you have objections. This deadline is set. Unless I hear an outcry of complaints, it stays. One or two people is not going to do it. Similarly, unless there is a significant technical issue, we will devote as little time as possible during the meeting to the "last call" documents. Since there's been no discussion on the mailing list I know it's safe to assume this won't be a problem. What we will devote time to is the new documents to see if we can jumpstart some discussion and make some forward progress with them. Having said all that, here's the agenda: Implementation Reports TIS Gilmore/Vixie? Microsoft? IBM? Others? Last Call Documents: draft-ietf-dnssec-secext2-02.txt Domain Name System Security Extensions, Eastlake revision to RFC2065, currently at Proposed Standard will recycle at Proposed Standard draft-ietf-dnssec-certs-01.txt (expires, May 1998) Storing Certificates in the Domain Name System, Eastlake and Gudmundsson to be submitted for Proposed draft-ietf-dnssec-indirect-key-01.txt (expires, May 1998) Indirect KEY RRs in the Domain Name System, Eastlake to be submitted for Proposed draft-ietf-dnssec-dhk-01.txt (expires, May 1998) Storage of Diffie-Hellman Keys in the Domain Name System, Eastlake to be submitted for Proposed draft-ietf-dnssec-dss-01.txt (expires, May 1998) DSA KEYs and SIGs in the Domain Name System, Eastlake to be submitted for Proposed draft-ietf-dnssec-as-map-05.txt (expires, January 1998) Mapping Autonomous Systems Number into the Domain Name System, Eastlake to be submitted for Proposed draft-ietf-dnssec-ddi-02.txt (expired, September 1997) Detached Domain Name System Information, Eastlake to be submitted for Proposed Other documents draft-ietf-dnssec-in-key-00.txt (expired, September 1997) The DNS Inverse Key Domain, Eastlake Shall we officially kill this proposal? draft-ietf-dnssec-ar-00.txt (expires, May 1998) DNSsec Authentication Referral Record (AR), Watson draft-ietf-dnssec-key-handling-00.txt (expires, May 1998) Zone KEY RRSet Signing Procedure, Lewis and Gudmundsson draft-lewis-dnsnxt-semantics-01.txt (expired, August 1997) Semantics of DNS NXT Resource Records, Lewis and Gudmundsson draft-lewis-dnssig-authorization-00.txt (expires, May 1998) DNSSEC Signature and Data Verification Semantics, Lewis and Gudmundsson There's also secure dynamic update, but that will have to wait for the next revision of the document. See you on tuesday (and virtually), Jim -- James M. Galvin Executive Director, Trust and Security CommerceNet Consortium +1 410.203.2707 3209A Corporate Court +1 410.203.2709 FAX Ellicott City, MD 21042 http://www.commerce.net From owner-dns-security Fri Dec 5 16:39:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA03587 for dns-security-outgoing; Fri, 5 Dec 1997 16:38:56 -0500 (EST) Reply-To: James M Galvin To: dns-security@ex.tis.com Subject: WG Last Call: draft-ietf-dnssec-indirect-key-01.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11945.881357926.1@commerce.net> Date: Fri, 05 Dec 1997 16:38:46 -0500 From: James M Galvin Message-ID: <9712051538.aa11949@lists.Commerce.Net> Sender: owner-dns-security@ex.tis.com Precedence: bulk Consider this an official declaration of a last call that expires Friday, December 19, for: Indirect KEY RRs in the Domain Name System, Eastlake All those opposed speak now. -- James M. Galvin Executive Director, Trust and Security CommerceNet Consortium +1 410.203.2707 3209A Corporate Court +1 410.203.2709 FAX Ellicott City, MD 21042 http://www.commerce.net From owner-dns-security Fri Dec 5 16:39:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA03607 for dns-security-outgoing; Fri, 5 Dec 1997 16:39:50 -0500 (EST) Reply-To: James M Galvin To: dns-security@ex.tis.com Subject: WG Last Call: draft-ietf-dnssec-dhk-01.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11955.881357999.1@commerce.net> Date: Fri, 05 Dec 1997 16:40:00 -0500 From: James M Galvin Message-ID: <9712051540.aa11962@lists.Commerce.Net> Sender: owner-dns-security@ex.tis.com Precedence: bulk Consider this an official declaration of a last call that expires Friday, December 19, for: Storage of Diffie-Hellman Keys in the Domain Name System, Eastlake All those opposed speak now. -- James M. Galvin Executive Director, Trust and Security CommerceNet Consortium +1 410.203.2707 3209A Corporate Court +1 410.203.2709 FAX Ellicott City, MD 21042 http://www.commerce.net From owner-dns-security Fri Dec 5 16:39:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA03620 for dns-security-outgoing; Fri, 5 Dec 1997 16:39:55 -0500 (EST) Reply-To: James M Galvin To: dns-security@ex.tis.com Subject: WG Last Call: draft-ietf-dnssec-secext2-02.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11923.881357749.1@commerce.net> Date: Fri, 05 Dec 1997 16:35:49 -0500 From: James M Galvin Message-ID: <9712051535.aa11927@lists.Commerce.Net> Sender: owner-dns-security@ex.tis.com Precedence: bulk Consider this an official declaration of a last call that expires Friday, December 19, for: Domain Name System Security Extensions, Eastlake revision to RFC2065, currently at Proposed Standard will recycle at Proposed Standard All those opposed speak now. -- James M. Galvin Executive Director, Trust and Security CommerceNet Consortium +1 410.203.2707 3209A Corporate Court +1 410.203.2709 FAX Ellicott City, MD 21042 http://www.commerce.net From owner-dns-security Fri Dec 5 16:40:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA03647 for dns-security-outgoing; Fri, 5 Dec 1997 16:40:51 -0500 (EST) Reply-To: James M Galvin To: dns-security@ex.tis.com Subject: WG Last Call: draft-ietf-dnssec-certs-01.txt (expires, May 1998) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11935.881357836.1@commerce.net> Date: Fri, 05 Dec 1997 16:37:16 -0500 From: James M Galvin Message-ID: <9712051537.aa11939@lists.Commerce.Net> Sender: owner-dns-security@ex.tis.com Precedence: bulk Consider this an official declaration of a last call that expires Friday, December 19, for: Storing Certificates in the Domain Name System, Eastlake and Gudmundsson All those opposed speak now. -- James M. Galvin Executive Director, Trust and Security CommerceNet Consortium +1 410.203.2707 3209A Corporate Court +1 410.203.2709 FAX Ellicott City, MD 21042 http://www.commerce.net From owner-dns-security Fri Dec 5 16:40:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA03648 for dns-security-outgoing; Fri, 5 Dec 1997 16:40:52 -0500 (EST) Reply-To: James M Galvin To: dns-security@ex.tis.com Subject: WG Last Call: draft-ietf-dnssec-dss-01.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11987.881358082.1@commerce.net> Date: Fri, 05 Dec 1997 16:41:22 -0500 From: James M Galvin Message-ID: <9712051541.aa11991@lists.Commerce.Net> Sender: owner-dns-security@ex.tis.com Precedence: bulk Consider this an official declaration of a last call that expires Friday, December 19, for: DSA KEYs and SIGs in the Domain Name System, Eastlake All those opposed speak now. -- James M. Galvin Executive Director, Trust and Security CommerceNet Consortium +1 410.203.2707 3209A Corporate Court +1 410.203.2709 FAX Ellicott City, MD 21042 http://www.commerce.net From owner-dns-security Fri Dec 5 16:41:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA03697 for dns-security-outgoing; Fri, 5 Dec 1997 16:41:52 -0500 (EST) Reply-To: James M Galvin To: dns-security@ex.tis.com Subject: WG Last Call: draft-ietf-dnssec-as-map-05.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11998.881358150.1@commerce.net> Date: Fri, 05 Dec 1997 16:42:30 -0500 From: James M Galvin Message-ID: <9712051542.aa12002@lists.Commerce.Net> Sender: owner-dns-security@ex.tis.com Precedence: bulk Consider this an official declaration of a last call that expires Friday, December 19, for: Mapping Autonomous Systems Number into the Domain Name System, Eastlake All those opposed speak now. -- James M. Galvin Executive Director, Trust and Security CommerceNet Consortium +1 410.203.2707 3209A Corporate Court +1 410.203.2709 FAX Ellicott City, MD 21042 http://www.commerce.net From owner-dns-security Fri Dec 5 16:41:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA03696 for dns-security-outgoing; Fri, 5 Dec 1997 16:41:51 -0500 (EST) Reply-To: James M Galvin To: dns-security@ex.tis.com Subject: WG Last Call: draft-ietf-dnssec-ddi-02.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12009.881358227.1@commerce.net> Date: Fri, 05 Dec 1997 16:43:47 -0500 From: James M Galvin Message-ID: <9712051543.aa12013@lists.Commerce.Net> Sender: owner-dns-security@ex.tis.com Precedence: bulk Consider this an official declaration of a last call that expires Friday, December 19, for: Detached Domain Name System Information, Eastlake to be submitted for Proposed All those opposed speak now. -- James M. Galvin Executive Director, Trust and Security CommerceNet Consortium +1 410.203.2707 3209A Corporate Court +1 410.203.2709 FAX Ellicott City, MD 21042 http://www.commerce.net From owner-dns-security Sun Dec 7 22:04:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA19346 for dns-security-outgoing; Sun, 7 Dec 1997 22:00:34 -0500 (EST) Message-Id: <199712080312.TAA28533@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: dns-security@ex.tis.com, gnu@toad.com Subject: Re: WG Last Call: draft-ietf-dnssec-dss-01.txt In-reply-to: <9712051541.aa11991@lists.Commerce.Net> Date: Sun, 07 Dec 1997 19:12:50 -0800 From: John Gilmore Sender: owner-dns-security@ex.tis.com Precedence: bulk This I-D should not specify the format of the KEY record "flag bits", etc. It should only specify the portion of the KEY record that is algorithm-specific (the "public key" field). In particular, the secext2 draft has changed the rest of the KEY record (so that additional flags can optionally appear), but the dss draft has not been changed to conform. Along those lines, I would suggest revising the text and diagram in section 2, which currently looks like this: 2. DSA KEY Resource Records DSA public keys are stored in the DNS as KEY RRs using algorithm number 3 (see RFC 2065). The structure of the RDATA portion of this RR is as shown below. The first 4 octets, including the flags, protocol, and algorithm fields are common to all KEY RRs. The remainder, from Q through Y is the "public key" part of the KEY RR. The period of key validity is not in the KEY RR but is indicated by the SIG RR(s) which signs and authenticates the KEY RR(s) at that domain name. 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | flags | protocol | algorithm=3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Q (20 octets) | | .../ |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I suggest revising it to look like the public key description for the MD5/RSA algorithm in section 3.2.1 of the secext2-02 draft: 3.2.1 The MD5/RSA Algorithm If the type flag field does not have the "no key" value and the algorithm field is 1, indicating the MD5/RSA algorithm, the public key field is structured as follows: 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | pub exp length| public key exponent / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | / +- modulus / | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ The SIG description is fine in this regard; it only attempts to describe "the signature portion of the SIG RR RDATA area", referring readers to RFC 2065 for the rest of the fields. I find the "varying width bit descriptions" format awkward and confusing (the "T" field in the first sample above). Has this become common in other RFC's and drafts? The security considerations section should reference the Young & Yung paper from Crypto '97 on high bandwidth covert channels in DSA, as well as Schneier's older coverage. "The Prevalence of Kleptographic Attacks on Discrete-Log Based Schemes Using a Prime Order Subgroup", Adam Young and Moti Yung, Advances in Cryptology - Proceedings, CRYPTO '97, page 264. Berlin: Springer-Verlag, 1997. ISBN 3-540-63384-7. For some reason the I-D is called "dss" (Digital Signature Standard), but throughout the document the algorithm is called DSA (Digital Signature Algorithm). I agree that the draft should reference the algorithm, not the standard. If the draft proceeds to an RFC, no trace of "dss" should remain in the RFC (except the citation to the FIPS). John From owner-dns-security Sun Dec 7 22:40:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA19574 for dns-security-outgoing; Sun, 7 Dec 1997 22:40:10 -0500 (EST) Message-Id: <199712080352.TAA28688@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: dns-security@ex.tis.com, gnu@toad.com Subject: Re: WG Last Call: draft-ietf-dnssec-certs-01.txt In-reply-to: <9712051537.aa11939@lists.Commerce.Net> Date: Sun, 07 Dec 1997 19:52:26 -0800 From: John Gilmore Sender: owner-dns-security@ex.tis.com Precedence: bulk This draft seems to exist for two purposes, one of which is somewhat worthwhile, and the other of which is worthless and dangerous. The somewhat worthwhile purpose is to provide a standard way to publish and retrieve non-DNS-formatted certificates from the DNS. (For example, PGP keys and signatures, or X.509 certs). However, such certificates can already be stored and retrieved in KEY RR's. Private or newly standardized "algorithm" and "protocol" fields can be used for this. The apparent reason for having a different RR type for these, is so that a query for KEY RR's (e.g. when validating a DNS zone) won't retrieve unwanted X.509 certificates and such. The proposed solution doesn't solve the problem, though. Ideally an application would like to be able to query the DNS for just the key format(s) that it understands. E.g. an X.509 mail application will not want to see PGP keys or DNS zone keys. The CERT record merely divides the problem space in half, leaving the problem remaining in each half of the space. A real solution to the problem would be to either provide a different RR type for each kind of key or certificate (ZONEKEY, EMAILKEY, X509CERT, PGPCERT, etc), or would offer more specific DNS queries, optionally matching on RDATA fields in target RRs, instead of just on the RR type and the RR owner name. The worthless and dangerous purpose of this draft would enable the use of the same numeric public/private key pair in both X.509 certificates, and in DNS-format keys and signatures. It burns a scarce KEY record flag bit for this purpose, and also attempts to match the two records by using a hash value. In discussion with one of the authors, I've been unable to find any valid reason why anyone would ever want to do this. For example, it was proposed that you might want to use the same numeric key as a DNS zone key and an X.509 email key. But that is a very stupid idea -- who would hand the private key for their zone, to an individual person to use daily for sending and receiving email messages? A compromise of either key would compromise both, while there is no advantage to be gained from the sharing. Merely using separate zone and email keys would not only be simpler, but more secure. It was also proposed that some programs might want to use the keys from the X.509 certificates for something, but would only know how to parse DNS KEY RR's, not X.509 certs. Looked at from a software engineering point of view, this makes no sense. If a program understands X.509 keys, then it will be able to parse an X.509 key out of a KEY or CERT record in X.509 format. It does not need the key's owner to do a one-time translation of the key into DNS "algorithm 1" KEY RR format. If a program doesn't understand X.509 keys, then the presence or absence of an X.509 CERT record along with the DNS KEY RR is irrelevant to it. You might as well generate the key in DNS "algorithm 1" KEY RR format, and forget the CERT record. (The same applies to PGP keys; X.509 was just an example.) Less major comments: The I-D has numerous typos. The certificate type field is too big. 256 values should be fine. The URL private type should use a counted field rather than null termination, to make it easy to match on. Also, there is no obvious scheme for dealing with compatability, upgrades, etc. The problem is that applications looking for keys will have to examine them for an exact match with the URL that the application understands; but the URL may change over time, or several versions of certificates may need to be described by the same URL. This provides backward and forward compatability issues. Key tag field is a bad idea. It's only useful for applications which understand both the CERT and the matching KEY record; and those apps should simply use whichever record is appropriate. If for some reason an application actually needs to cross-reference between a public key in one format, and a public key in another format, it can simply do the format conversion. Providing a 16-bit hash of the key is just a premature optimization, which will encourage implementers to e.g. assume that key tags are unique, which they aren't. (TIS made this mistake.) Text representation should not use "mnemonic fields" for the cert types or algorithm types. This creates a backward compatability problem when adding new types. The CERT bit that this draft adds to the KEY RR should not exist. It should definitely not be processed as a mnemonic (when the rest of the flags field is numeric!). The rules in section 4.1 for naming CERT RR's are complicated. Examples would help immensely. John From owner-dns-security Sun Dec 7 23:59:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA20004 for dns-security-outgoing; Sun, 7 Dec 1997 23:57:46 -0500 (EST) Message-Id: <199712080510.VAA29240@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: dns-security@ex.tis.com, gnu@toad.com Subject: Re: WG Last Call: draft-ietf-dnssec-indirect-key-01.txt In-reply-to: <9712051538.aa11949@lists.Commerce.Net> Date: Sun, 07 Dec 1997 21:10:02 -0800 From: John Gilmore Sender: owner-dns-security@ex.tis.com Precedence: bulk It is not clear what problem this draft is trying to solve. The "target type" field seems to be encoding numerous separate kinds of information (e.g. the format of the location data (URL or domain name); the format of the data to be retrieved there (KEY RDATA, CERT RDATA, PKCS #1, etc); and the "type" of certificate that might be found there (PKIX, PGP, etc). Rather than encode various combinations of these, wouldn't separate fields be better? Typos. John From owner-dns-security Mon Dec 8 12:14:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA24581 for dns-security-outgoing; Mon, 8 Dec 1997 12:11:54 -0500 (EST) Message-Id: <3.0.5.32.19971208110930.00833100@localhost> X-Sender: ogud@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 08 Dec 1997 11:09:30 -0500 To: dns-security@tis.com From: Olafur Gudmundsson Subject: What parts of DNS answer does AD bit cover Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id MAA24578 Sender: owner-dns-security@ex.tis.com Precedence: bulk In testing DNSSEC we have discovered that the rules for the AD bit as stated in RFC2065 and SECEXT2 are too stringent. After discussing this with Donald, we propose the following, AD bit MUST NOT be turned off if Unsecured glue data is added to the ADDITIONAL data section. Similarly AD bit can be left on if unsigned NS are in the AUTHORITY section such as child's NS record, in many cases parent server may not have the signed records. Proposed new rule: AD bit covers ALL data in ANSWER section and AUTHORITY with the exception for Insecure NS records. AD bit does not cover ADDITIONAL DATA section. Comments Olafur -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-= Ólafur Guðmundsson (in ISO-8859-1) ogud@tis.com (work) Olafur Gudmundsson (in US ascii) ogud@acm.org (private) (301)-854-5700 Fax: x5363 From owner-dns-security Tue Dec 9 06:19:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA01360 for dns-security-outgoing; Tue, 9 Dec 1997 06:08:58 -0500 (EST) Message-ID: <19971209111923.20014.qmail@hotmail.com> X-Originating-IP: [194.133.48.111] From: "Mumtaz Siddiqui" To: dee@cybercash.com Cc: dns-security@tis.com Subject: one suggestion Content-Type: text/plain Date: Tue, 09 Dec 1997 03:19:22 PST Sender: owner-dns-security@ex.tis.com Precedence: bulk Super zone key is configured staticly in all secure zones. Would this key be kept on line. super zone key is beyond the scope of a zone, if a query is made for a zone's super-zone-key what would be the response from the sub zone? If staticly configured super zone key is required to be kept online then what about keeping other keys staticly configured for cross certifications online. My suggestion: Keep staticly configured keys online because these keys are public and sould be available to everyone. If a resolver having key of C.B.A.R (localy configured) requires key of Z.Y.X.R, right now KEY CHAINing would be done via R(i.e. ROOT). If pubkeys become online then chaining path may be small if e.g. server serving zone A or B has public key of X or Y or Z(staticly configured). Inorder to acheive this functionality resolver having C's pub key should query to server serving its superzone (B in this example) for Z.Y.X.R pub key. if server serving B has staticly configured key of Z or any of its enclosing zone then it should return it, if the server has not configured with Z or its enclosing zone key then it should simply return its own super zone key (A's key) in response, and resolver should goto server of A for the same query. if e.g. B has key of X then resolver will ask server serving zone X for Z's pubkey, and in this way two hops(A & R) will eliminate. R / \ X A / \ Y B / \ Z C If super zone key cannot be kept online then how super zone key would be retreived in KEY CHAINing? ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-dns-security Wed Dec 10 20:40:28 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA15560 for dns-security-outgoing; Wed, 10 Dec 1997 20:35:45 -0500 (EST) Date: Wed, 10 Dec 1997 20:48:34 -0500 (EST) From: "Donald E. Eastlake 3rd" To: John Gilmore Cc: dns-security@ex.tis.com Subject: Re: WG Last Call: draft-ietf-dnssec-dss-01.txt In-Reply-To: <199712080312.TAA28533@toad.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk John, I don't have any problems with your suggestions below and will incorporate them. Donald On Sun, 7 Dec 1997, John Gilmore wrote: > Date: Sun, 07 Dec 1997 19:12:50 -0800 > From: John Gilmore > To: dns-security@ex.tis.com, gnu@toad.com > Subject: Re: WG Last Call: draft-ietf-dnssec-dss-01.txt > > This I-D should not specify the format of the KEY record "flag bits", > etc. It should only specify the portion of the KEY record that is > algorithm-specific (the "public key" field). In particular, the > secext2 draft has changed the rest of the KEY record (so that > additional flags can optionally appear), but the dss draft has not > been changed to conform. > > Along those lines, I would suggest revising the text and diagram in > section 2, which currently looks like this: > > 2. DSA KEY Resource Records > > DSA public keys are stored in the DNS as KEY RRs using algorithm > number 3 (see RFC 2065). The structure of the RDATA portion of this > RR is as shown below. The first 4 octets, including the flags, > protocol, and algorithm fields are common to all KEY RRs. The > remainder, from Q through Y is the "public key" part of the KEY RR. > > The period of key validity is not in the KEY RR but is indicated by > the SIG RR(s) which signs and authenticates the KEY RR(s) at that > domain name. > > 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | flags | protocol | algorithm=3 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | T | > |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Q (20 octets) | > | .../ > |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > I suggest revising it to look like the public key description for the > MD5/RSA algorithm in section 3.2.1 of the secext2-02 draft: > > 3.2.1 The MD5/RSA Algorithm > > If the type flag field does not have the "no key" value and the > algorithm field is 1, indicating the MD5/RSA algorithm, the public > key field is structured as follows: > > 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | pub exp length| public key exponent / > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | / > +- modulus / > | / > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ > > The SIG description is fine in this regard; it only attempts to > describe "the signature portion of the SIG RR RDATA area", referring > readers to RFC 2065 for the rest of the fields. > > I find the "varying width bit descriptions" format awkward and > confusing (the "T" field in the first sample above). Has this become > common in other RFC's and drafts? > > The security considerations section should reference the Young & Yung > paper from Crypto '97 on high bandwidth covert channels in DSA, as > well as Schneier's older coverage. "The Prevalence of Kleptographic > Attacks on Discrete-Log Based Schemes Using a Prime Order Subgroup", > Adam Young and Moti Yung, Advances in Cryptology - Proceedings, CRYPTO > '97, page 264. Berlin: Springer-Verlag, 1997. ISBN 3-540-63384-7. > > For some reason the I-D is called "dss" (Digital Signature Standard), > but throughout the document the algorithm is called DSA (Digital > Signature Algorithm). I agree that the draft should reference the > algorithm, not the standard. If the draft proceeds to an RFC, no > trace of "dss" should remain in the RFC (except the citation to the > FIPS). > > John > ===================================================================== Donald E. Eastlake 3rd +1 978-287-4877(tel) dee@cybercash.com 318 Acton Street +1 978-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.privacy.org/ipc From owner-dns-security Wed Dec 10 22:38:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA16326 for dns-security-outgoing; Wed, 10 Dec 1997 22:38:05 -0500 (EST) Date: Wed, 10 Dec 1997 22:51:51 -0500 (EST) From: "Donald E. Eastlake 3rd" To: dns-security@ex.tis.com Subject: Re: WG Last Call: draft-ietf-dnssec-indirect-key-01.txt In-Reply-To: <199712080510.VAA29240@toad.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk On Sun, 7 Dec 1997, John Gilmore wrote: > Date: Sun, 07 Dec 1997 21:10:02 -0800 > From: John Gilmore > To: dns-security@ex.tis.com, gnu@toad.com > Subject: Re: WG Last Call: draft-ietf-dnssec-indirect-key-01.txt > > It is not clear what problem this draft is trying to solve. This draft is based on the assumption that key distribution via DNS becomes reasonably common. At least common enough that people go look first in the DNS for user/host keys. Then it seems like there would be a number of cases where you would want to use this because they have a bunch of keys/certificates elsewhere and want to tell the people looking in DNS to go use their existing key/certificate server. The impetus for writing the draft came from an actual large ISP that indicated it didn't want to have to put a bunch of user keys into the DNS and keep them updated there but would find it much easier to just have DNS entries pointing to its key server. > The "target type" field seems to be encoding numerous separate kinds > of information (e.g. the format of the location data (URL or domain > name); the format of the data to be retrieved there (KEY RDATA, > CERT RDATA, PKCS #1, etc); and the "type" of certificate that might > be found there (PKIX, PGP, etc). Rather than encode various > combinations of these, wouldn't separate fields be better? The -00 draft had this more orthogonal. But the total number of combinations just doesn't seem that high and if you make these things orthogonal, there are number of combinations that don't make sense. I guess I'd be willing to change back if people want. > Typos. It was a bit hectic getting these drafts out before the deadline... > John Donald ===================================================================== Donald E. Eastlake 3rd +1 978-287-4877(tel) dee@cybercash.com 318 Acton Street +1 978-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.privacy.org/ipc From owner-dns-security Sat Dec 13 21:14:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA10750 for dns-security-outgoing; Sat, 13 Dec 1997 21:11:03 -0500 (EST) X-Authentication-Warning: allmalt.cs.uwm.edu: xwang owned process doing -bs Date: Sat, 13 Dec 1997 20:23:27 -0600 (CST) From: "Steven(Xunhua) WANG" cc: dns-security@ex.tis.com Subject: one question In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk In the Domain Name System Security Extension of Nov 21, 1997, it seems that the stub-resolver, which is implemented in BIND and will ask the local name server do a recursive query for it, will have to trust the local name server, right? I guess so because in this case the chain of trust is checked by the local name server. Thanks in advances! Xunhua Wang From owner-dns-security Sun Dec 14 02:33:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA12193 for dns-security-outgoing; Sun, 14 Dec 1997 02:32:04 -0500 (EST) To: dns-security@tis.com Subject: re: stub-resolvers have to trust their local name servers? From: Paul Vixie Date: 13 Dec 1997 23:43:27 -0800 Message-ID: Lines: 7 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-dns-security@ex.tis.com Precedence: bulk yes. this is the nominal reason for TSIG's existence. see the internet-drafts repository. -- Paul Vixie La Honda, CA "Many NANOG members have been around pacbell!vixie!paul longer than most." --Jim Fleming From owner-dns-security Sun Dec 14 17:14:28 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA16565 for dns-security-outgoing; Sun, 14 Dec 1997 17:13:04 -0500 (EST) Message-Id: <199712142225.OAA16888@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: "Steven(Xunhua) WANG" cc: dns-security@ex.tis.com, gnu@toad.com Subject: Re: one question In-reply-to: Date: Sun, 14 Dec 1997 14:25:25 -0800 From: John Gilmore Sender: owner-dns-security@ex.tis.com Precedence: bulk > In the Domain Name System Security Extension of Nov 21, 1997, it seems > that the stub-resolver, which is implemented in BIND and will ask the > local name server do a recursive query for it, will have to trust the > local name server, right? > I guess so because in this case the chain of trust is checked by the > local name server. Eventually the resolver in BIND will validate the received DNS records itself. Initial releases will only validate them in servers. TSIG may help in the meantime, but would require manual configuration. John Gilmore From owner-dns-security Sun Dec 14 19:28:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA17255 for dns-security-outgoing; Sun, 14 Dec 1997 19:28:16 -0500 (EST) X-Authentication-Warning: allmalt.cs.uwm.edu: xwang owned process doing -bs Date: Sun, 14 Dec 1997 18:40:43 -0600 (CST) From: "Steven(Xunhua) WANG" To: John Gilmore cc: dns-security@ex.tis.com Subject: STUB-resolver case In-Reply-To: <199712142225.OAA16888@toad.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk > > In the Domain Name System Security Extension of Nov 21, 1997, it seems > > that the stub-resolver, which is implemented in BIND and will ask the > > local name server do a recursive query for it, will have to trust the > > local name server, right? > > I guess so because in this case the chain of trust is checked by the > > local name server. > > Eventually the resolver in BIND will validate the received DNS records > itself. Initial releases will only validate them in servers. TSIG may > help in the meantime, but would require manual configuration. TSIG can authenticate the communication between stub-resolver and the local name server, preventing others garble the message. But in the security model, the stub-resolver has to trust the local name server do the name lookup for it. It is not a good idea because in the original security, only the Zone Key should be trusted(the local name server is just a publisher of the RRs of that zone). Is there anything wrong about the above? Thanks for the help. Xunhua Wang From owner-dns-security Mon Dec 15 23:38:00 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA27471 for dns-security-outgoing; Mon, 15 Dec 1997 23:34:21 -0500 (EST) Date: Mon, 15 Dec 1997 23:46:56 -0500 (EST) From: "Donald E. Eastlake 3rd" To: dns-security@tis.com Subject: Security status of the root zone Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk RFC 2065 generally indicates that you tell whether a zone is secured by checking its parent for a KEY entry at the delegation point, assuming the parent is secure. This is a bit hard to do for root. Since it appears that root will be secured quite early in the roll out of DNS security, I propose to change the current secext2 draft to require that the root zone always be secure. Donald ===================================================================== Donald E. Eastlake 3rd +1 978-287-4877(tel) dee@cybercash.com 318 Acton Street +1 978-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.privacy.org/ipc From owner-dns-security Tue Dec 16 10:06:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA01307 for dns-security-outgoing; Tue, 16 Dec 1997 10:05:29 -0500 (EST) Date: Tue, 16 Dec 1997 10:18:26 -0500 (EST) From: "Donald E. Eastlake 3rd" To: dns-security@tis.com Subject: A "super-root" key Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk There has been some discussion about the desireability of having a "super-root" key. I.E., an especially secure strong key that is used rarely and only to sign the root zone key. Although the normal root zone key will probably not be used all that often, perhaps twice a week, it would still be more exposed that a "super-root" key used perhaps once a year. This seems like a good idea but I would like to achieve it with an absolute minimum of additional mechanism. In particular, I suggest that the super-root key be used to sign a KEY RR RRset at the root node consisting of itself and the normal root key and the resulting SIG be included in the root zone along with this KEY RRset and a second signature over it by the normal root zone key. If the super-root public key is staticly configured at a resolver, this should authenticate the normal root key and thus the signatures in the rest of the root zone. The above would be recommended in a revised secext2 without going into detailed logistics of how to acomplish this with a partciular signer application. It might also recommend key sharing the super-root key so that multiple people would have to act to sign with it but I would like to avoid going into any detail on this in the secext2 document or any standards track document. (It might be appropriate to have an Information RFC describing a recommended and/or deployed way of doing this.) Donald ===================================================================== Donald E. Eastlake 3rd +1 978-287-4877(tel) dee@cybercash.com 318 Acton Street +1 978-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.privacy.org/ipc From owner-dns-security Tue Dec 16 15:10:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA03761 for dns-security-outgoing; Tue, 16 Dec 1997 15:09:35 -0500 (EST) Date: Tue, 16 Dec 1997 15:22:51 -0500 (EST) From: "Donald E. Eastlake 3rd" To: dns-security@tis.com Subject: Proposed change to NXT Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk Background The purpose of the NXT RR is to be able to securely deny the existence of DNS names and to securely deny the existence of types at existing names. This note mostly ignores the types question and concentrates on particular aspects of name denial and side effects thereof. For simplicity, it also assumes that all zones are secure. Why do you need secure name denial? There really are protocols that want to take different actions depending on whether they are sure a name does not exist or just can't get any answer about it. For example, mail wants to stop and report immediately if the destination does not exist but keep trying if it is not sure. RFC 2065 According to the current proposed standard, you have an NXT for each name in the zone whose RDATA points to the next name with the last one pointing back to the zone name. A lexical ordering of names is defined. With just that, a program querying the zone can step through all the names in the zone. This unacceptable to many zone administrators currently and if user names are added to the DNS (for key distribution for example) it will become really, really unacceptable. RFC 2065 avoids this problem by letting wildcards mask off areas of the name space within which you both lose authenticated existence denial but also avoid name leakage. If an exact name falls within a wildcard scope, the "next" pointer always points to just after the wildcard scope. Thus, a server can falsely deny the exitence of such names but, in exchange for that loss in security, the client also can't step through the names so they are not leaked. The above design was created before it was noticed that you need to be able, when you verifiable deny the existence of a name, also verifiably deny the existence of any wildcard that could have also produced an answer for the query. This was not possible with the RFC 2065 design which is, in this regard, flawed. secext2 draft and TIS implementation The secext2 draft currently presecribes NXTs that link all names in the zone, including wildcards sorted in their unexpanded form. This enables the verifiable denial of all names, including wildcards, but leaks all names. I believe this is also how the current TIS implementation works [although the TIS document permits the domain name in the NXT RDATA part to be always be the zone name if you do not want to leak names]. As stated above, I believe many system managers will find the name leakage so unacceptable that they will, for that reason, either avoid DNSSEC or try to patch out NXTs. Proposal Using an idea originating with Charlie Kaufman, it is possible to get *both* total authenticated name existence denial, including wild card, and not leak any specific names. You make a change from the NXT RRs as described in secext2 by simply replacing the owner name and the next name in the RDATA by a hashed name constructed by doing SHA1 or like of the domain name in question, encoding it (in hex for example), and appending the zone name. Then you link the NXTs in hash order by sorting the hashes numerically, for example. (This also limits (for hex encoding) domain names in secure zones to 214 characters and eliminates the name collision of the parent and child NXT RRs at delegation points.) This means that when it is desired to prove a name doesn't exist, you get an NXT such that the hash of the non-existent name is between the hashes in the owner and RDATA names of the NXT. Other than that, things all pretty much work as before. But now, while you can still NXT walk (just do a query for type NXT with any name, use the NXT you get back (either because the name you queried was found or denied), and keep taking the name in the NXT RDATA to get the next NXT...) all NXT walking tells you is the one-way hash of the names in the zone. You can count them but that's about it. (You can do an off line dictionary attack but then you could always have done a dictionary attack against the zone anyway.) There is no change to non-existent type processing except that the type bit map will be in an NXT with the hash contructed name. The above proposal has no effect on the number of RRs in a zone but it does double the number of distinct names in a zone. If we are going to change to this hashed NXT name scheme, or anything like it, we should decide as soon as practiable to minimize deployment of the current scheme before it is replaced. Donald ===================================================================== Donald E. Eastlake 3rd +1 978-287-4877(tel) dee@cybercash.com 318 Acton Street +1 978-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.privacy.org/ipc From owner-dns-security Wed Dec 17 13:32:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA12147 for dns-security-outgoing; Wed, 17 Dec 1997 13:30:15 -0500 (EST) Date: Wed, 17 Dec 1997 13:42:05 -0500 (EST) From: "Donald E. Eastlake 3rd" To: "Steven(Xunhua) WANG" Cc: dns-security@ex.tis.com Subject: Re: STUB-resolver case In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk How bad it is for the stub resovler to trust some name server to give correct answers is a policy question. Certainly it is giving complete trust now. It is more secure for the resolver to do crypto and check the chain back to some locally configured key at the resolver. It also involves more computation, code, and logistics. I believe that, in many cases, the right engineering tradeoff will be for example, for resovlers within an organization to trust a boarder caching recursive server. Donald On Sun, 14 Dec 1997, Steven(Xunhua) WANG wrote: > Date: Sun, 14 Dec 1997 18:40:43 -0600 (CST) > From: Steven(Xunhua) WANG > To: John Gilmore > Cc: dns-security@ex.tis.com > Subject: STUB-resolver case > > > > In the Domain Name System Security Extension of Nov 21, 1997, it seems > > > that the stub-resolver, which is implemented in BIND and will ask the > > > local name server do a recursive query for it, will have to trust the > > > local name server, right? > > > I guess so because in this case the chain of trust is checked by the > > > local name server. > > > > Eventually the resolver in BIND will validate the received DNS records > > itself. Initial releases will only validate them in servers. TSIG may > > help in the meantime, but would require manual configuration. > TSIG can authenticate the communication between stub-resolver and the > local name server, preventing others garble the message. But in the > security model, the stub-resolver has to trust the local name server do > the name lookup for it. It is not a good idea because in the original > security, only the Zone Key should be trusted(the local name server is > just a publisher of the RRs of that zone). > > Is there anything wrong about the above? Thanks for the help. > > Xunhua Wang > > ===================================================================== Donald E. Eastlake 3rd +1 978-287-4877(tel) dee@cybercash.com 318 Acton Street +1 978-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.privacy.org/ipc From owner-dns-security Wed Dec 17 13:49:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA12260 for dns-security-outgoing; Wed, 17 Dec 1997 13:49:43 -0500 (EST) X-Authentication-Warning: allmalt.cs.uwm.edu: xwang owned process doing -bs Date: Wed, 17 Dec 1997 13:00:58 -0600 (CST) From: "Steven(Xunhua) WANG" To: "Donald E. Eastlake 3rd" cc: dns-security@ex.tis.com Subject: Re: STUB-resolver case In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk > How bad it is for the stub resovler to trust some name server to give correct > answers is a policy question. Certainly it is giving complete trust now. It > is more secure for the resolver to do crypto and check the chain back to some > locally configured key at the resolver. It also involves more computation, > code, and logistics. I believe that, in many cases, the right engineering > tradeoff will be for example, for resovlers within an organization to trust a > boarder caching recursive server. I cannot agree with you more! Yes, it is a policy. What I think is that the statement can be made more clear and consistent: in draft-ietf-dnssec-secext2: 2.3: This data origin authentication key belongs to the zone and not to the servers that store copies of the data. That means compromise of a server or even ALL servers for a zone will not necessarily affect the degree of assurance that a resolver has that it can determine whether data is genuine. While in RFC2137: For mode B, the zone owner key and master file are kept on-line at the zone primary server. Maybe I am too verbatim? But for draft standard, we need that, right? Anyway, if you do not agree this, just forget them. In fact, if several INDEPENDENT primary servers are allowed in this case, the dilemma can be resolved(the zone key can be distributed to the independent primary servers. In this way the dynamic update can be accomplished by threshold cryptography. At the same time, compromise of certain number of servers will not compromise the zone key). Of course, you have stated previously that the goal of DNSSEC is to provide security for the single-primary-server model, not to change it. Then, again, forget what I said. Xunhua Wang From owner-dns-security Wed Dec 17 15:36:03 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA12963 for dns-security-outgoing; Wed, 17 Dec 1997 15:34:53 -0500 (EST) Date: Wed, 17 Dec 1997 15:47:00 -0500 (EST) From: "Donald E. Eastlake 3rd" To: Paul Wren Cc: dns-security@tis.com Subject: Re: Proposed change to NXT In-Reply-To: <01bd0b2c$0b82f400$603239cc@dorset.software.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk Cryptographic hashes are strings of 1s and 0s. There is no problme ordering the hashes. Just treat them as unsigned integers or whatever. (Of course, the exact comparison method would have to be specified.) Donald On Wed, 17 Dec 1997, Paul Wren wrote: > Date: Wed, 17 Dec 1997 15:40:43 -0500 > From: Paul Wren > To: "Donald E. Eastlake 3rd" , dns-security@tis.com > Subject: Re: Proposed change to NXT > > From: Donald E. Eastlake 3rd > > This means that when it is desired to prove a name doesn't exist, you > >get an NXT such that the hash of the non-existent name is between the > >hashes in the owner and RDATA names of the NXT. > > Forgive me if I'm really missing something, but cryptographic hashes are not > ordered. There is no concept of "between". How can this work? > > ===================================================================== Donald E. Eastlake 3rd +1 978-287-4877(tel) dee@cybercash.com 318 Acton Street +1 978-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.privacy.org/ipc From owner-dns-security Wed Dec 17 15:40:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA12990 for dns-security-outgoing; Wed, 17 Dec 1997 15:40:50 -0500 (EST) From: "Paul Wren" To: "Donald E. Eastlake 3rd" , Subject: Re: Proposed change to NXT Date: Wed, 17 Dec 1997 15:40:43 -0500 Message-ID: <01bd0b2c$0b82f400$603239cc@dorset.software.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-dns-security@ex.tis.com Precedence: bulk From: Donald E. Eastlake 3rd > This means that when it is desired to prove a name doesn't exist, you >get an NXT such that the hash of the non-existent name is between the >hashes in the owner and RDATA names of the NXT. Forgive me if I'm really missing something, but cryptographic hashes are not ordered. There is no concept of "between". How can this work? From owner-dns-security Thu Dec 18 13:42:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA21670 for dns-security-outgoing; Thu, 18 Dec 1997 13:36:57 -0500 (EST) Reply-To: James M Galvin To: dns-security@ex.tis.com Subject: DRAFT DNSSEC meeting summary MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <20681.882470917.0@commerce.net> Date: Thu, 18 Dec 1997 13:48:37 -0500 From: James M Galvin Message-ID: <9712181248.aa20685@lists.Commerce.Net> Sender: owner-dns-security@ex.tis.com Precedence: bulk ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20681.882470917.1@commerce.net> Enclosed you will find the meeting summary for our last meeting. Comments and corrections are welcome. I will submit these next monday, December 22. Thanks! Jim -- James M. Galvin Executive Director, Trust and Security CommerceNet Consortium +1 410.203.2707 3209A Corporate Court +1 410.203.2709 FAX Ellicott City, MD 21042 http://www.commerce.net ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20681.882470917.2@commerce.net> Content-Description: DNSSEC Meeting Summary Summary, DNS Security Working Group, Tuesday, December 9, 1997 The DNS Security Working Group met on December 9, 1997, with the following agenda: Introduction Implementation Status Documents What's Next After a brief introduction Olafur Gudmundsson gave a brief status report on the Trusted Information Systems reference implementation of the DNS security extensions. TIS has to a large extent completed a prototype implementation of DNSSEC functionality. Some of these prototypes will be made available soon. TIS is working with ISC on integrating the changes into a not to distant version of BIND. It is important to realize that SECURE DNS requires at least four tools: security aware nameserver (BIND) key generation tool DNS zone signing tool security aware resolver Currently there are research prototypes of all of these tools developed, with the exception of some of the secure resolution in the nameserver. We will be working with ISC on how best to integrate the lessons from the secure resolver work into the nameserver without breaking a number of things. TIS has started an implementation of the SECUPD draft. Paul Vixie reported briefly on the status of DNS security extensions in Bind indicating that ISC will incorporate the TIS prototype into BIND as soon as feasible. John Gilmore has worked out a deployment strategy, which will allow a minimally security aware server to be released soon with a fully security aware server to follow later. The remaining bulk of the meeting was devoted to the 12 documents currently being reviewed. Seven of these documents are currently in Working Group Last Call, which closes on December 19. The following six of them will be eligible to be submitted to the IESG for consideration as Proposed Standards if no significant technical issues are raised prior to the end of the Last Call: draft-ietf-dnssec-secext2-02.txt draft-ietf-dnssec-dhk-01.txt draft-ietf-dnssec-dss-01.txt draft-ietf-dnssec-ddi-02.txt draft-ietf-dnssec-certs-01.txt draft-ietf-dnssec-indirect-key-01.txt Most of these documents will have one additional version issued that includes a few minor editorial changes. In addition, the IETF policy requires that unencumbered technologies must be the default, or mandatory to implement, whenever they exist and meet the necessary requirements. As a result, the revision to RFC2065, draft-ietf-dnssec-secext2-02.txt, will be changed to mandate the use of DSS as specified by draft-ietf-dnssec-dss-01.txt. It was left to the discretion of the author as to whether to merge the two documents or instead to separate the RSA specification from draft-ietf-dnssec-secext2-02.txt into a separate document. The remaining last call document, draft-ietf-dnssec-as-map-05.txt, has been removed from consideration for publication because two questions were raised. First, who will "own" and "manage" the "map-as.arpa" namespace? Second, are certain the routing area has a need for this specification and will use it? The agreed upon action was to remand this document to the routing area. Of the 5 remaining documents, it was agreed to remove draft-ietf-dnssec-in-key-00.txt from review. The following 4 documents: draft-ietf-dnssec-key-handling-00.txt draft-lewis-dnssig-authorization-00.txt draft-lewis-dnsnxt-semantics-01.txt draft-ietf-dnssec-ar-00.txt are still under review by the working group. Time did not permit significant discussion of these documents. The first three of them affect the operational behavior of the secure DNS and are priority work items; everyone is encouraged to review them. The last represents a potential new work item; its author is looking for individuals with whom to experiment. ------- =_aaaaaaaaaa0-- From owner-dns-security Thu Dec 18 14:44:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA22235 for dns-security-outgoing; Thu, 18 Dec 1997 14:44:08 -0500 (EST) Date: Thu, 18 Dec 1997 14:56:42 -0500 (EST) From: "Donald E. Eastlake 3rd" To: dns-security@tis.com Subject: DSA/RSA ... RE: DSS wording Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk I have done a pass over the dnssec dsa draft and split out the rsa algorithm material from secext2 into a separate document. On dsa, the purpose is to reference a fixed existing unencumbered signature algorithm for use in domain name security, not to track possible future changes in "dss". Currently the dsa draft I am working on still references the FIPS although I have no particular problem in changing if someone can give me good ANSI standard references and these ANSI documents are freely available on the net like FIPS are. I'm sure they are just clones of the FIPS documents, if the FIPS documents are more easily available, I see no reason to change. I did not add the Young&Yung reference but did put in a recommendation to check recent research. I think as long as we clearly point out the problem areas and alert people, which is done, we don't need to go into too much detail. Donald On Thu, 11 Dec 1997, Blake Greenlee wrote: > Date: Thu, 11 Dec 1997 13:52:57 -0500 > From: Blake Greenlee > To: 'John Kennedy' , > "djohnson@certicom.com" > Cc: "dee@cybercash.COM" , > "dns-sec@tis.COM" , "gnu@toad.COM" , > "x9f1@x9.org" > Subject: RE: DSS wording > > Dear Folks: > > We should reference ANSI standards, not FIPS. > > Blake > > -----Original Message----- > From: John Kennedy [SMTP:JKENNEDY@novell.com] > Sent: Thursday, December 11, 1997 1:02 PM > To: djohnson@certicom.com > Cc: dee@cybercash.COM; dns-sec@tis.COM; gnu@toad.COM; x9f1@x9.org > Subject: Re: DSS wording > > Don, > > I understand your position, Don, and concur. I still think it is a good > idea to > reference the DSS standard, however. > > -John > > >>> "Don B. Johnson" 12/11 10:42 AM >>> > John, > > I personally do not see any advantage to referencing the Young & Yung paper. > My personal take on this paper is that it was an interesting acamdemic > exercise. > What they assume is a corrupt system. If one assumes a corrupt system, then > no crypto method offers any security, as there are just too many things to > play with. One should assume that there is NO security in a corrupt system. > > At the most, I would suggest a mention in all standards that this standard > does not address the possibility of a corrupt implementation, but I do not > even favor that, that would just be my compromise position. > Rgds, Don J. > > > At 01:02 12/11/1997 -0700, John Kennedy wrote: > >I agree that the paper by Young & Yung should be reference. Another > >recommendation is to use different arithmetic groups for your DSS and > >Diffie-Hellman calculations. Finally, it is also advisable to encode and > >sign the appropriate group parameters with the subject public DSS keys as > an > >integral packet. That way you don't open yourself to a group substitution > >attack. > > > >Regarding DSA vs. DSS > > > >I believe alignment with the NIST/ANSI DSS standard has a number of > >important benefits. > >First, most commercial implementations are going to hitch themselves to > this > >standard. It is both stabile and well-defined. There is no other proper > >authority on this standard than NIST. > > > >If we choose the more generic "DSA" wording, we leave implementers with > >insufficient definition for both security and implementation. Thus, I > >strongly recommend both explicit reference and alignment with the FIPS/ANSI > >standard. This will really help to cement this standard and allow > >developers to move ahead. > > > >Regards, > > > >-John Kennedy > >jkennedy@novell.com > > > > > > > > writes: > >" > >The security considerations section should reference the Young & Yung > >paper from Crypto '97 on high bandwidth covert channels in DSA, as > >well as Schneier's older coverage. "The Prevalence of Kleptographic > >Attacks on Discrete-Log Based Schemes Using a Prime Order Subgroup", > >Adam Young and Moti Yung, Advances in Cryptology - Proceedings, CRYPTO > >'97, page 264. Berlin: Springer-Verlag, 1997. ISBN 3-540-63384-7. > >For some reason the I-D is called "dss" (Digital Signature Standard), > >but throughout the document the algorithm is called DSA (Digital > >Signature Algorithm). I agree that the draft should reference the > >algorithm, not the standard. If the draft proceeds to an RFC, no > >trace of "dss" should remain in the RFC (except the citation to theFIPS). > >" > > > > > Don B. Johnson email:djohnson@certicom.com 703-367-0414 > Go to http://www.certicom.com for Java elliptic curve experiments. ===================================================================== Donald E. Eastlake 3rd +1 978-287-4877(tel) dee@cybercash.com 318 Acton Street +1 978-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.privacy.org/ipc From owner-dns-security Fri Dec 19 16:11:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA02082 for dns-security-outgoing; Fri, 19 Dec 1997 16:08:13 -0500 (EST) Date: Fri, 19 Dec 1997 16:20:56 -0500 (EST) From: "Donald E. Eastlake 3rd" To: dns-security@ex.tis.com Subject: Re: WG Last Call: draft-ietf-dnssec-certs-01.txt In-Reply-To: <199712080352.TAA28688@toad.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk On Sun, 7 Dec 1997, John Gilmore wrote: > Date: Sun, 07 Dec 1997 19:52:26 -0800 > From: John Gilmore > > This draft seems to exist for two purposes, one of which is somewhat > worthwhile, and the other of which is worthless and dangerous. > > The somewhat worthwhile purpose is to provide a standard way to > publish and retrieve non-DNS-formatted certificates from the DNS. > (For example, PGP keys and signatures, or X.509 certs). > > However, such certificates can already be stored and retrieved in KEY > RR's. Private or newly standardized "algorithm" and "protocol" fields > can be used for this. Yes, I suppose you could take any RR with a variable length field, like TXT, and stuff a certificate in it (cf, the kitchen sink draft). But, as Nixon said, "It would be wrong". KEY RRs should have keys in them. SIG RRs should have sigantures in them. A certificate has both and should be a new RR type. > The apparent reason for having a different RR type for these, is so > that a query for KEY RR's (e.g. when validating a DNS zone) won't > retrieve unwanted X.509 certificates and such. The proposed solution > doesn't solve the problem, though. Ideally an application would like > to be able to query the DNS for just the key format(s) that it > understands. E.g. an X.509 mail application will not want to see PGP > keys or DNS zone keys. The CERT record merely divides the problem > space in half, leaving the problem remaining in each half of the > space. A real solution to the problem would be to either provide a > different RR type for each kind of key or certificate (ZONEKEY, > EMAILKEY, X509CERT, PGPCERT, etc), or would offer more specific DNS > queries, optionally matching on RDATA fields in target RRs, instead of > just on the RR type and the RR owner name. I think the design esthetics are a strong reason but it is certaily an added benefit that you don't get a bunch of CERTs back if you just ask for KEYs. And while some certificates may be not much bigger than a key and a signature, others, particularly X.509 certs with some options and a policy statement, can be really big. So I would contend that having the two RR types, when there are CERTs present, will frequently save considerably more than a factor of two on KEY retrieval, a savings not to be sneezed at even if 1280 byte DNS replies are generally permitted. As for having lots of RR types, this was discussed in the working group early on and the consensus was to not use up more than a few new types. > The worthless and dangerous purpose of this draft would enable the use > of the same numeric public/private key pair in both X.509 > certificates, and in DNS-format keys and signatures. It burns a > scarce KEY record flag bit for this purpose, and also attempts to > match the two records by using a hash value. > > In discussion with one of the authors, I've been unable to find any > valid reason why anyone would ever want to do this. For example, it > was proposed that you might want to use the same numeric key as a DNS > zone key and an X.509 email key. But that is a very stupid idea -- > who would hand the private key for their zone, to an individual person > to use daily for sending and receiving email messages? A compromise > of either key would compromise both, while there is no advantage to be > gained from the sharing. Merely using separate zone and email keys > would not only be simpler, but more secure. That seems like a somewhat bogus example. I don't think it is as terrible as you make out. Say you have a mechanism for SSL/TLS or email or whatever that likes X.509 certs and you can get such certs issued signed by cert-authority.tld. There might easily be an alternative, perhaps more recent version of the mechanism that looks for keys in DNS authenticated by DNS. If so, it does not seem that terrible to extract the public key from the X.509 certficiate and, if it is a type provided for, also add it as a KEY RR. I certainly don't interpret the idea of having the same key as a KEY RR and inside a CERT RR as implying use of the same key for two different purposes. KEYs may be accessed by remote appliciations. That's one reason you might what to publicly distribute them through the DNS. And different version of such remote applications might look for KEY or CERT RRs. The question of the CERT bit in the KEY RR is less clear to me. I don't think, after what we have done to free so many up and allow for expansion, that KEY RR flag bits are all that scarce. On the other hand, the value may be small. It's just a hint that there might be a CERT RR and, if you really like CERT RRs, you can always just do a query. Is anyone out there depending on this CERT flag in the KEY RR? > It was also proposed that some programs might want to use the keys > from the X.509 certificates for something, but would only know how to > parse DNS KEY RR's, not X.509 certs. Looked at from a software > engineering point of view, this makes no sense. If a program > understands X.509 keys, then it will be able to parse an X.509 key out > of a KEY or CERT record in X.509 format. It does not need the key's > owner to do a one-time translation of the key into DNS "algorithm 1" > KEY RR format. If a program doesn't understand X.509 keys, then the > presence or absence of an X.509 CERT record along with the DNS KEY RR > is irrelevant to it. You might as well generate the key in DNS > "algorithm 1" KEY RR format, and forget the CERT record. (The same > applies to PGP keys; X.509 was just an example.) I really can't speak to the sensibility of this conversation you had and what was proposed during it since it was not with me. > Less major comments: > > The I-D has numerous typos. Sorry about that. Things were rushed towards the draft deadline. > The certificate type field is too big. 256 values should be fine. Well, two byte fields are pretty traditional in DNS. Some of the one byte fields in KEY and SIG are that way as holdovers from the first supercompact proposal by myself and Charlie Kaufman. If I was doing KEY and SIG from scratch, I'd probably make some of them into two byte fields. Once this is wired down, its hard to change so I would lean towards making it a little bigger than seems needed. > The URL private type should use a counted field rather than null > termination, to make it easy to match on. Also, there is no obvious > scheme for dealing with compatability, upgrades, etc. The problem is > that applications looking for keys will have to examine them for an > exact match with the URL that the application understands; but the URL > may change over time, or several versions of certificates may need to > be described by the same URL. This provides backward and forward > compatability issues. I don't care that much about URL termination but it is possible to have a URL longer than 255 characters and nulls are prohibited in URLs. Does anyone else have input on this null termination versus counted question? There are a number of ways to handle versions in private cert type URLs. The version can be tacked onto the hierarchial part or included after a "#" or "?". These are full URL syntax URLs and it is entirely up to the application what sort of pattern matching it does against them. The domain name part is there to assure global uniqueness is achievable and you could even tack the version number onto the start of that ( cert-v1.certs.toad.com ). I'd be happy to add a mentioned that exact URL match is not implied. I don't claim that a robust and powerful way of handling all the situations of version is easy and this RFC certainly doesn't provide any guidance in that area. It just dumps it in the lap of the private syntax user. > Key tag field is a bad idea. It's only useful for applications which > understand both the CERT and the matching KEY record; and those apps > should simply use whichever record is appropriate. If for some reason > an application actually needs to cross-reference between a public key > in one format, and a public key in another format, it can simply do > the format conversion. Providing a 16-bit hash of the key is just a > premature optimization, which will encourage implementers to > e.g. assume that key tags are unique, which they aren't. (TIS made > this mistake.) If there are, for any reason, applications looking to match KEY RRs and CERT RRs, then the hash provides a useful optimization, in my opinion. Any tendence to believe it is other than a heuristic and a test for exact match can be avoided after detecting hash match can be reasonably overcome by documentation. But if applications are mostly going to just retrieve one type (KEY or CERT) and then, in a few cases try for the other type if the initial retrieval fails, maybe there isn't a need for the hash field in CERT. Anyone else have opinions on this? (Note: CERT RRs don't necessarily have the same owner name as a corresponding KEY RR. They might be referenced by an indirect key or wome other mechanism.) > Text representation should not use "mnemonic fields" for the cert > types or algorithm types. This creates a backward compatability > problem when adding new types. As long a numeric is allowed, I don't see much problem. Isn't this like saying that it is bad for any new RR type to have a mnemonic? If you do symbolic output from new software and try to read that into old software, you can run across undefined mnemonics. But how much of a real problem is that? > The CERT bit that this draft adds to the KEY RR should not exist. It > should definitely not be processed as a mnemonic (when the rest of the > flags field is numeric!). Mnemonics are defined for all flag bits in the current secext2 draft. But I'd welcome more input on whether the CERT bit should exist in the KEY RR. > The rules in section 4.1 for naming CERT RR's are complicated. > Examples would help immensely. I'll see what I can do. > John Donald ===================================================================== Donald E. Eastlake 3rd +1 978-287-4877(tel) dee@cybercash.com 318 Acton Street +1 978-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.privacy.org/ipc From owner-dns-security Mon Dec 22 10:50:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA22070 for dns-security-outgoing; Mon, 22 Dec 1997 10:45:28 -0500 (EST) Reply-To: James M Galvin To: "Donald E. Eastlake 3rd" cc: dns-security@tis.com Subject: Re: Proposed change to NXT In-reply-to: "Donald E. Eastlake 3rd"'s message of Tue, 16 Dec 1997 15:22:51 EST. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22089.882805888.1@commerce.net> Date: Mon, 22 Dec 1997 10:51:28 -0500 From: James M Galvin Message-ID: <9712220951.aa22093@lists.Commerce.Net> Sender: owner-dns-security@ex.tis.com Precedence: bulk On Tue, 16 Dec 1997 15:22:51 EST, "Donald E. Eastlake 3rd" said (and I quote): If we are going to change to this hashed NXT name scheme, or anything like it, we should decide as soon as practiable to minimize deployment of the current scheme before it is replaced. I think this change is important and would interpret the silence on the mailing list as agreeing. Let's do it. Jim -- James M. Galvin Executive Director, Trust and Security CommerceNet Consortium +1 410.203.2707 3209A Corporate Court +1 410.203.2709 FAX Ellicott City, MD 21042 http://www.commerce.net From owner-dns-security Mon Dec 22 11:28:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA22445 for dns-security-outgoing; Mon, 22 Dec 1997 11:28:27 -0500 (EST) X-Sender: lewis@pop.hq.tis.com Message-Id: In-Reply-To: <9712220951.aa22093@lists.Commerce.Net> References: "Donald E. Eastlake 3rd"'s message of Tue, 16 Dec 1997 15:22:51 EST. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 22 Dec 1997 11:39:36 -0500 To: dns-security@tis.com From: Edward Lewis Subject: Re: Proposed change to NXT Cc: lewis@tis.com Sender: owner-dns-security@ex.tis.com Precedence: bulk At 10:51 AM -0500 12/22/97, James M Galvin wrote: >On Tue, 16 Dec 1997 15:22:51 EST, > "Donald E. Eastlake 3rd" said (and I quote): > > If we are going to change to this hashed NXT name scheme, or anything > like it, we should decide as soon as practiable to minimize deployment > of the current scheme before it is replaced. > >I think this change is important and would interpret the silence on the >mailing list as agreeing. While I agree that we should decide as soon as possible (ergo be quiet), I am not so sure about the proposal (ergo type). I've written a proto-draft in the past few days, but I am not convinced what I have written is correct, so I haven't yet submitted it. My main concern with the hashing scheme is that I question whether or not the hashing scheme will actually hide the names. Could an "attacker" precomute the possible has values ahead of time, collect the hash values, and then do a "reverse lookup" - hash to plaintext - to get the original name? Is the plaintext space sparse enough for the hash? How would this proposal handle multi-level zones? Is the hash performed over the entire name or just the label portion(s)? How is a short name padded prior to hashing? Before implementing any such proposal there needs to be more detail specified. I would like to see a short example listed to see how the hashing works. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: +1 301-854-5794 Email: lewis@tis.com "Serenity now, insanity later" -- Lloyd Braun Opinions expressed are property of my evil twin, not my employer. From owner-dns-security Mon Dec 22 11:38:41 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA22515 for dns-security-outgoing; Mon, 22 Dec 1997 11:38:31 -0500 (EST) X-Sender: lewis@pop.hq.tis.com Message-Id: In-Reply-To: <9712220951.aa22093@lists.Commerce.Net> References: "Donald E. Eastlake 3rd"'s message of Tue, 16 Dec 1997 15:22:51 EST. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 22 Dec 1997 11:49:24 -0500 To: dns-security@tis.com From: Edward Lewis Subject: Re: Proposed change to NXT Cc: lewis@tis.com Sender: owner-dns-security@ex.tis.com Precedence: bulk Olafur suggested I submit this segment of my proto-draft on the topic: 3.0 Criterion for judging approaches Given the experience to date, a number of criteria have been identified upon which to evaluate a replacement. These features are not stated as "requirements" because absolute statements are not possible in some cases (e.g., how is vulnerability quantized in a general discussion?). The criteria of an authenticated non-existence solution are: The resolver should be able to determine that the response is denying existence, and that the denial is the correct one. The denial of existance should not expose other names or data in a zone. (RFC2065 failed this.) The approach should not require a private key to be used in a name server machine. (Signing the response fails this.) The approach should minimize vulnerablilies and not provide a mechanism for an attack to deny existence of other data. (The SOA response fails this.) The approach should minimize the additions to the DNS in terms names and or resource records. 4.0 Taxonomy of Mechanisms (real and imagined) There are a few categories in which all of the considered mechanisms fit. One category is "here's what I have, look to see if what you want is here," the NXT is an example of this. Another is "I tell you definitively that what you seek is not here" is where all signed-response mechanims fall. The third is "there's nothing in this range, which, as you can see, is where your data would be." Returning the SOA is an example of this. (If any other categories can be identified, please contribute.) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: +1 301-854-5794 Email: lewis@tis.com "Serenity now, insanity later" -- Lloyd Braun Opinions expressed are property of my evil twin, not my employer. From owner-dns-security Mon Dec 22 11:48:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA22580 for dns-security-outgoing; Mon, 22 Dec 1997 11:48:31 -0500 (EST) Message-Id: <3.0.5.32.19971222120000.00847260@pop.hq.tis.com.> X-Sender: ogud@pop.hq.tis.com. X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 22 Dec 1997 12:00:00 -0500 To: "Donald E. Eastlake 3rd" From: Olafur Gudmundsson Subject: DNS record requirements at delegation points in each zone Cc: ogud@tis.com, dns-security@tis.com, gnu@toad.com Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id LAA22577 Sender: owner-dns-security@ex.tis.com Precedence: bulk Donald Few days back when John Gilmore was visiting us, the following issue came up. We (TIS) have been assuming that delegating zones will always contain the following records at delegation points NS, KEY+SIG, NXTu+SIG (and glue) John assumed the draft implied that parent contains only NS or NS, NXTu+SIG He thought that listing the KEY set was optional or not allowed. We looked though the draft and did not find a statement one way or the other. In the case where both zones are served by the same server this is not an issue. But in all other cases it is. I think paragraph 2.5 should be more clear on this point, to the point of specifying what records must be contained in the delegating zone and what records must be contained in the delegated zone. We prefer that delegating zone must contain and only contain NS, KEY,SIG(KEY), NXTu,SIG(NXTu) Delegated zone must contain SOA, SIG(SOA), NS, SIG(NS), KEY, SIG(KEY), NXTl,SIG(NXTl),NXTu,SIG(NXTu) Comments Olafur PS: I use the following notation to describe the two NXT RRsets. NXTu == NXT from delegating zone (NXTupper) NXTl == NXT from delegated zone (NXTlower) ---------------------------------------------------- Ólafur Guðmundsson (in ISO-8859-1) ogud@tis.com (work) Olafur Gudmundsson (in US ascii) ogud@acm.org (private) (301)-854-5700 Fax: x5363 From owner-dns-security Mon Dec 22 13:07:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA23161 for dns-security-outgoing; Mon, 22 Dec 1997 13:05:37 -0500 (EST) Message-Id: <3.0.5.32.19971222131700.008a3c40@pop.hq.tis.com.> X-Sender: ogud@pop.hq.tis.com. X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 22 Dec 1997 13:17:00 -0500 To: "Matt Crawford" From: Olafur Gudmundsson Subject: Re: DNS record requirements at delegation points in each zone Cc: dns-security@tis.com In-Reply-To: <199712221754.LAA03740@gungnir.fnal.gov> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id NAA23152 Sender: owner-dns-security@ex.tis.com Precedence: bulk At 11:54 AM 12/22/97 -0600, Matt Crawford wrote: >Can the delegated zone really be expected to maintain NXTu and SIG(NXTu)? >That doesn't seem practical. > Matt > It is not a problem, NXTu is treated the same way as KEY set. It is sent to the delegated zone and it adds it to its zone (only difference is that these two sets are signed by the delegating zone key). Yes the NXTu can be out of date if the names in the delegating zone change frequently, but that is not a problem as the delegating zone is the authorative source for it. newer If resolver gets two equally valid NXTu sets, the resolver should pick the newer one. Olafur ---------------------------------------------------- Ólafur Guðmundsson (in ISO-8859-1) ogud@tis.com (work) Olafur Gudmundsson (in US ascii) ogud@acm.org (private) (301)-854-5700 Fax: x5363 From owner-dns-security Mon Dec 22 13:46:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA23571 for dns-security-outgoing; Mon, 22 Dec 1997 13:45:36 -0500 (EST) X-Sender: lewis@pop.hq.tis.com Message-Id: In-Reply-To: <3.0.5.32.19971222131700.008a3c40@pop.hq.tis.com.> References: <199712221754.LAA03740@gungnir.fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 22 Dec 1997 13:56:11 -0500 To: Olafur Gudmundsson From: Edward Lewis Subject: Re: DNS record requirements at delegation points in each zone Cc: "Matt Crawford" , dns-security@tis.com Sender: owner-dns-security@ex.tis.com Precedence: bulk At 1:17 PM -0500 12/22/97, Olafur Gudmundsson wrote: >At 11:54 AM 12/22/97 -0600, Matt Crawford wrote: >>Can the delegated zone really be expected to maintain NXTu and SIG(NXTu)? >>That doesn't seem practical. Yes: the decision can be made a number of ways. NXTu - has the NS bit on and the SOA off. NXTl - has both NS and SOA on SIG (NXTu) - signed by someone other than the owner SIG (NXTl) - signed by the owner (NOTE: this assumes the policy regarding the signing of NXTs says that only the NXT's native zone can sign it with a zone key. If other signers are permitted, the decision tree gets more complicated. It is possible that the zone of a SIG(NXT?) maybe undecidable - until brute force matching to NXT? is done.) >If resolver gets two equally valid NXTu sets, the resolver should pick the >newer one. The question is how is the concept of DNS credibility is extended to mesh with security status and security time? Specifically, a resolver doesn't ever receive two+ "equal" NXT sets from which it needs to pick one. A cache/name server backing up the resolver does need to decide what to store and what to drop. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: +1 301-854-5794 Email: lewis@tis.com "Serenity now, insanity later" -- Lloyd Braun Opinions expressed are property of my evil twin, not my employer. From owner-dns-security Mon Dec 22 14:07:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA23776 for dns-security-outgoing; Mon, 22 Dec 1997 14:06:37 -0500 (EST) Date: Mon, 22 Dec 1997 14:20:13 -0500 (EST) From: "Donald E. Eastlake 3rd" To: Olafur Gudmundsson Cc: dns-security@tis.com, gnu@toad.com, "Donald E. Eastlake" Subject: Re: DNS record requirements at delegation points in each zone In-Reply-To: <3.0.5.32.19971222120000.00847260@pop.hq.tis.com.> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by portal.ex.tis.com id OAA23773 Sender: owner-dns-security@ex.tis.com Precedence: bulk On Mon, 22 Dec 1997, Olafur Gudmundsson wrote: > Date: Mon, 22 Dec 1997 12:00:00 -0500 > From: Olafur Gudmundsson > > Donald > > Few days back when John Gilmore was visiting us, the following issue came up. > We (TIS) have been assuming that delegating zones will always contain the > following records at delegation points > NS, KEY+SIG, NXTu+SIG (and glue) I don't have time to do extensive searches right now as I'm going to be leaving to catch a plane shortly. Above is what I assumed early on and I think it is what RFC 2065 says. But I believe I was swayed by arguments not to be too restrictive and to allow the KEY with upper sig to be in the lower zone. I don't think that will be very common. It *has* to be possible for the KEY+SIG to be in the upper zone, at least for the null KEY because the will be slow adopters who will not upgrade their software and will not change their zone, but must be flagged as insecure via a null KEY in the parent. > John assumed the draft implied that parent contains only > NS This doesn't make sense. The parent need to be able to issue authoritative denials without recursing and going off to possibly non-existent servers for the child zone. The NXT chain for a zone must all be in that zone. > or NS, NXTu+SIG The current draft, I believe, does permit this, although it always made more sense to me for the KEY to be in the parent. It *must* be there for insecure zones and it seems like a good idea for secure zones. > He thought that listing the KEY set was optional or not allowed. > We looked though the draft and did not find a statement one way or the other. > In the case where both zones are served by the same server this is not an > issue. But in all other cases it is. Like I say, I don't have time to do a search right now... > I think paragraph 2.5 should be more clear on this point, to the point of > specifying what records must be contained in the delegating zone and what > records must be contained in the delegated zone. OK. > We prefer that delegating zone must contain and only contain > NS, KEY,SIG(KEY), NXTu,SIG(NXTu) > > Delegated zone must contain > SOA, SIG(SOA), NS, SIG(NS), KEY, SIG(KEY), NXTl,SIG(NXTl),NXTu,SIG(NXTu) Why is NXTu in the delegated zone? It doesn't need it, as far as I can see. > Comments > Olafur > > PS: I use the following notation to describe the two NXT RRsets. > NXTu == NXT from delegating zone (NXTupper) > NXTl == NXT from delegated zone (NXTlower) > ---------------------------------------------------- > Ólafur Guðmundsson (in ISO-8859-1) ogud@tis.com (work) > Olafur Gudmundsson (in US ascii) ogud@acm.org (private) > (301)-854-5700 Fax: x5363 Donald ===================================================================== Donald E. Eastlake 3rd +1 978-287-4877(tel) dee@cybercash.com 318 Acton Street +1 978-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.privacy.org/ipc From owner-dns-security Mon Dec 22 14:13:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA23848 for dns-security-outgoing; Mon, 22 Dec 1997 14:13:40 -0500 (EST) Date: Mon, 22 Dec 1997 14:25:58 -0500 (EST) From: "Donald E. Eastlake 3rd" To: Edward Lewis Cc: dns-security@tis.com Subject: Re: Proposed change to NXT In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk On Mon, 22 Dec 1997, Edward Lewis wrote: > Date: Mon, 22 Dec 1997 11:39:36 -0500 > From: Edward Lewis > To: dns-security@tis.com > > At 10:51 AM -0500 12/22/97, James M Galvin wrote: > >On Tue, 16 Dec 1997 15:22:51 EST, > > "Donald E. Eastlake 3rd" said (and I quote): > > > > If we are going to change to this hashed NXT name scheme, or anything > > like it, we should decide as soon as practiable to minimize deployment > > of the current scheme before it is replaced. > > > >I think this change is important and would interpret the silence on the > >mailing list as agreeing. > > While I agree that we should decide as soon as possible (ergo be quiet), I > am not so sure about the proposal (ergo type). I've written a proto-draft > in the past few days, but I am not convinced what I have written is > correct, so I haven't yet submitted it. > > My main concern with the hashing scheme is that I question whether or not > the hashing scheme will actually hide the names. Could an "attacker" > precomute the possible has values ahead of time, collect the hash values, > and then do a "reverse lookup" - hash to plaintext - to get the original > name? Is the plaintext space sparse enough for the hash? The attacker can always just query the zone for names. By hashing the entire FQDN, you avoid precomputation over just the local zones. People who call their host "www" should not be suprised if it is guessed either way. > How would this proposal handle multi-level zones? Is the hash performed > over the entire name or just the label portion(s)? How is a short name > padded prior to hashing? SHA-1 does its own padding. > Before implementing any such proposal there needs to be more detail specified. I would propose hashing the entire FQDN in wire format with SHA-1 then printing the resuling 160 bit binary value as a 40 character hex label directly under the zone name. > I would like to see a short example listed to see how the hashing works. You are entirely correct that a more complete and full description is needed, even if we go with the above suggestion of mine. > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis Trusted Information Systems > Phone: +1 301-854-5794 Email: lewis@tis.com > > "Serenity now, insanity later" -- Lloyd Braun > > Opinions expressed are property of my evil twin, not my employer. Donald ===================================================================== Donald E. Eastlake 3rd +1 978-287-4877(tel) dee@cybercash.com 318 Acton Street +1 978-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.privacy.org/ipc From owner-dns-security Mon Dec 22 14:59:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA24115 for dns-security-outgoing; Mon, 22 Dec 1997 14:59:40 -0500 (EST) X-Sender: lewis@pop.hq.tis.com Message-Id: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 22 Dec 1997 15:08:23 -0500 To: dns-security@tis.com From: Edward Lewis Subject: Another thought on Re: Proposed change to NXT Cc: Edward Lewis Sender: owner-dns-security@ex.tis.com Precedence: bulk Including the hash of each name in the zone will double the number of names in the zone, albeit with an equal number of records. This will have an operational impact on the process of signing the data and the storing of data. With the current NXT set up, I can do signing in four steps - two major and two minor: 1. Read params (easy) 2. Ingest all data (hard) -- results in a sorted zone (b-tree in my case) 3. Open up keys (easy) 4. Process data - sign sets, add NXTs, write files. (hard) If the hashes are used, I will need to make a fifth step - placing the adding of NXTs into their own step - before processing data. Hmmm. I may need to use a different tree. The doubling of names may not be a big problem - the balanced b-tree adds one more level across the board. Searching for a name averages one more comparison. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: +1 301-854-5794 Email: lewis@tis.com "Serenity now, insanity later" -- Lloyd Braun Opinions expressed are property of my evil twin, not my employer. From owner-dns-security Tue Dec 23 06:56:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA29130 for dns-security-outgoing; Tue, 23 Dec 1997 06:54:43 -0500 (EST) To: dns-security@tis.com Subject: Re: Proposed change to NXT In-Reply-To: "Donald E. Eastlake 3rd"'s message of "Tue, 16 Dec 1997 15:22:51 -0500." References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 23 Dec 1997 23:06:05 +1100 Message-Id: <22117.882878765@munnari.OZ.AU> From: Robert Elz Sender: owner-dns-security@ex.tis.com Precedence: bulk Date: Tue, 16 Dec 1997 15:22:51 -0500 (EST) From: "Donald E. Eastlake 3rd" Message-ID: I am one of those who needs a much better description of how this is supposed to work. In particular... | Proposal | [...] You make a change from the NXT RRs as | described in secext2 by simply replacing the owner name and the next | name in the RDATA by a hashed name constructed by doing SHA1 or like of | the domain name in question, encoding it (in hex for example), and | appending the zone name. Is the name in the RDATA the hash of the next name in order (as it would currently be the next name in order) or is it the next hash in order of some other existing name (which would mean computing all the hashes, sorting them, and then assigning the rdata values, and then of course, signing them) If it is the former (the hash of the next name in order), then ... | [...] This means that when it is desired to prove a name doesn't exist, you | get an NXT such that the hash of the non-existent name is between the | hashes in the owner and RDATA names of the NXT. makes no sense to me at all, the hash which is the owner and the hash which is the rdata are just random numbers, being between them as a concept makes no sense to me at all. On the other hand, if the hashes are ordered first, and then assigned to NXTs it seems to me that a bad guy can simply query for all the NXT records (this may take a little while as finding the first one might not be easy - but most of them would be found easily enough by doing a bunch of queries for unlikely names, and following the ordered NXT chain), and then when it wants to fake a NXDOMAIN response, it simply computes the hash of the name in question, selects the NXT record (and its signature) it had previously gone and fetched, and including those in the response - the victim will see those, compute the hash of the name it looked up, find that is between the hashes returned in the NXT (which is properly signed), and hence believe that the name really doesn't exist. What am I missing here? It seems to me that we have a set of three factors that simply can't all co-exist. Those are the desire to keep the keep off line (and certainly not copied to all secondaries), so answers can't be signed dynamically (were it not for that the server could simply sign a NXDOMAIN type record containing the actual name queried, and assert that that one name does not exist, and no more). And the desire to securily assert NXDOMAIN (were it not for that we wouldnt be having this discussion at all). And the desire to keep names secret (were it not for that the current (2065) NXT scheme works, I think). If one of those has to be sacrificed, and I suspect that it might, then I think it is the last one that has to go, and if that is true, 2065 NXTs, as wacko a DNS concept as they are, simply remain unchanged. kre From owner-dns-security Tue Dec 23 07:09:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA29209 for dns-security-outgoing; Tue, 23 Dec 1997 07:09:43 -0500 (EST) To: dns-security@tis.com Subject: Re: Proposed change to NXT In-Reply-To: "Donald E. Eastlake 3rd"'s message of "Tue, 16 Dec 1997 15:22:51 -0500." References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 23 Dec 1997 23:20:19 +1100 Message-Id: <22203.882879619@munnari.OZ.AU> From: Robert Elz Sender: owner-dns-security@ex.tis.com Precedence: bulk I think I just worked out how it is supposed to work, so everyone can ignore my last message... Clearly the hashes are ordered (my second possibility) - what I missed was that it is impossible to claim a name that does exist doesn't, because every such name will produce a hash value, that will be the label and rdata of (two different) NXT records - its hash will never fall between any existing hashes, it will fall right on them, hence the bad guy can't just find some NXT record that covers the name, and return that, because there would never be one. Oh well... Given that, and a description which makes it all obvious, then it looks workable to me. kre