From owner-dns-security Mon Feb 2 15:18:34 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA14202 for dns-security-outgoing; Mon, 2 Feb 1998 15:12:19 -0500 (EST) Date: Mon, 2 Feb 1998 15:26:08 -0500 (EST) From: "Donald E. Eastlake 3rd" To: Lea Viljanen Cc: dns-security@tis.com Subject: Re: DNSSEC, CNAME & forthcoming CERTs In-Reply-To: <199801291327.IAA00685@tapas.nixu.fi> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk On Thu, 29 Jan 1998, Lea Viljanen wrote: > Date: Thu, 29 Jan 1998 08:27:34 -0500 > From: Lea Viljanen > > > But as I say, you can put a KEY at the same domain name as a CNAME. And > > that is really sufficinet since you could always put an indirect KEY > > there pointing at a certificate elsewhere if you want. (see > > draft-ietf-dnssec-indirect-key-01.txt) > > What you're saying is, if we want to bind a key and a certificate > to an owner name, which is an alias, we put something like (xcuse > the syntax): > > www CNAME foo > KEY wwwpubkey > KEY INDIRECT/DNS-CERT somename > ... > foo A 1.2.3.4 > KEY foopubkey > ... > somename CERT whatevercertificate > KEY INDIRECT/DNS-KEY www > > This seems to do the trick, right. Thanks. There is some > inconvenience involved, since we need a lot of intermediate > placeholder names, but that's a minor nuisance. Well, (1) The indirect key could point to some non-DNS certificate server. Like something designed to server up X.509 certs or whatever. This eliminates the "somename" stuff entirely. (2) The indirect key can optinally contain a hash to the cert. Since the indirect key and this hash are secure and the hash can be checked, there is no need for the CERT RR to be in a secure DNS zone or be signed. (you show it with its own KEY RR. I'm not sure why that would be needed... It could just be an insecure zone of CERTs or even if it is secure, seems like a just a SIG by the zone would do. > My other thought with this is that this indirect key is actually > quite something other than a key. It's a reference to a key, > or even more clashing, a reference to some object other than > a key (a CERT). Is it really wise to call it with the same a CERT has a key in it along with other stuff, in particular a signature. > name as a plain KEY? Or is this coupling of function just a > trick to prevent opening the CNAME issue even further? It just didn't seem worth it to use up another RR type code. Nomrally the reason for an indirect KEY is so you can find a KEY. The original request was from an ISP that wan't someday to have it's users keys accessible from the DNS but didn't want to have to update the zone all the time, so they wanted a way to have a pointer to a separate key server. It is not clear why the presence of some additional authenticating material with a KEY, making it a CERT, changes the situation so much. > How are the implementors supposed to handle this? If I > make a query for CERT record for the name www, what's the > server to do? Follow the CNAME? Check all the KEYs for > possible CERT indirection? And the KEY RR will not be > the easiest to parse, since you can't tell by the RR > name what type of thingie you'll get. You really always have to look at the algorithm field in a KEY to tell if it is of any use to you and when you do you will find it's indirect. > Semantically I would feel more comfortable having this same > indirection mechanism attached to both the KEY and CERT RR's. > I.e. if I want to refer to an URL giving me a certificate, > I'd have a CERT RR with indirection fields instead of something > used to refer to a key. However, that would mean allowing the > CERTs with a CNAME, sigh. If you can get feedback from actual implementors supporting the idea of CERT RR's existing at CNAME's, I'd be willing to revist the issue. > BTW, the indirect-key-01.txt seems to have a critical typo in > section 2.1: the target type numbering goes 0,1,2,2,3... Yes, sorry I have not gotten to updating it yet. > P.S. This indirect key stuff reminds me of a quote I read > yesterday: > > "Every problem in computer science can be solved > with one more level of indirection". > - David Wheeler > -- > Lea 'LadyBug' Viljanen NameSurfer Ltd > Lea.Viljanen@namesurfer.com WWW-based DNS-tools Thanks, 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 Feb 10 18:24:09 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA27902 for dns-security-outgoing; Tue, 10 Feb 1998 18:19:45 -0500 (EST) Message-Id: <3.0.3.32.19980210183329.03241218@pop.hq.tis.com> X-Sender: balenson@pop.hq.tis.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 10 Feb 1998 18:33:29 -0500 To: balenson@tis.com From: "David M. Balenson" Subject: REMINDER: ISOC 1998 Network and Distributed System Security Symposium Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-dns-security@ex.tis.com Precedence: bulk ---------------------------------------------------------------------------- David M. Balenson, AR&E Cryptographic Technologies Group Trusted Information Systems, 3060 Washington Road, Glenwood, MD 21738 USA balenson@tis.com; 301-854-5358; fax 301-854-5363 From owner-dns-security Tue Feb 10 23:48:24 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA29978 for dns-security-outgoing; Tue, 10 Feb 1998 23:47:48 -0500 (EST) Message-Id: <3.0.3.32.19980211000023.0070ba90@pop.hq.tis.com> X-Sender: balenson@pop.hq.tis.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 11 Feb 1998 00:00:23 -0500 To: balenson@tis.com From: "David M. Balenson" Subject: REMINDER: ISOC 1998 Network and Distributed Security Symposium Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_887191223==_" Sender: owner-dns-security@ex.tis.com Precedence: bulk --=====================_887191223==_ Content-Type: text/plain; charset="us-ascii" Ok, now that I got your attention, here's the missing text ... --=====================_887191223==_ Content-Type: text/plain; charset="us-ascii" 1998 NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS) SYMPOSIUM March 11-13, 1998 Catamaran Resort Hotel San Diego, California Sponsored by the Internet Society Program Chairs: Matt Bishop, University of California at Davis Steve Kent, BBN Technologies ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss98 EARLY REGISTRATION DISCOUNT DEADLINE: February 13, 1998 This 5th annual Symposium brings together researchers, implementers, and users of network and distributed system security technologies to discuss today's important security issues and challenges. The Symposium provides a mix of technical papers and panel presentations that describe promising new approaches to security problems that are practical and, to the extent possible, have been implemented. NDSS'98 fosters the exchange of technical information and encourages the Internet community to deploy available security technologies and develop new solutions to unsolved problems. KEYNOTE SPEAKER: Howard Gittleson, Director of the Internet Security Products Group at Bell Laboratories, Lucent Technologies THIS YEAR'S TOPICS INCLUDE: - Internet and Intranet security - Implementation issues for electronic commerce - All-optical networks security - Secure single login - Timestamping protocols - Remote password protocols - Mobile agent systems security - Java security - Trust management - Traffic analysis of TCP gateways - Secure bootstrapping - Firewalls and IP security NEW THIS YEAR! PRE-CONFERENCE TECHNICAL TUTORIALS: - Principles of Network Security (Dr. Stephen T. Kent, BBN Technologies) - Electronic Payment Systems (Dr. B. Clifford Neuman, USC/ISI) - Kerberos (Jeffrey I. Schiller, MIT) - Internet Security with Firewalls (Fred Avolio, TIS) - Web Security and Beyond (Dr. B. Clifford Neuman, USC/ISI) FOR MORE INFORMATION contact the Internet Society: Internet Society, 12020 Sunrise Valley Drive, Reston, VA, 20191 USA Phone: +1 703 648 9888 Fax: + 1 703 648 9887 E-mail: ndss98reg@isoc.org URL: http://www.isoc.org/ndss98/ SPONSORSHIP OPPORTUNITIES AVAILABLE! Take advantage of this high visibility event. Contact Torryn P. Brazell at the Internet Society at +1 703 648 9888 or send e-mail to brazell@isoc.org. Sponsorship Chair: George Conrades, GTE Internetworking THE INTERNET SOCIETY is a non-governmental organization for global cooperation and coordination for the Internet and its internetworking technologies and applications. --=====================_887191223==_-- From owner-dns-security Wed Feb 11 14:31:05 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA06180 for dns-security-outgoing; Wed, 11 Feb 1998 14:29:56 -0500 (EST) X-Sender: lewis@pop.hq.tis.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 11 Feb 1998 14:42:15 -0500 To: dns-security@tis.com From: Edward Lewis Subject: secext2-03 comments Cc: lewis@tis.com Sender: owner-dns-security@ex.tis.com Precedence: bulk Now that I've wrapped up the current signer, I read the secext2-03 text. I have a few comments: 2.3.6 A third reason for a non-zone signature is that the signature may exist for the benefit of the consumer of the information and not for the use of DNSSEC. The DNSSEC SIG by a zone key is merely a notary public's stamp claiming that "this is what I entered." The SIG does not guarantee the accuracy of the information. If a pair of entities are passign information using DNS (TXT records as an example) the source may apply another SIG which the sink will use. DNS meanwhile won't bother with it. 3.1.2. Just say that bots 12-15 are to be defined by the Secure Dynamic Update standard and leave it at that. This reduces a chance of text conflict. 3.2 There is a case where the No Key flags make sens for a particular protocol. I could set up a zone that is signed by DSS but is experimental in RSA. I may be signed in both algorithms but delegate a zone that is DSS only. 3.4 This entire section should be written from the angle that zone's security status is relative to the algorithm under consideration. I may have a zone signed by RSA, and unsigned by DSS. The end resolver will have to be aware that at least one RSA signature is mandatory and all DSS signatures are optional (and not pertinent to DNSSEC). 4.1.6 Typo: lest -> least 4.4 Another typo: constraint -> constraints 4.5 This belongs in a BCP document, not a protocol standard. 6. If I recall correctly, in DC the working group agreed that this entire issue - signature verification policy - was to be removed from the secext2 document and the issue taken on as a work item by the group. 7.1 Specifying mnemonics for the flags is a mistake. Considering the parsing of the code, when will I know that the flags are over and the next field begins? There must be a end-of-flags symbol, or it will be hard to determine whether the token seen is a flag I've not yet learned or a protocol I've not yet learned. (OK, maybe I can lop off the last two tokens, but this a mess.) Perhaps you can define a single mnemonic to cover the popular settings, such as "ZONE_KEY" (0x4100) or "NULL_ZONE_KEY" (0xC100)? (There are only 4 bits in use for normal DNSSEC, plus an extended flags bit. Maybe a "+" can be in the mnemonic to continue on - "ZONE_KEY+EXT".) 7.3 Since you are specifying mnemonics for the KEY, you should list the NXT mnemonics. Don't cite WKS as a reference. WKS may be retired and - even if not - it is a parsing nightmare. Using the OS interface to resolve the words (TELNET) to numbers (23) can yield inconsistencies. (/etc/services is not standardly defined.) I keep a hacked version of the assigned numbers RFC around for the conversion. This file is a pain to manage in the build distribution. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: +1 301-854-5794 Email: lewis@tis.com "Trying is the first step to failure." - Homer Simpson Opinions expressed are property of my evil twin, not my employer. From owner-dns-security Fri Feb 20 09:46:34 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA18303 for dns-security-outgoing; Fri, 20 Feb 1998 09:42:02 -0500 (EST) Message-Id: <199802201411.JAA07411@ensun101.UD.Engr> Subject: CFP: Arch. Prot. & QoS for Future Internet To: dns-security@tis.com Date: Fri, 20 Feb 1998 09:11:32 -0500 (EST) Reply-To: atiq@engr.udayton.edu (Mohammed Atiquzzaman) From: atiq@engr.udayton.edu (Mohammed Atiquzzaman) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-dns-security@ex.tis.com Precedence: bulk CALL FOR PAPERS European Transactions on Telecommunications (ETT) Special Issue on ARCHITECTURES, PROTOCOLS AND QUALITY OF SERVICE FOR THE INTERNET OF THE FUTURE Guest Editors: Matteo D'Ambrosio and Mohammed Atiquzzaman Recent advances in switching and transmission technologies allow the implementation of very high speed networks that are changing the face of the Internet. In the next Telecommunication Age it will be possible to support new multimedia applications in a global environment and design new services on flexible platforms without upgrading the physical infrastrucure. In order to reach these goals many researchers are working on defining the new Network Architecture, which will be capable of offering transport and computation services to communication applications with stringent Quality of Service (QoS) requirements. New protocols and node implementations have to be envisioned with this objective in mind. The ETT Journal announces a forthcoming issue on "Architectures, Protocols and Quality of Service For The Internet Of The Future", that will be focused on (but not limited to) the following topics: - New node architectures for Switching and Routing at Gigabit Speeds - Multi-Protocol Label Switching (MPLS): design principles, network architecture and performance - Internetworking with ATM and High Speed Networks to offer QoS guarantees - Multimedia Services running on Heterogeneous Networks - Network and Transport Protocols in the Integrated Services Internet - QoS provision, multicast support and policy capabilities in Routing and Signalling Protocols - Differentiated Services Architectures - Open Control Architectures and Active Networks Prospective authors should email their manuscripts (PostScript format) or send five (5) hard copies to one of the Guest Editors listed below. The following deadlines will apply: - Submission of manuscripts June 30, 1998 - Notification of acceptance November 15, 1998 - Submission of final manuscript December 15, 1998 - Publication Date March-April, 1999 Guest Editors Matteo D'Ambrosio Mohammed Atiquzzaman Networking Department Department of Electrical & CSELT Computer Engineering v. Reiss Romoli 274 University of Dayton 10148 Torino Dayton, Ohio 45469-0226 Italy USA phone: +39 11 2285006 phone: +1 937 229-3183 fax: +39 11 2285069 fax: +1 937 229-4529 e-mail: matteo.dambrosio@cselt.it e-mail: atiq@engr.udayton.edu More information about the special issue can be obtained from http://www.engr.udayton.edu/faculty/matiquzz/ett-cfp.html Note: If a paper is not accepted for the special issue, it will be considered for publication in one of the regular issues of ETT. From owner-dns-security Tue Feb 24 11:05:44 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA24886 for dns-security-outgoing; Tue, 24 Feb 1998 10:58:17 -0500 (EST) Message-Id: <199802241555.KAA21086@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-tkey-00.txt Date: Tue, 24 Feb 1998 10:55:45 -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 : Secret Key Establishment for DNS (TKEY RR) Author(s) : D. Eastlake Filename : draft-ietf-dnssec-tkey-00.txt Pages : 16 Date : 23-Feb-98 [draft-ietf-dnsind-tsig-*.txt] provides a means of authenticating and securing Domain Name System (DNS) queries and responses using shared secret keys via the TSIG resource record (RR). However, it provides no mechanism for setting up such keys other than manual exchange. This document describes a TKEY RR that can be used in a number of different modes to establish shared secret keys between a DNS resolver and server. 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-tkey-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnssec-tkey-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-ietf-dnssec-tkey-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: <19980223173949.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-tkey-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-tkey-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980223173949.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dns-security Wed Feb 25 13:49:41 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA07290 for dns-security-outgoing; Wed, 25 Feb 1998 13:44:41 -0500 (EST) Date: Wed, 25 Feb 1998 14:00:13 -0500 (EST) From: "Donald E. Eastlake 3rd" To: Edward Lewis Cc: dns-security@tis.com Subject: Re: secext2-03 comments 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 Hi Ed, Thanks for going over secext2-03... On Wed, 11 Feb 1998, Edward Lewis wrote: > Date: Wed, 11 Feb 1998 14:42:15 -0500 > From: Edward Lewis > To: dns-security@tis.com > Cc: lewis@tis.com > Subject: secext2-03 comments > > Now that I've wrapped up the current signer, I read the secext2-03 text. I > have a few comments: > > 2.3.6 A third reason for a non-zone signature is that the signature may > exist for the benefit of the consumer of the information and not for the > use of DNSSEC. > > The DNSSEC SIG by a zone key is merely a notary public's stamp claiming > that "this is what I entered." The SIG does not guarantee the accuracy of > the information. If a pair of entities are passign information using DNS > (TXT records as an example) the source may apply another SIG which the sink > will use. DNS meanwhile won't bother with it. Good point, I'll include it. > 3.1.2. Just say that bots 12-15 are to be defined by the Secure Dynamic > Update standard and leave it at that. This reduces a chance of text > conflict. I guess I'm neutral on this, but I'm willing to make most of the change you suggest. I'll only distinguish between zero and non-zero an drop the rest of the text which really is too specific. > 3.2 There is a case where the No Key flags make sens for a particular > protocol. I could set up a zone that is signed by DSS but is experimental > in RSA. I may be signed in both algorithms but delegate a zone that is DSS > only. If you are actually refering to 3.3, the word protocol there means things like SMTP, not crypto algorithm. But assuming you meant 3.3 and "algorithm" I see your point and will make the change. > 3.4 This entire section should be written from the angle that zone's > security status is relative to the algorithm under consideration. I may > have a zone signed by RSA, and unsigned by DSS. The end resolver will have > to be aware that at least one RSA signature is mandatory and all DSS > signatures are optional (and not pertinent to DNSSEC). I guess you are right. This was all written before there were specs for more than one algorithm so I wasn't thinking of that. I'll change it. > 4.1.6 Typo: lest -> least > 4.4 Another typo: constraint -> constraints Thanks, fixed. > 4.5 This belongs in a BCP document, not a protocol standard. Hummm, well, if I can combine it with the previous key life type stuff I took out into separate document... OK. > 6. If I recall correctly, in DC the working group agreed that this entire > issue - signature verification policy - was to be removed from the secext2 > document and the issue taken on as a work item by the group. I assume you are refering to 6.3.1. The working group has agreed several times to split this off into a separate subgroup but it has never happened. I believe some guidance in this area is necessary. Just making this material a separate draft doesn't seem to accomplish much. I believe there should be guidance in the Proposed Standard. It is stated to be a local policy with the 6.3.1 text being a recommendation. > 7.1 Specifying mnemonics for the flags is a mistake. Considering the > parsing of the code, when will I know that the flags are over and the next > field begins? There must be a end-of-flags symbol, or it will be hard to > determine whether the token seen is a flag I've not yet learned or a > protocol I've not yet learned. > (OK, maybe I can lop off the last two tokens, but this a mess.) > > Perhaps you can define a single mnemonic to cover the popular settings, > such as "ZONE_KEY" (0x4100) or "NULL_ZONE_KEY" (0xC100)? > > (There are only 4 bits in use for normal DNSSEC, plus an extended flags > bit. Maybe a "+" can be in the mnemonic to continue on - "ZONE_KEY+EXT".) Originally, this just said print as an unsigned integer but that can be pretty obscure. HEX is better. But I thought mnemonics would be clearest. On person has sent me a suggestion that the mnemonics be separated by virtical bars, to indicate they are "or"ed togethe, which is really the same as your "+". I'd be happy to change to either although I guess I prefer + myself... Eliminating mnemonics altogether seems too obscure. > 7.3 Since you are specifying mnemonics for the KEY, you should list the NXT > mnemonics. Don't cite WKS as a reference. > > WKS may be retired and - even if not - it is a parsing nightmare. Using > the OS interface to resolve the words (TELNET) to numbers (23) can yield > inconsistencies. (/etc/services is not standardly defined.) I keep a > hacked version of the assigned numbers RFC around for the conversion. This > file is a pain to manage in the build distribution. Well, just saying you use the same syntax as WKS (a list of RR menmonics or numbers) does not say anything to me that you ahve to use /etc/services. And you can tell when the list is over by the end of the RR. Why is it a good thing to try to list all RR mnemonics here in this draft? > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis Trusted Information Systems > Phone: +1 301-854-5794 Email: lewis@tis.com > > "Trying is the first step to failure." - Homer Simpson > > Opinions expressed are property of my evil twin, not my employer. Thanks, 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