Received: from relay.tis.com by neptune.TIS.COM id aa15926; 23 May 95 10:09 EDT Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (g3.0) id sma006572; Tue, 23 May 95 10:13:52 -0400 Received: from antares.tis.com by tis.com (4.1/SUN-5.64) id AA17288; Tue, 23 May 95 10:13:29 EDT Message-Id: <9505231413.AA17288@tis.com> Reply-To: dns-security@TIS.COM To: dns-security@TIS.COM Subject: meeting in Stockholm?? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <17368.801238419.1@tis.com> Date: Tue, 23 May 1995 10:13:41 -0400 From: James M Galvin Hello everybody. What a wonderfully quiet list we have! However, wearing my Chair's hat, it's time to think about a meeting in Stockholm. I'm soliciting for comments on whether to meet in Stockholm. Here's our current status to help you decide. 1. Eastlake/Kaufman are almost done with the last revision of the current specification. 2. TIS is almost done with an alpha implementation of the specification. The implementation is alpha because we have'nt implemented everything in the spec, yet, but what we have done is complete. I expect both of these things to come to closure very soon now. When E/K are done with the specification, we'll post it as an internet-draft and immediately start a working group two week last call. After that, it will go to our area director for consideration to be published as a proposed standard. TIS will release our alpha software when the specification is released. This version of the software will be provided by request only. Future versions will be available via anonymous FTP. For now, it will only be available to a US or Canadian site. (Sorry, that's the law. We will resolve international distribution before we're done.) If you want the software, now would be a good time to let me know. Send a note to me at "galvin@tis.com". (REPLYING TO THIS MESSAGE WILL NOT WORK.) In the past, it was requested that the discussions that E/K and TIS be visible to the community. I will be posting the collected works to our anonymous FTP server, probably next week, for those who want to indulge. The problem I have is creating an agenda for a meeting in Stockholm. There might be some interesting operational issues to discuss. In addition, there are some issues related to dynamic update that are probably worth discussing. However, all of these things we could do on the mailing list and thus involve more people. So, I'm leaning towards not having a meeting but I'm interested in what other people think. Comments? Jim   Received: from relay.tis.com by neptune.TIS.COM id aa16598; 23 May 95 11:14 EDT Received: from necom830.cc.titech.ac.jp(131.112.32.132) by relay.tis.com via smap (g3.0) id sma008038; Tue, 23 May 95 11:19:13 -0400 Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Wed, 24 May 1995 00:17:38 +0900 From: Masataka Ohta Message-Id: <199505231517.AAA14152@necom830.cc.titech.ac.jp> Subject: Re: meeting in Stockholm?? To: dns-security@TIS.COM Date: Wed, 24 May 95 0:17:36 JST In-Reply-To: <9505231413.AA17288@tis.com>; from "James M Galvin" at May 23, 95 10:13 am X-Mailer: ELM [version 2.3 PL11] > Hello everybody. What a wonderfully quiet list we have! However, > wearing my Chair's hat, it's time to think about a meeting in Stockholm. > > I'm soliciting for comments on whether to meet in Stockholm. Here's our > current status to help you decide. > > 1. Eastlake/Kaufman are almost done with the last revision of the current > specification. In Danvers, I talked with Donald. To my surprize, he, then, could have understood several issues of why his protocol does NOT work, which is too complex DNS issue that people without real coding experience have the least chance to understand. Later, he send me a mail on the way on how to avoid some of the issues. But, unfortunately, he doesn't understand the issue well that it does not work. So, I'm quite sure that > 2. TIS is almost done with an alpha implementation of the specification. > The implementation is alpha because we have'nt implemented everything > in the spec, yet, but what we have done is complete. your implementation is broken. > TIS will release our alpha software when the specification is released. > This version of the software will be provided by request only. Future > versions will be available via anonymous FTP. For now, it will only be > available to a US or Canadian site. (Sorry, that's the law. We will > resolve international distribution before we're done.) Then, WG, including me, can't evaluate the code, which is equivalent to having no code. > The problem I have is creating an agenda for a meeting in Stockholm. > There might be some interesting operational issues to discuss. Sure. The E/K spec has several defects, which might have been revealed with some operational experience. > However, all of these things we could do on > the mailing list and thus involve more people. Distribute some working code. You are about a year late. > I expect both of these things to come to closure very soon now. When > E/K are done with the specification, we'll post it as an internet-draft > and immediately start a working group two week last call. After that, > it will go to our area director for consideration to be published as a > proposed standard. Wasn't that agreed in Tronto that the draft should be made as a proposed standard after working code appears, which was scheduled to be before San Jose? Masataka Ohta   Received: from relay.tis.com by neptune.TIS.COM id aa17110; 23 May 95 12:03 EDT Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (g3.0) id sma008753; Tue, 23 May 95 12:08:09 -0400 Received: from antares.tis.com by tis.com (4.1/SUN-5.64) id AA01095; Tue, 23 May 95 12:07:46 EDT Message-Id: <9505231607.AA01095@tis.com> Reply-To: James M Galvin To: Masataka Ohta Cc: dns-security@TIS.COM Subject: Re: meeting in Stockholm?? In-Reply-To: Masataka Ohta's message of Wed, 24 May 1995 00:17:36 +0200. <199505231517.AAA14152@necom830.cc.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <17696.801245273.1@tis.com> Date: Tue, 23 May 1995 12:07:54 -0400 From: James M Galvin In Danvers, I talked with Donald. To my surprize, he, then, could have understood several issues of why his protocol does NOT work, which is too complex DNS issue that people without real coding experience have the least chance to understand. Please do describe what you believe is broken. It is important that we all understand and we resolve any problems. your implementation is broken. While there may be scenarios in which in doesn't work, owing to our not testing all possible operational environments, it does, in fact, work at this time. It is far from broken in all of the cases in which we have tested it. For a protocol as important as DNS, we agree with you that real, operational testing is essential. We're going to begin that process soon. > For now, it will only be > available to a US or Canadian site. Then, WG, including me, can't evaluate the code, which is equivalent to having no code. You are correct, the situation is a bit lop-sided at the moment. However, I don't believe it is as bad as having no code. There are a set of folks who will get to see the code and test it, in the short-term. You, too, will eventually have access. Unfortunately, this situation is not under our control so there is nothing I or you can do about it. > The problem I have is creating an agenda for a meeting in Stockholm. > There might be some interesting operational issues to discuss. Sure. The E/K spec has several defects, which might have been revealed with some operational experience. As I suggested above, please do describe your defects. In our experience, what we've implemented works fine. > However, all of these things we could do on > the mailing list and thus involve more people. Distribute some working code. You are about a year late. You're exaggerating Ohtason, since we've only been working on this for a year. In any case, we're distributing code now. > I expect both of these things to come to closure very soon > now. When E/K are done with the specification, we'll post it > as an internet-draft and immediately start a working group two > week last call. After that, it will go to our area director > for consideration to be published as a proposed standard. Wasn't that agreed in Tronto that the draft should be made as a proposed standard after working code appears, which was scheduled to be before San Jose? I don't remember it that way but I could be wrong. What I remember is simply stating, as a TIS person not the Chair, that we would have some code very soon. We had hoped to have a demo in San Jose but didn't have enough pieces implemented to justify it. As we got further along in the implementation some questions came up which we resolved with the authors of the specs. Had there not been any questions we would have had code some time ago, well in advance of the specification release. As Chair, I know there is no requirement for working code for a proposed standard. There is for a draft standard, however. In any case, the working group can aspire to a higher standard and insist on working code before the spec is published as a proposed standard. What do others think? Jim   Received: from relay.tis.com by neptune.TIS.COM id aa28227; 24 May 95 8:58 EDT Received: from necom830.cc.titech.ac.jp(131.112.32.132) by relay.tis.com via smap (g3.0) id sma017096; Wed, 24 May 95 09:03:01 -0400 Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Wed, 24 May 1995 22:00:50 +0859 From: Masataka Ohta Message-Id: <199505241301.WAA01875@necom830.cc.titech.ac.jp> Subject: Re: meeting in Stockholm?? To: galvin@TIS.COM Date: Wed, 24 May 95 22:00:48 JST Cc: dns-security@TIS.COM In-Reply-To: <9505231607.AA01095@tis.com>; from "James M Galvin" at May 23, 95 12:07 pm X-Mailer: ELM [version 2.3 PL11] > In Danvers, I talked with Donald. To my surprize, he, then, could have > understood several issues of why his protocol does NOT work, which is > too complex DNS issue that people without real coding experience have > the least chance to understand. > > Please do describe what you believe is broken. I did several times. > It is important that we all understand and we resolve any problems. The problem is that you, Jim, can't understand. For example, at the last meeting, it was discussed why glue records can not be and does not have to be authenticated. People with some DNS experience could have understood the issue and the agreement was reached. But, judging from the meeting summary you wrote, you didn't understand it at all. And now, dynamic update draft is combined with secure DNS in wrong way related to glue record and can't work. Sue was able to understand the issue when I talked with her personally at Danvers. But I doubt she realized the seriousness of the defect (because dynamic update draft has other problems). > your implementation is broken. > > While there may be scenarios in which in doesn't work, owing to our not > testing all possible operational environments, it does, in fact, work at > this time. It's not a problem of operational environment but just a wrong specification. > For a protocol as important as DNS, we agree with you that real, > operational testing is essential. It is inessential to have real operational test on protocols which is known to be broken in advance. > Then, WG, including me, can't evaluate the code, which is equivalent > to having no code. > > You are correct, the situation is a bit lop-sided at the moment. > However, I don't believe it is as bad as having no code. Agreed. It is worse than having no code. > You, too, will eventually have access. Unfortunately, this > situation is not under our control so there is nothing I or you can do > about it. Fine. You can't say operational code is reviewd by WG. And, can't I do nothing? Don't you remember that I said, at the last meeting, my secure name server is running? It's export control free. > As I suggested above, please do describe your defects. In our > experience, what we've implemented works fine. Read WG log. Cryptographic part should work just fine but not more than that. > Distribute some working code. You are about a year late. > > You're exaggerating Ohtason, since we've only been working on this for a > year. Not, as I spent only a week or two about a year ago to make my mostly complete secure name server run. > In any case, we're distributing code now. You aren't. > As Chair, I know there is no requirement for working code for a proposed > standard. No. But it's an agreement of the WG and is also a personal opinion of Donald. Masataka Ohta   Received: from relay.tis.com by neptune.TIS.COM id aa29264; 24 May 95 10:22 EDT Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (g3.0) id sma018473; Wed, 24 May 95 10:26:59 -0400 Received: from antares.tis.com by tis.com (4.1/SUN-5.64) id AA10999; Wed, 24 May 95 10:26:40 EDT Message-Id: <9505241426.AA10999@tis.com> Reply-To: James M Galvin To: Masataka Ohta Cc: dns-security@TIS.COM Subject: Re: meeting in Stockholm?? In-Reply-To: Masataka Ohta's message of Wed, 24 May 1995 22:00:48 +0200. <199505241301.WAA01875@necom830.cc.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <974.801325596.1@tis.com> Date: Wed, 24 May 1995 10:26:38 -0400 From: James M Galvin And now, dynamic update draft is combined with secure DNS in wrong way related to glue record and can't work. Sue was able to understand the issue when I talked with her personally at Danvers. But I doubt she realized the seriousness of the defect (because dynamic update draft has other problems). The next version of the Secure DNS draft should say more about glue records, to clarify the issue of concern with respect to Secure DNS. We haven't looked carefully at the relationship to dynamic update, yet. > As I suggested above, please do describe your defects. In our > experience, what we've implemented works fine. Read WG log. Cryptographic part should work just fine but not more than that. I don't understand this comment. > As Chair, I know there is no requirement for working code for > a proposed standard. No. But it's an agreement of the WG and is also a personal opinion of Donald. As always, the working group may aspire to a higher standard. I don't remember the working group agreeing to working code before any publication but I've no problem being corrected if others in the working group agree with you. Also, I suspect you are misinterpreting Donald's preference. Although I won't attempt to speak for him or to his rationale, I do know that he's in agreement with me with respect to publishing the specification as soon as the revision is ready, in parallel with software release. Jim   Received: from relay.tis.com by neptune.TIS.COM id aa29511; 24 May 95 10:40 EDT Received: from necom830.cc.titech.ac.jp(131.112.32.132) by relay.tis.com via smap (g3.0) id sma018849; Wed, 24 May 95 10:44:58 -0400 Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Wed, 24 May 1995 23:43:17 +0900 From: Masataka Ohta Message-Id: <199505241443.XAA02444@necom830.cc.titech.ac.jp> Subject: Re: meeting in Stockholm?? To: galvin@TIS.COM Date: Wed, 24 May 95 23:43:16 JST Cc: dns-security@TIS.COM In-Reply-To: <9505241426.AA10999@tis.com>; from "James M Galvin" at May 24, 95 10:26 am X-Mailer: ELM [version 2.3 PL11] > And now, dynamic update draft is combined with secure DNS in > wrong way related to glue record and can't work. Sue was able to > understand the issue when I talked with her personally at > Danvers. But I doubt she realized the seriousness of the defect > (because dynamic update draft has other problems). > > The next version of the Secure DNS draft should say more about glue > records, What's wrong is not wording, but protocol. > to clarify the issue of concern with respect to Secure DNS. As Donald still does not understand it to be able to propose a solution, it is worthless. And, of course, there are several other wrongness in the specification. > We > haven't looked carefully at the relationship to dynamic update, yet. You don't have to. > > As I suggested above, please do describe your defects. In our > > experience, what we've implemented works fine. > > Read WG log. Cryptographic part should work just fine but not > more than that. > > I don't understand this comment. Don't you know that secure DNS consists of cryptography and DNS? DNS part is subtly but fatally broken. > As always, the working group may aspire to a higher standard. I don't > remember the working group agreeing to working code before any > publication but I've no problem being corrected if others in the working > group agree with you. Read WG log. Masataka Ohta   Received: from relay.tis.com by neptune.TIS.COM id aa00431; 24 May 95 11:38 EDT Received: from callandor.cybercash.com(204.178.186.70) by relay.tis.com via smap (g3.0) id sma019877; Wed, 24 May 95 11:43:28 -0400 Received: by callandor.cybercash.com; id WAA09098; Mon, 22 May 1995 22:50:25 -0400 Received: from cybercash.com(204.254.34.52) by callandor.cybercash.com via smap (V1.3) id sma009090; Mon May 22 22:50:20 1995 Received: by cybercash.com.cybercash.com (4.1/SMI-4.1) id AA09566; Wed, 24 May 95 11:38:23 EDT Date: Wed, 24 May 1995 11:38:22 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: Masataka Ohta Cc: dns-security@TIS.COM Subject: Re: meeting in Stockholm?? In-Reply-To: <199505241443.XAA02444@necom830.cc.titech.ac.jp> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Ohta San, I believe that the next version of the draft, which I plan to have out next week, will address most of your concerns. While it is true that in the past, even when you spoke to me in person at Danvers, I did not fully understand these, I believe that I do now. Donald ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)   Received: from relay.tis.com by neptune.TIS.COM id aa00590; 24 May 95 11:54 EDT Received: from kerby.ocsg.com(192.156.168.6) by relay.tis.com via smap (g3.0) id sma020099; Wed, 24 May 95 11:58:42 -0400 Received: from sickly.cybersafe.com (sickly.cybersafe.com [192.156.168.11]) by kerby.ocsg.com (8.6.12/8.6.11, dpg hack 11mar95) with SMTP id IAA22971; Wed, 24 May 1995 08:58:50 -0700 Received: by sickly.cybersafe.com (NX5.67d/NX3.0S) id AA05817; Wed, 24 May 95 08:58:40 -0700 Date: Wed, 24 May 95 08:58:40 -0700 From: Dennis Glatting Message-Id: <9505241558.AA05817@sickly.cybersafe.com> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: Masataka Ohta Subject: Re: meeting in Stockholm?? Cc: galvin@TIS.COM, dns-security@TIS.COM Reply-To: dennis.glatting@cybersafe.com It would help if detailed descriptions of the problems are posted rather than terse, inconclusive statements. -dpg   Received: from relay.tis.com by neptune.TIS.COM id aa00586; 24 May 95 11:54 EDT Received: from necom830.cc.titech.ac.jp(131.112.32.132) by relay.tis.com via smap (g3.0) id sma020074; Wed, 24 May 95 11:56:17 -0400 Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Thu, 25 May 1995 00:53:59 +0859 From: Masataka Ohta Message-Id: <199505241554.AAA02799@necom830.cc.titech.ac.jp> Subject: Re: meeting in Stockholm?? To: "Donald E. Eastlake 3rd" Date: Thu, 25 May 95 0:53:58 JST Cc: dns-security@TIS.COM In-Reply-To: ; from "Donald E. Eastlake 3rd" at May 24, 95 11:38 am X-Mailer: ELM [version 2.3 PL11] > I believe that the next version of the draft, which I plan to have out > next week, will address most of your concerns. While it is true that > in the past, even when you spoke to me in person at Danvers, I did not > fully understand these, I believe that I do now. I really hope so. But, as the implementation is said to be still partial, I, quite righteously from my experience, can't believe you completely. :-) Anyway, I'm looking forward to see the next version. Masataka Ohta   Received: from relay.tis.com by neptune.TIS.COM id aa05982; 30 May 95 15:35 EDT From: hugo@watson.ibm.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Message-Id: <199505301939.PAA09411@relay.tis.com> Received: from watson.ibm.com(129.34.139.4) by relay.tis.com via smap (g3.0) id sma009407; Tue, 30 May 95 15:39:33 -0400 Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 8925; Tue, 30 May 95 15:40:14 EDT Date: Tue, 30 May 95 15:39:03 EDT To: dns-security@TIS.COM Subject: meeting in Stockholm?? Ref: Your note of Tue, 23 May 1995 10:13:41 -0400 (attached) Charles, I do not remember if you're subscribed to this list (dns-sec). Let me know if you are, so I do not forward these messages. This one seems important fyi. Hugo ----------------------------- Note follows ------------------------------ Received: from TIS.COM by watson.ibm.com (IBM VM SMTP V2R3) with TCP; Tue, 23 May 95 11:08:08 EDT Received: from neptune.tis.com by neptune.TIS.COM id aa15930; 23 May 95 10:15 EDT Received: from relay.tis.com by neptune.TIS.COM id aa15926; 23 May 95 10:09 EDT Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (g3.0) id sma006572; Tue, 23 May 95 10:13:52 -0400 Received: from antares.tis.com by tis.com (4.1/SUN-5.64) id AA17288; Tue, 23 May 95 10:13:29 EDT Message-Id: <9505231413.AA17288@tis.com> Reply-To: dns-security@TIS.COM To: dns-security@TIS.COM Subject: meeting in Stockholm?? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <17368.801238419.1@tis.com> Date: Tue, 23 May 1995 10:13:41 -0400 From: James M Galvin Hello everybody. What a wonderfully quiet list we have! However, wearing my Chair's hat, it's time to think about a meeting in Stockholm. I'm soliciting for comments on whether to meet in Stockholm. Here's our current status to help you decide. 1. Eastlake/Kaufman are almost done with the last revision of the current specification. 2. TIS is almost done with an alpha implementation of the specification. The implementation is alpha because we have'nt implemented everything in the spec, yet, but what we have done is complete. I expect both of these things to come to closure very soon now. When E/K are done with the specification, we'll post it as an internet-draft and immediately start a working group two week last call. After that, it will go to our area director for consideration to be published as a proposed standard. TIS will release our alpha software when the specification is released. This version of the software will be provided by request only. Future versions will be available via anonymous FTP. For now, it will only be available to a US or Canadian site. (Sorry, that's the law. We will resolve international distribution before we're done.) If you want the software, now would be a good time to let me know. Send a note to me at "galvin@tis.com". (REPLYING TO THIS MESSAGE WILL NOT WORK.) In the past, it was requested that the discussions that E/K and TIS be visible to the community. I will be posting the collected works to our anonymous FTP server, probably next week, for those who want to indulge. The problem I have is creating an agenda for a meeting in Stockholm. There might be some interesting operational issues to discuss. In addition, there are some issues related to dynamic update that are probably worth discussing. However, all of these things we could do on the mailing list and thus involve more people. So, I'm leaning towards not having a meeting but I'm interested in what other people think. Comments? Jim   Received: from relay.tis.com by neptune.TIS.COM id aa09088; 15 Jun 95 16:32 EDT Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (g3.0.1) id sma019858; Thu, 15 Jun 95 16:34:56 -0400 Received: from antares.tis.com by tis.com (4.1/SUN-5.64) id AA04346; Thu, 15 Jun 95 16:36:24 EDT Message-Id: <9506152036.AA04346@tis.com> Reply-To: James M Galvin To: dns-security@TIS.COM Subject: no meeting in Stockholm Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <2025.803248582.1@tis.com> Date: Thu, 15 Jun 1995 16:36:23 -0400 From: James M Galvin Looks like the right thing to do is not have a meeting in Stockholm. I expect to propose an agenda for this mailing list before then, following the next (final?) version of the specification, whichever is later. Thanks, Jim   Received: from relay.tis.com by neptune.TIS.COM id aa02546; 19 Jun 95 23:32 EDT Received: from necom830.cc.titech.ac.jp(131.112.32.132) by relay.tis.com via smap (g3.0.1) id sma025897; Mon, 19 Jun 95 23:35:13 -0400 Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Tue, 20 Jun 1995 12:34:56 +0859 From: Masataka Ohta Message-Id: <199506200335.MAA04182@necom830.cc.titech.ac.jp> Subject: Re: no meeting in Stockholm To: galvin@TIS.COM Date: Tue, 20 Jun 95 12:34:53 JST Cc: dns-security@TIS.COM In-Reply-To: <9506152036.AA04346@tis.com>; from "James M Galvin" at Jun 15, 95 4:36 pm X-Mailer: ELM [version 2.3 PL11] > Looks like the right thing to do is not have a meeting in Stockholm. Agreed. It's not meaningful to have discussion on an incomplete and defective draft. > I > expect to propose an agenda for this mailing list before then, following > the next (final?) version of the specification, whichever is later. I hope, someday for the first time, we can have a discussion on DNS-affinity issues of proposals, which you couldn't have understood the importance and actively obstructed at the last meeting. Masataka Ohta   Received: from relay.tis.com by neptune.TIS.COM id aa13447; 28 Jun 95 15:45 EDT Received: from ietf.cnri.reston.va.us(132.151.1.35) by relay.tis.com via smap (g3.0.1) id xma014166; Wed, 28 Jun 95 15:47:08 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04911; 28 Jun 95 15:29 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM cc: dns-security@TIS.COM From: Internet-Drafts@cnri.reston.va.us Reply-to: Internet-Drafts@cnri.reston.va.us Subject: I-D ACTION:draft-ietf-dnssec-secext-04.txt Date: Wed, 28 Jun 95 15:29:31 -0400 Sender: cclark@cnri.reston.va.us Message-ID: <9506281529.aa04911@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Security Working Group of the IETF. Title : Domain Name System Security Extensions Author(s) : D. Eastlake, C. Kaufman Filename : draft-ietf-dnssec-secext-04.txt Pages : 41 Date : 06/26/1995 The Domain Name System (DNS) has become a critical operational part of the Internet infrastructure yet it has no strong security mechanisms to assure data integrity or authentication. Extensions to the DNS are described that provide these services to security aware resolvers or applications through the use of cryptographic digital signatures. These digital signatures are included in secured zones as resource records. Security can still be provided even through non-security aware DNS servers in many cases. The extensions also provide for the storage of authenticated public keys in the DNS. This storage of keys can support general public key distribution service as well as DNS security. The stored keys enable security aware resolvers to learn the authenticating key of zones in addition to keys for which they are initially configured. Keys associated with DNS names can be retrieved to support other protocols. Provision is made for a variety of key types and algorithms. In addition, the security extensions provide for the optional authentication of DNS protocol transactions. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnssec-secext-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-secext-04.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dnssec-secext-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19950626104131.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-secext-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-secext-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950626104131.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart--   Received: from relay.tis.com by neptune.TIS.COM id aa16038; 24 Jul 95 11:18 EDT Received: from necom830.cc.titech.ac.jp(131.112.32.132) by relay.tis.com via smap (g3.0.1) id xma009916; Mon, 24 Jul 95 11:10:50 -0400 Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Tue, 25 Jul 1995 00:14:10 +0900 From: Masataka Ohta Message-Id: <199507241514.AAA07143@necom830.cc.titech.ac.jp> Subject: Re: meeting in Stockholm?? To: "Donald E. Eastlake 3rd" Date: Tue, 25 Jul 95 0:14:09 JST Cc: dns-security@TIS.COM In-Reply-To: ; from "Donald E. Eastlake 3rd" at May 24, 95 11:38 am X-Mailer: ELM [version 2.3 PL11] Donald; > Ohta San, > > I believe that the next version of the draft, which I plan to have out > next week, will address most of your concerns. While it is true that > in the past, even when you spoke to me in person at Danvers, I did not > fully understand these, I believe that I do now. I haven't had enough time to review all the part of your draft. But, at least, your draft ignores the WG consensus at the last meeting that non-authoritative delegation RRs do not have to and should not be authenticated by parent zones. As discussed in the meeting, the ignorance makes delegation packets unnecessarily lengthy so that 512 bytes won't be enough. I'd like to propose that, instead of seeking your own way only to make secure DNS complex, you should merge your partially implemented proposal with mine whose implementation of export-free, almost-complete nameserver has been running for these 8 monthes after my 2 weeks of hacking. Masataka Ohta   Received: from relay.tis.com by neptune.TIS.COM id aa22108; 24 Jul 95 18:22 EDT Received: from callandor.cybercash.com(204.178.186.70) by relay.tis.com via smap (g3.0.1) id xma015751; Mon, 24 Jul 95 18:14:40 -0400 Received: by callandor.cybercash.com; id SAA22522; Mon, 24 Jul 1995 18:16:37 -0400 Received: from cybercash.com(204.254.34.52) by callandor.cybercash.com via smap (g3.0.1) id xma022520; Mon, 24 Jul 95 18:16:32 -0400 Received: by cybercash.com.cybercash.com (4.1/SMI-4.1) id AA10570; Mon, 24 Jul 95 18:19:31 EDT Date: Mon, 24 Jul 1995 18:19:30 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: Masataka Ohta Cc: dns-security@TIS.COM Subject: Re: meeting in Stockholm?? In-Reply-To: <199507241514.AAA07143@necom830.cc.titech.ac.jp> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 25 Jul 1995, Masataka Ohta wrote: > Donald; > > > Ohta San, > > > > I believe that the next version of the draft, which I plan to have out > > next week, will address most of your concerns. While it is true that > > in the past, even when you spoke to me in person at Danvers, I did not > > fully understand these, I believe that I do now. > > I haven't had enough time to review all the part of your draft. > > But, at least, your draft ignores the WG consensus at the > last meeting that non-authoritative delegation RRs do not > have to and should not be authenticated by parent zones. I think the draft follows the consensus. See sections 2.3.4 which says that only the KEY RR (for which the parent zone is authoritative) should be signed by the parent (and the NXT RR but you don't see that on "delegation packets"). > As discussed in the meeting, the ignorance makes delegation packets > unnecessarily lengthy so that 512 bytes won't be enough. > > I'd like to propose that, instead of seeking your own way only > to make secure DNS complex, you should merge your partially It's my opinion that, while the original proposal by myself and Charlie Kaufman was more complex than yours, our current proposal is simpler. > implemented proposal with mine whose implementation of > export-free, almost-complete nameserver has been running for > these 8 monthes after my 2 weeks of hacking. I am not doing the implementation so I don't have any ability to make decisions concerning "merging" of implementations. > Masataka Ohta Donald ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)   Received: from relay.tis.com by neptune.TIS.COM id aa03050; 25 Jul 95 9:29 EDT Received: from holmes.umd.edu(129.2.128.24) by relay.tis.com via smap (g3.0.1) id xma022342; Tue, 25 Jul 95 09:22:12 -0400 Received: from UMDD (umdd.umd.edu [128.8.170.13]) by holmes.umd.edu(8.6.12/94Mar10) with SMTP id JAA32106; Tue, 25 Jul 1995 09:29:37 -0400 Message-Id: <199507251329.JAA32106@holmes.umd.edu> Received: by UMDD.UMD.EDU id 3964 ; 25 Jul 95 09:29:39 EDT Received: by UMDD (Mailer R2.10 ptf000) id 3964; Tue, 25 Jul 95 09:29:39 EDT Date: Tue, 25 Jul 95 09:13:43 EDT From: Bruce Crabill Subject: comments on NXT RR To: DNS-SECURITY@TIS.COM I've been reading draft-ietf-dnssec-secext-04.txt and have a few comments about section 5, the section dealing with the NXT RR. I realize that the NXT RR is realitively new (used to be the NXD RR but was renamed when the bitmap was added), but the documentation for the RR needs to be made a bit clearer. You don't really say what the bitmap is a bitmap of (you get the impression that it is a bitmap of RR types (as in the WKS bitmap of protocols), but this isn't clearly stated, nor is the structure of the bitmap defined. The example on the bottom of page 27 implies that the bitmap has a value of 130. I'm not sure how to interept this. If it is decimal, then you are saying that it applies to DNS RR types 0 and 6. Also, has the FTP site for the archives changed? The last archive on FTP.TIS.COM is 9411 and I can't seem to find any place where the NXT RR was discussed. Bruce   Received: from relay.tis.com by neptune.TIS.COM id aa00572; 26 Jul 95 17:32 EDT Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (g3.0.1) id xma016332; Wed, 26 Jul 95 17:25:26 -0400 Received: from magellan.tis.com by tis.com (4.1/SUN-5.64) id AA06086; Wed, 26 Jul 95 17:31:41 EDT Message-Id: <9507262131.AA06086@tis.com> Reply-To: James M Galvin To: dns-security@TIS.COM Subject: ANNOUNCE: TIS/DNSSEC Version 1.0 alpha is now available Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <26084.806794299.1@tis.com> Date: Wed, 26 Jul 1995 17:31:43 -0400 From: James M Galvin Trusted Information Systems is pleased to announce the availability of a secure DNS: TIS/DNSSEC Version 1.0 alpha. It provides integrity and authentication services for DNS resource records using digital signature technology. It is being made available for alpha testing on the following basis. o TIS/DNSSEC is available via anonymous FTP in source code form. All modules have been written in the C programming language and it is known to run on many UNIX-derived operating systems. o This version of TIS/DNSSEC depends on a specialized version of TIS/MOSS, which is currently included in the distribution. o This version of TIS/DNSSEC is not available outside the United States or Canada, nor can you give it to anyone who is not a U.S. or Canadian citizen and does not have a U.S. "green card." (These are U.S. State and Commerce Department requirements because of the use of TIS/MOSS. We hope to be able to remove this restriction in a future version.) This version of TIS/DNSSEC is an alpha implementation because it does not implement the entire specification. As soon as we complete the implementation it will be a beta distribution until the code stabilizes. TIS/DNSSEC is a product of Trusted Information Systems that may be used free of charge during the alpha test period. Instructions on how to retrieve TIS/DNSSEC Version 1.0 alpha may be found in the file "/pub/DNSSEC/README" on the host "ftp.tis.com" which may be retrieved via anonymous ftp. If you have any questions or comments please send email to "tisdnssec-support@tis.com".   Received: from relay.tis.com by neptune.TIS.COM id aa00632; 26 Jul 95 17:38 EDT Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (g3.0.1) id xma016403; Wed, 26 Jul 95 17:31:30 -0400 Received: from magellan.tis.com by tis.com (4.1/SUN-5.64) id AA06321; Wed, 26 Jul 95 17:37:45 EDT Message-Id: <9507262137.AA06321@tis.com> Reply-To: James M Galvin To: dns-security@TIS.COM Subject: WG Last Call: draft-ietf-dnssec-secext-04.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <26111.806794666.1@tis.com> Date: Wed, 26 Jul 1995 17:37:47 -0400 From: James M Galvin Speaking as chair of the DNS Security Working Group, I would like to announce a working group last call on the following document: draft-ietf-dnssec-secext-04.txt This document will be submitted to the IESG on or after August 16 (3 weeks from now) for consideration as a Proposed Standard unless it is found to be technically flawed. Speak now (on technical flaws) or forever hold your peace. Jim   Received: from relay.tis.com by neptune.TIS.COM id aa28048; 2 Aug 95 3:25 EDT Received: from necom830.cc.titech.ac.jp(131.112.32.132) by relay.tis.com via smap (g3.0.1) id xma011675; Wed, 2 Aug 95 03:17:18 -0400 Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Wed, 2 Aug 1995 16:19:36 +0900 From: Masataka Ohta MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM Message-Id: <199508020719.QAA06514@necom830.cc.titech.ac.jp> Subject: Re: meeting in Stockholm?? To: "Donald E. Eastlake 3rd" Date: Wed, 2 Aug 95 16:19:35 JST Cc: dns-security@TIS.COM In-Reply-To: ; from "Donald E. Eastlake 3rd" at Jul 24, 95 6:19 pm X-Mailer: ELM [version 2.3 PL11] > > > I believe that the next version of the draft, which I plan to have out > > > next week, will address most of your concerns. While it is true that > > > in the past, even when you spoke to me in person at Danvers, I did not > > > fully understand these, I believe that I do now. > > > > I haven't had enough time to review all the part of your draft. > > > > But, at least, your draft ignores the WG consensus at the > > last meeting that non-authoritative delegation RRs do not > > have to and should not be authenticated by parent zones. > > I think the draft follows the consensus. See sections 2.3.4 which > says that only the KEY RR (for which the parent zone is authoritative) > should be signed by the parent (and the NXT RR but you don't see that > on "delegation packets"). I'm afraid you still misunderstand what "authoritative" means. > > As discussed in the meeting, the ignorance makes delegation packets > > unnecessarily lengthy so that 512 bytes won't be enough. And this issue remains unsolved. > > I'd like to propose that, instead of seeking your own way only > > to make secure DNS complex, you should merge your partially > > It's my opinion that, while the original proposal by myself and > Charlie Kaufman was more complex than yours, our current proposal is > simpler. It is no excuse that you made a bad proposal less bad, especially in the face of a good proposal. > > implemented proposal with mine whose implementation of > > export-free, almost-complete nameserver has been running for > > these 8 monthes after my 2 weeks of hacking. > > I am not doing the implementation so I don't have any ability to make > decisions concerning "merging" of implementations. I'm talking not about implementations but about specifications, only one of which is implemented. Masataka Ohta   Received: from relay.tis.com by neptune.TIS.COM id aa00737; 2 Aug 95 7:20 EDT Received: from necom830.cc.titech.ac.jp(131.112.32.132) by relay.tis.com via smap (g3.0.1) id xma013007; Wed, 2 Aug 95 07:12:44 -0400 Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Wed, 2 Aug 1995 20:16:49 +0859 From: Masataka Ohta Message-Id: <199508021117.UAA08574@necom830.cc.titech.ac.jp> Subject: Re: WG Last Call: draft-ietf-dnssec-secext-04.txt To: galvin@TIS.COM Date: Wed, 2 Aug 95 20:16:48 JST Cc: dns-security@TIS.COM In-Reply-To: <9507262137.AA06321@tis.com>; from "James M Galvin" at Jul 26, 95 5:37 pm X-Mailer: ELM [version 2.3 PL11] > Speaking as chair of the DNS Security Working Group, I would like to > announce a working group last call on the following document: > > draft-ietf-dnssec-secext-04.txt I don't think we are ready to proceed. > This document will be submitted to the IESG on or after August 16 (3 > weeks from now) for consideration as a Proposed Standard unless it is > found to be technically flawed. Why didn't you have a meeting or two at Stockholm, if you want to have an intense discussion? Yes, it is technically flawed. If you don't think so, give a full implementation. Moreover, E&K proposal is not compared to the alternative proposal of mine, because, at the last meeting, you forced your wrong view that the difference is merely on the number of RR types. > Speak now (on technical flaws) or forever hold your peace. While your misjudgement was understandable at the time of the last meeting, I really hope you not repeat it again. Masataka Ohta   Received: from relay.tis.com by neptune.TIS.COM id aa14120; 2 Aug 95 21:44 EDT Received: from big-screw.mit.edu(18.72.0.176) by relay.tis.com via smap (g3.0.1) id xma026175; Wed, 2 Aug 95 21:36:16 -0400 Received: by big-screw id AA15630; Wed, 2 Aug 95 21:44:19 -0400 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 2 Aug 1995 21:44:31 -0400 To: dns-security@TIS.COM From: "Jeffrey I. Schiller" Subject: Re: WG Last Call: draft-ietf-dnnsec-secext-04.txt I will re-iterate a comment I made in private in Stockholm. I would strongly suggest that the signature computation be exactly compatible with that performed by the RSAREF toolkit (not to mention other toolkits, PEM and PGP which all conform to the PKCS standard for signatures). The current documented version is only "close." -Jeff   Received: from relay.tis.com by neptune.TIS.COM id aa27990; 3 Aug 95 14:30 EDT Received: from callandor.cybercash.com(204.178.186.70) by relay.tis.com via smap (g3.0.1) id xma006281; Thu, 3 Aug 95 14:21:47 -0400 Received: by callandor.cybercash.com; id OAA08504; Thu, 3 Aug 1995 14:19:50 -0400 Received: from cybercash.com(204.254.34.52) by callandor.cybercash.com via smap (g3.0.1) id xma008500; Thu, 3 Aug 95 14:19:42 -0400 Received: by cybercash.com.cybercash.com (4.1/SMI-4.1) id AA04174; Thu, 3 Aug 95 14:23:10 EDT Date: Thu, 3 Aug 1995 14:23:09 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: James M Galvin Cc: dns-security@TIS.COM Subject: Re: WG Last Call: draft-ietf-dnssec-secext-04.txt In-Reply-To: <9507262137.AA06321@tis.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 26 Jul 1995, James M Galvin wrote: > Speaking as chair of the DNS Security Working Group, I would like to > announce a working group last call on the following document: > > draft-ietf-dnssec-secext-04.txt > > This document will be submitted to the IESG on or after August 16 (3 > weeks from now) for consideration as a Proposed Standard unless it is > found to be technically flawed. > > Speak now (on technical flaws) or forever hold your peace. > > Jim I would like to make the following minor changes. I do not believe these have any techncial effect. (1) As suggested by Jeff Schiller, change the RSA algorithm signature to be exactly PKCS1. (see his message below) This mostly involved adding the MD5 OID algorithm identifier to the MD5 message digest before encrypting with the private key. It would make it possible to implement DNSSEC with RSAREF. (2) Since MOSS has now gone to Proposed Standard, I want to reserve bit 9 in the KEY RR flags to indicate MOSS. (3) Due to the message sent by Bruce Crabill below, I would like to add the following clarifying text to section 5 and to change the examle to use a list of RR type mnemonics. "The NXT RR type bit map is one bit per RR type present for the owner name similar to the WKS socket bit map. The first bit represents RR type zero (an illegal type which should not be present.) A one bit indicates that at least one RR of that type is present for the owner name. A zero indicates that no such RR is present. All bits not specified because they are beyond the end of the bit map are assumed to be zero. Note that bit 30, for NXT, will always be on so the minimum bit map length is actually four octets. The NXT bit map should be printed as a list of type mnemonics or decimal numbers similar to the WKS RR." I believe these changes are not of a type that would require delaying forwarding the draft to the IESG. Donald From jis@mit.eduThu Aug 3 13:13:13 1995 Date: Wed, 2 Aug 1995 21:44:31 -0400 From: "Jeffrey I. Schiller" To: dns-security@TIS.COM Subject: Re: WG Last Call: draft-ietf-dnnsec-secext-04.txt I will re-iterate a comment I made in private in Stockholm. I would strongly suggest that the signature computation be exactly compatible with that performed by the RSAREF toolkit (not to mention other toolkits, PEM and PGP which all conform to the PKCS standard for signatures). The current documented version is only "close." -Jeff From BRUCE@umdd.umd.eduThu Aug 3 13:23:50 1995 Date: Tue, 25 Jul 95 09:13:43 EDT From: Bruce Crabill To: DNS-SECURITY@TIS.COM Subject: comments on NXT RR I've been reading draft-ietf-dnssec-secext-04.txt and have a few comments about section 5, the section dealing with the NXT RR. I realize that the NXT RR is realitively new (used to be the NXD RR but was renamed when the bitmap was added), but the documentation for the RR needs to be made a bit clearer. You don't really say what the bitmap is a bitmap of (you get the impression that it is a bitmap of RR types (as in the WKS bitmap of protocols), but this isn't clearly stated, nor is the structure of the bitmap defined. The example on the bottom of page 27 implies that the bitmap has a value of 130. I'm not sure how to interept this. If it is decimal, then you are saying that it applies to DNS RR types 0 and 6. ... ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)   Received: from relay.tis.com by neptune.TIS.COM id aa10721; 8 Aug 95 12:16 EDT Received: from ietf.cnri.reston.va.us(132.151.1.35) by relay.tis.com via smap (g3.0.1) id xmad01879; Tue, 8 Aug 95 12:07:20 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa14163; 8 Aug 95 12:04 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM cc: dns-security@TIS.COM From: Internet-Drafts@cnri.reston.va.us Reply-to: Internet-Drafts@cnri.reston.va.us Subject: I-D ACTION:draft-ietf-dnssec-as-map-02.txt Date: Tue, 08 Aug 95 12:04:40 -0400 Sender: cclark@cnri.reston.va.us Message-ID: <9508081204.aa14163@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Security Working Group of the IETF. Title : Mapping Autonomous Systems Number into the Domain Name System Author(s) : D. Eastlake Filename : draft-ietf-dnssec-as-map-02.txt Pages : 9 Date : 08/07/1995 One requirement of secure routing is that independent routing entities, such as those identified by Internet Autonomous System Numbers, be able to authenticate messages to each other. Modifications currently being developed (see draft-ietf-dnssec-secext-*.txt) to the Domain Name System will enable it to be used for authenticated public key distribution. This draft maps all Autonomous System numbers into DNS Domain Names so that the DNS can be used to distribute their public keys. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnssec-as-map-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-as-map-02.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dnssec-as-map-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19950807171114.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-as-map-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-as-map-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950807171114.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart--   Received: from relay.tis.com by neptune.TIS.COM id aa21112; 11 Aug 95 14:28 EDT Received: from callandor.cybercash.com(204.178.186.70) by relay.tis.com via smap (g3.0.1) id xma020516; Fri, 11 Aug 95 14:20:07 -0400 Received: by callandor.cybercash.com; id OAA19114; Fri, 11 Aug 1995 14:22:28 -0400 Received: from cybercash.com(204.254.34.52) by callandor.cybercash.com via smap (g3.0.1) id xma019108; Fri, 11 Aug 95 14:22:14 -0400 Received: by cybercash.com.cybercash.com (4.1/SMI-4.1) id AA14106; Fri, 11 Aug 95 14:26:08 EDT Date: Fri, 11 Aug 1995 14:26:07 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: dns-security@TIS.COM Subject: Re: WG Last Call: draft-ietf-dnssec-secext-04.txt In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Since there have not been any particular objections, I have incorporated the changes listed in my 3 August message with exact wording indicated below interspersed with my original message. In addition, I would like to make the following minor clarifications in the next few days in connection with dynamic update. (1) Add an explicit statement that a SIG RR with an expiration date before the date signed is ineffective. (2) Add an explicit statement that SIG RRs should not have a date signed significantly in the future. and (3) Add an explicit statement that, to prevent misordering of network request to update a zone dynamically, monotonically increasing "time signed" dates are necessary. Donald On Thu, 3 Aug 1995, Donald E. Eastlake 3rd wrote: > On Wed, 26 Jul 1995, James M Galvin wrote: > > Speaking as chair of the DNS Security Working Group, I would like to > > announce a working group last call on the following document: > > > > draft-ietf-dnssec-secext-04.txt > > > > This document will be submitted to the IESG on or after August 16 (3 > > weeks from now) for consideration as a Proposed Standard unless it is > > found to be technically flawed. > > > > Speak now (on technical flaws) or forever hold your peace. > > > > Jim > > I would like to make the following minor changes. I do not > believe these have any techncial effect. > > (1) As suggested by Jeff Schiller, change the RSA algorithm signature > to be exactly PKCS1. (see his message below) This mostly involved > adding the MD5 OID algorithm identifier to the MD5 message digest > before encrypting with the private key. It would make it possible to > implement DNSSEC with RSAREF. -- exact source changed/reordered .in +3 .ne 3 hash = MD5 ( data ) signature = ( 01 | FF* | 00 | prefix | hash ) ** e (mod n) .in -3 where MD5 is the message digest algorithm documented in RFC 1321, "|" is concatenation, "e" is the secret key exponent of the signer, and "n" is the public modulus of the signer's public key. 01, FF, and 00 are fixed octets of the corresponding hexadecimal value. "prefix" is the ASN.1 BER MD5 algorithm designator prefix specified in PKCS1, that is, .br .ti +5 hex 3020300c06082a864886f70d020505000410 [NETSEC]. .br The FF octet is repeated the maximum number of times such that the value of the quantity being exponentiated is one octet shorter than the value of n. The above specifications are exactly Public Key Cryptographic Standard #1 [PKCS1]. The size of n, including most and least significant bits (which will be 1) SHALL be not less than 512 bits and not more than 2552 bits. n and e SHOULD be chosen such that the public exponent is small. Leading zeros bytes are not permitted in the MD5/RSA algorithm signature. -- end exact source changed/reordered > (2) Since MOSS has now gone to Proposed Standard, I want to reserve > bit 9 in the KEY RR flags to indicate MOSS. -- begin exact changed source Bit 8 is reserved to be the "IPSEC" bit and indicate that this key is valid for use in conjunction with the IP level security standard. This key could be used in connection with secured communication on behalf of an end entity or user whose name is the owner name of the KEY RR if the entity or user bits are on. The presence of a KEY resource with the IPSEC and entity bits on and experimental and no-key bits off is a guarantee that the host speaks IPSEC. .ti +5 Bit 9 is reserved to be the "MOSS" bit and indicate that this key is valid for use in conjunction with MIME object security standard. This key could be used in connection with secured communication on behalf of an end entity or user whose name is the owner name of the KEY RR if the entity or user bits are on. The presence of a KEY resource with the MOSS and entity bits on and experimental and no-key bits off is a guarantee that the host speaks MOSS. .ti +5 Bits 10-11 are reserved and must be zero. -- end exact changed source > (3) Due to the message sent by Bruce Crabill below, I would like to > add the following clarifying text to section 5 and to change the > examle to use a list of RR type mnemonics. > "The NXT RR type bit map is one bit per RR type present for the owner > name similar to the WKS socket bit map. The first bit represents RR > type zero (an illegal type which should not be present.) A one bit > indicates that at least one RR of that type is present for the owner > name. A zero indicates that no such RR is present. All bits not > specified because they are beyond the end of the bit map are assumed > to be zero. Note that bit 30, for NXT, will always be on so the > minimum bit map length is actually four octets. The NXT bit map > should be printed as a list of type mnemonics or decimal numbers > similar to the WKS RR." Exact text above added and example line changed to the following: big.foo.bar. NXT medium.foo.bar. A, MX, SIG, NXT > I believe these changes are not of a type that would require delaying > forwarding the draft to the IESG. > > Donald > > > >From jis@mit.eduThu Aug 3 13:13:13 1995 > Date: Wed, 2 Aug 1995 21:44:31 -0400 > From: "Jeffrey I. Schiller" > To: dns-security@TIS.COM > Subject: Re: WG Last Call: draft-ietf-dnnsec-secext-04.txt > > I will re-iterate a comment I made in private in Stockholm. I would > strongly suggest that the signature computation be exactly compatible with > that performed by the RSAREF toolkit (not to mention other toolkits, PEM > and PGP which all conform to the PKCS standard for signatures). The current > documented version is only "close." > > -Jeff > > > >From BRUCE@umdd.umd.eduThu Aug 3 13:23:50 1995 > Date: Tue, 25 Jul 95 09:13:43 EDT > From: Bruce Crabill > To: DNS-SECURITY@TIS.COM > Subject: comments on NXT RR > > I've been reading draft-ietf-dnssec-secext-04.txt and have a few comments > about section 5, the section dealing with the NXT RR. I realize that the > NXT RR is realitively new (used to be the NXD RR but was renamed when the > bitmap was added), but the documentation for the RR needs to be made a bit > clearer. You don't really say what the bitmap is a bitmap of (you get the > impression that it is a bitmap of RR types (as in the WKS bitmap of > protocols), but this isn't clearly stated, nor is the structure of the > bitmap defined. The example on the bottom of page 27 implies that the > bitmap has a value of 130. I'm not sure how to interept this. If it is > decimal, then you are saying that it applies to DNS RR types 0 and 6. > ... > > ===================================================================== > Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com > 318 Acton Street +1 508-371-7148(fax) dee@world.std.com > Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) > ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)   Received: from relay.tis.com by neptune.TIS.COM id aa17255; 13 Aug 95 9:52 EDT Received: from necom830.cc.titech.ac.jp(131.112.32.132) by relay.tis.com via smap (g3.0.1) id xma002889; Sun, 13 Aug 95 09:43:14 -0400 Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Sun, 13 Aug 1995 22:47:47 +0859 From: Masataka Ohta Message-Id: <199508131348.WAA25745@necom830.cc.titech.ac.jp> Subject: Re: WG Last Call: draft-ietf-dnssec-secext-04.txt To: "Donald E. Eastlake 3rd" Date: Sun, 13 Aug 95 22:47:46 JST Cc: dns-security@TIS.COM In-Reply-To: ; from "Donald E. Eastlake 3rd" at Aug 11, 95 2:26 pm X-Mailer: ELM [version 2.3 PL11] > Since there have not been any particular objections, I have incorporated > the changes listed in my 3 August message with exact wording indicated > below interspersed with my original message. Why are you so much interested in revising your proposal which is proven to be broken to unnecessarily cause UDP packet size overflow? Masataka Ohta   Received: from relay.tis.com by neptune.TIS.COM id aa22870; 13 Aug 95 22:09 EDT Received: from callandor.cybercash.com(204.178.186.70) by relay.tis.com via smap (g3.0.1) id xma005112; Sun, 13 Aug 95 21:59:55 -0400 Received: by callandor.cybercash.com; id WAA03832; Sun, 13 Aug 1995 22:02:17 -0400 Received: from cybercash.com(204.254.34.52) by callandor.cybercash.com via smap (g3.0.1) id xma003830; Sun, 13 Aug 95 22:02:17 -0400 Received: by cybercash.com.cybercash.com (4.1/SMI-4.1) id AA21607; Sun, 13 Aug 95 22:06:14 EDT Date: Sun, 13 Aug 1995 22:06:13 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: dns-security@TIS.COM Subject: Re: WG Last Call: draft-ietf-dnssec-secext-04.txt In-Reply-To: <199508131348.WAA25745@necom830.cc.titech.ac.jp> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Ohta-san, On Sun, 13 Aug 1995, Masataka Ohta wrote: > > Since there have not been any particular objections, I have incorporated > > the changes listed in my 3 August message with exact wording indicated > > below interspersed with my original message. > > Why are you so much interested in revising your proposal which > is proven to be broken to unnecessarily cause UDP packet size > overflow? I have suggest six very minor changes to the draft and I think the reasons for each should have been clear. In the initial batch of three, one was specifically requested by the Security Area Head so that DNS RSA signatures could be calculated by RSAREF, on was simply a clarification requested by a mailing list participant, and one was the reservation of an additional KEY RR bit because MOSS has gone to Proposed Standard. The second batch were all requested by the editor of the DNS Dyanmic Update Draft. On Wed, 2 Aug 1995, Masataka Ohta wrote: > [responding to a posting by Jim Galvin, DNSSEC WG Chair:] > > Speaking as chair of the DNS Security Working Group, I would like to > > announce a working group last call on the following document: > > > > draft-ietf-dnssec-secext-04.txt > > I don't think we are ready to proceed. I believe the consensus is that we are ready. > > This document will be submitted to the IESG on or after August 16 (3 > > weeks from now) for consideration as a Proposed Standard unless it is > > found to be technically flawed. > > Why didn't you have a meeting or two at Stockholm, if you want to have > an intense discussion? > > Yes, it is technically flawed. If you don't think so, give a full > implementation. If you believe the current proposal has flaws, that you can not persuade other of, but will be shown by implementation, you need only sit back and these will become aparent, will they not? > Moreover, E&K proposal is not compared to the alternative proposal of > mine, because, at the last meeting, you forced your wrong view that > the difference is merely on the number of RR types. If you beieve that you were not treated fairly at the last DNS SEC working group meeting, you have had ample time to post to the mailing list. I have seen very few postings from you and none addressing this point. > > Speak now (on technical flaws) or forever hold your peace. > > While your misjudgement was understandable at the time of > the last meeting, I really hope you not repeat it again. It seems to me that, very roughly, there are two possible levels of problem. One relates to such matters as efficiency, how many retrievals will overflow the UDP packet maximum, etc., but does not generally touch on correct operation of the protocol. It is clear that in this area you have your own opinions but they differ from the working group consensus. You have not persuaded the working group to your opinion and I do not think you will be able to do so at this point. There is also a second level of problem which would be a clear case where the protocol, as described, acted incorrectly. By this I do not mean, for example, the problems with securing CNAME RRs in old servers, becasue that problem is documented in the draft. I mean some case of incorrect operation that has not been considered or documented. If you know of a problem of this second type, it should be possible for you to describe an exact, clear, and complete exmaple which would produce such incorrect (not just "inefficient") results, and I would suggest that you do so. > Masataka Ohta Donald ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)   Received: from relay.tis.com by neptune.TIS.COM id aa25392; 19 Aug 95 23:25 EDT Received: from callandor.cybercash.com(204.178.186.70) by relay.tis.com via smap (g3.0.1) id xma006386; Sat, 19 Aug 95 23:16:03 -0400 Received: by callandor.cybercash.com; id XAA28185; Sat, 19 Aug 1995 23:18:23 -0400 Received: from cybercash.com(204.254.34.52) by callandor.cybercash.com via smap (g3.0.1) id xma028180; Sat, 19 Aug 95 23:18:01 -0400 Received: by cybercash.com.cybercash.com (4.1/SMI-4.1) id AA27047; Sat, 19 Aug 95 23:22:25 EDT Date: Sat, 19 Aug 1995 23:22:24 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: dns-security@TIS.COM Subject: Re: WG Last Call: draft-ietf-dnssec-secext-04.txt (fwd) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Since there was no objection to the changes listed below, I have incorporated them. Donald ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) ---------- Forwarded message ---------- Date: Fri, 11 Aug 1995 14:26:07 -0400 (EDT) From: Donald E. Eastlake 3rd To: dns-security@TIS.COM Subject: Re: WG Last Call: draft-ietf-dnssec-secext-04.txt ... In addition, I would like to make the following minor clarifications in the next few days in connection with dynamic update. (1) Add an explicit statement that a SIG RR with an expiration date before the date signed is ineffective. (2) Add an explicit statement that SIG RRs should not have a date signed significantly in the future. and (3) Add an explicit statement that, to prevent misordering of network request to update a zone dynamically, monotonically increasing "time signed" dates are necessary. Donald ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)   Received: from relay.tis.com by neptune.TIS.COM id aa06944; 23 Aug 95 8:29 EDT Received: from sun4nl.nl.net(193.78.240.1) by relay.tis.com via smap (g3.0.1) id xma017473; Wed, 23 Aug 95 08:19:49 -0400 Received: from baltzer.nl by sun4nl.NL.net with SMTP id AA16480 (5.65b/CWI-3.3); Wed, 23 Aug 1995 14:15:32 +0200 Date: Wed, 23 Aug 1995 14:15:32 +0200 Message-Id: <9508231215.AA16480@sun4nl.NL.net> X-Sender: Pbaltzer@sun4nl.nluug.nl Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: From: Baltzer Science Publishers Subject: WIRELESS NETWORKS - CONTENTS CONTENTS WIRELESS NETWORKS, ISSN 1022-0038, Co-published with the ACM (Association for Computing Machinery) The journal of mobile communication, computation and information Editor-in-Chief: I. Chlamtac, Department of Electrical and Computer Engineering, University of Massachusetts, Amherst MA 01003, USA Aims & Scope: The wireless communication revolution is bringing fundamental changes to communication and computing. From wide-area cellular systems to wireless LANs, mobile and wireless networks are on the verge of providing fully distributed and ubiquitous mobile computing and communications any time, anywhere.Through a seamless integration with fixed network infrastructures the future promises a universal communication grid, bringing an end to the tyranny of geography. A parallel evolution and proliferation of services for the mobile user are changing the scope of communication and the nature of user and machine interaction paradigms. Wireless Networks will serve as the publication vehicle for high-quality, in-depth original articles addressing networks, systems, algorithms, and applications that support the symbiosis of portable computers, wireless networks, mobile communication and computation, and their integration into the global network of the future. Regularly addressed topics will include: Network architectures for nomadic LAN to WAN communication and computation; mobile and wireless communications protocols, media access control algorithms, algorithms for mobility and mobility management including hand-off, registration, location, tracking, and routing; performance evaluation of mobile/wireless networks; systems topology design including cell architectures, capacity allocation and coverage issues, mobility, bandwidth, or intermittent connectivity related communication and computing issues; network management, control and signaling; security, scalability and reliability issues; database design and management for mobility; software principles, operating systems and resource management for nomadic computing; service integration and interworking of wired and wireless networks; applications, computing services and service algorithms in the mobile environment; enabling technologies for wireless and mobile communication including wireless signal propagation studies, portable hardware technologies, energy efficient and low-power design and components; network demonstrations, experimentation, and testbeds. Contents Volume 1, No. II pp. 129-138, J.P.M.G. Linnartz, On the performance of packet switched cellular networks for wireless data communication pp. 139-146, Z. Haas and S. Paul, Limited lifetime shared access in mobile systems pp. 147-160, I Rubin and S. Shambayati, Performance evaluation of a reservation random access scheme for packetized wireless systems with call control and hand-off loading pp. 161-174, K.Y. Eng, M.J. Karol, M. Veeraraghavan, E. Ayanoglu, C.B. Woodworth, and R.A. Valenzuela, A wireless broadband ad-hoc ATM local-area network pp. 175-186, A. Bar-Noy, I. Kessler and M. Sidi, Mobile users: To update or not to update? pp. 187-196, I. Akyildiz and J. S.M. Ho, Dynamic mobile user location update for wireless PCS networks pp. 197-210, R. Jain and Yi-Bing Lin, An auxiliary user location strategy employing forward pointers to reduce network impacts of PCS pp. 211-220, C. Rose and R. Yates, Minimizing the average cost of paging under delay constraints pp. 221-226, A. Farago, On the complexity of finding sparsest and densest parts in wireless networks pp. 227-239, M. Zorzi, Mobile radio slotted ALOHA with capture and diversity Submissions of articles and proposals for special issues are to be addressed to the Editor-in-Chief: I. Chlamtac Requests for FREE SPECIMEN copies and orders for Wireless Networks are to be sent to: E-mail: publish@baltzer.nl or see our homepage http://www.NL.net/~baltzer/ .   Received: from relay.tis.com by neptune.TIS.COM id aa13417; 24 Aug 95 13:57 EDT Received: from ietf.cnri.reston.va.us(132.151.1.35) by relay.tis.com via smap (g3.0.1) id xma010567; Thu, 24 Aug 95 13:47:26 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa15334; 24 Aug 95 13:46 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@TIS.COM MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM cc: dns-security@TIS.COM From: Internet-Drafts@cnri.reston.va.us Reply-to: Internet-Drafts@cnri.reston.va.us Subject: I-D ACTION:draft-ietf-dnssec-secext-05.txt Date: Thu, 24 Aug 95 13:46:57 -0400 Sender: cclark@cnri.reston.va.us Message-ID: <9508241346.aa15334@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Security Working Group of the IETF. Title : Domain Name System Security Extensions Author(s) : D. Eastlake, C. Kaufman Filename : draft-ietf-dnssec-secext-05.txt Pages : 41 Date : 08/23/1995 The Domain Name System (DNS) has become a critical operational part of the Internet infrastructure yet it has no strong security mechanisms to assure data integrity or authentication. Extensions to the DNS are described that provide these services to security aware resolvers or applications through the use of cryptographic digital signatures. These digital signatures are included in secured zones as resource records. Security can still be provided even through non-security aware DNS servers in many cases. The extensions also provide for the storage of authenticated public keys in the DNS. This storage of keys can support general public key distribution service as well as DNS security. The stored keys enable security aware resolvers to learn the authenticating key of zones in addition to keys for which they are initially configured. Keys associated with DNS names can be retrieved to support other protocols. Provision is made for a variety of key types and algorithms. In addition, the security extensions provide for the optional authentication of DNS protocol transactions. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnssec-secext-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-secext-05.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dnssec-secext-05.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19950823133519.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-secext-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-secext-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950823133519.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart--   Received: from relay.tis.com by neptune.TIS.COM id aa08603; 25 Aug 95 13:59 EDT Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (g3.0.1) id xma026169; Fri, 25 Aug 95 13:49:23 -0400 Received: from antares.tis.com by tis.com (4.1/SUN-5.64) id AA20300; Fri, 25 Aug 95 13:57:58 EDT Message-Id: <9508251757.AA20300@tis.com> Reply-To: James M Galvin To: dns-security@TIS.COM Cc: Jeffrey I Schiller Subject: Re: WG Last Call: draft-ietf-dnssec-secext-04.txt In-Reply-To: "Donald E. Eastlake 3rd"'s message of Sat, 19 Aug 1995 23:22:24 EDT. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <18936.809373492.1@tis.com> Date: Fri, 25 Aug 1995 13:58:17 -0400 From: James M Galvin The Last Call period officially ended last week and a new version of the document has been issued with the suggested changes. Since no technical problems have been found with the specification, I'm declaring the working group consensus to be to move the document forward. With this note I'm officially forwarding the document: draft-ietf-dnssec-secext-05.txt as a product of this working group to the Security Area Director to be considered for publication as a Proposed Standard. Jim   Received: from relay.tis.com by neptune.TIS.COM id aa11593; 25 Aug 95 16:32 EDT Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (g3.0.1) id xma028781; Fri, 25 Aug 95 16:22:21 -0400 Received: from antares.tis.com by tis.com (4.1/SUN-5.64) id AA06423; Fri, 25 Aug 95 16:30:56 EDT Message-Id: <9508252030.AA06423@tis.com> Reply-To: James M Galvin From: James M Galvin To: dns-security@TIS.COM Subject: ANNOUNCE: TIS/DNSSEC Version 1.1 alpha is now available Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <23285.809382675.1@tis.com> Date: Fri, 25 Aug 1995 16:31:16 -0400 Sender: galvin@TIS.COM Trusted Information Systems is pleased to announce the availability of a secure DNS: TIS/DNSSEC Version 1.1 alpha. It provides integrity and authentication services for DNS resource records using digital signature technology. It is being made available for alpha testing on the following basis. o TIS/DNSSEC is available via anonymous FTP in source code form. All modules have been written in the C programming language and it is known to run on many UNIX-derived operating systems. o This version of TIS/DNSSEC depends on a specialized version of TIS/MOSS, which is currently included in the distribution. The next version will depend exclusively on RSAREF. o This version of TIS/DNSSEC is not available outside the United States or Canada, nor can you give it to anyone who is not a U.S. or Canadian citizen and does not have a U.S. "green card." (These are U.S. State and Commerce Department requirements because of the use of TIS/MOSS. We hope to be able to remove this restriction in a future version.) This version of TIS/DNSSEC is an alpha implementation because it does not implement the entire specification. As soon as we complete the implementation it will be a beta distribution until the code stabilizes. TIS/DNSSEC is a product of Trusted Information Systems that may be used free of charge during the alpha test period. Instructions on how to retrieve TIS/DNSSEC Version 1.1 alpha may be found in the file "/pub/DNSSEC/README" on the host "ftp.tis.com" which may be retrieved via anonymous ftp. If you have any questions or comments please send email to "tisdnssec-support@tis.com".   Received: from relay.tis.com by neptune.TIS.COM id aa26562; 26 Aug 95 15:06 EDT Received: from big-screw.mit.edu(18.72.0.176) by relay.tis.com via smap (g3.0.1) id xma006296; Sat, 26 Aug 95 14:56:58 -0400 Received: by big-screw id AA28751; Sat, 26 Aug 95 15:06:51 -0400 X-Sender: jis@e40-po.mit.edu (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 26 Aug 1995 15:07:02 -0400 To: James M Galvin From: "Jeffrey I. Schiller" Subject: Re: WG Last Call: draft-ietf-dnssec-secext-04.txt Cc: dns-security@TIS.COM, Jeffrey I Schiller At 13:58 8/25/95, James M Galvin wrote: >The Last Call period officially ended last week and a new version of the >document has been issued with the suggested changes. > >Since no technical problems have been found with the specification, I'm >declaring the working group consensus to be to move the document >forward. > >With this note I'm officially forwarding the document: > > draft-ietf-dnssec-secext-05.txt > >as a product of this working group to the Security Area Director to be >considered for publication as a Proposed Standard. OK. I'll review it and get back to you (which shouldn't take too long as I have already read through it once). -Jeff   Received: from relay.tis.com by neptune.TIS.COM id aa12901; 27 Aug 95 17:26 EDT Received: from watson.ibm.com(129.34.139.4) by relay.tis.com via smap (g3.0.1) id xma012100; Sun, 27 Aug 95 17:17:04 -0400 Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 1199; Sun, 27 Aug 95 17:27:02 EDT Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.02 on VAGENT2" id 5395; Sun, 27 Aug 1995 17:27:02 EDT Received: from gimili.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2Rx) with TCP; Sun, 27 Aug 95 17:27:02 EDT Received: by gimili.watson.ibm.com (AIX 3.2/UCB 5.64/930311) id AA36586; Sun, 27 Aug 1995 17:26:42 -0400 Date: Sun, 27 Aug 1995 17:26:42 -0400 From: "S.Kutten" Message-Id: <9508272126.AA36586@gimili.watson.ibm.com> To: dns-security@TIS.COM Subject: Call for papers: special issue on security and mobility Call for Papers For the new journal published in cooperation with the ACM: WIRELESS NETWORKS Special Issue: Mobility and Security Scope: Mobility introduces a new dimension to the problem of secure computing and communication. The securing becomes harder and often more important. This is sometimes due to the mobility of the communication devices, sometimes due to the mobility of users (without mobile device), or the mobility of objects, or that of the attackers. Papers are sought that address the requirements, designs, algorithms and implementation experience for securing networks, distributed systems, information, and applications in environments that can support mobility. Possible topics include, but are not limited to: Securing communication and distributed systems, such as: - Internet (TCP/IP, mobile IP, DNS, DHCP) - ATM - CDPD - GSM - SNA - Wireless LAN Cryptographic protocols, such as: - key distribution - authentication - payments - anonymity and privacy Cryptographic functions, such as: - encryption - message authentication - message digest - signatures Computer viruses and worms Security for intelligent and mobile objects and agents Secure electronic commerce Cryptographic hardware Security and cryptography for wireless communication systems. The authors should send 6 copies of their paper to one of the guest editors by November 15, 1995. The following time-table shall be followed: Manuscript Submission Deadline: November 15, 1995 Acceptance Notification: May 15, 1996 Final Manuscript Submission Deadline: July 15, 1996 Expected Publication Date: Last Quarter 1996 E-mail submissions are encouraged (post-script only). Set subject to `Submission to WINET special issue'. Guest Editors: Amir Herzberg IBM T.J. Watson Research Center P.O. Box 704 #H3-D18 Yorktown Heights, NY 10598 Telephone: (914) 784-6981 Facsimile: (914) 784-6205 Internet: amir@watson.ibm.com Shay Kutten IBM T.J. Watson Research Center P.O. Box 704 #H3-D38 Yorktown Heights, NY 10598 Telephone: (914) 784-7346 Facsimile: (914) 784-6205 Internet: kutten@watson.ibm.com   Received: from relay.tis.com by neptune.TIS.COM id aa08897; 11 Sep 95 10:25 EDT Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (g3.0.1) id xma026865; Mon, 11 Sep 95 10:14:07 -0400 Received: from antares.tis.com by tis.com (4.1/SUN-5.64) id AA26161; Mon, 11 Sep 95 10:24:01 EDT Message-Id: <9509111424.AA26161@tis.com> Reply-To: James M Galvin To: dns-security@TIS.COM Subject: ANNOUNCEMENT: TIS/DNSSEC Version 1.2 alpha Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <13577.810829467.1@tis.com> Date: Mon, 11 Sep 1995 10:24:28 -0400 From: James M Galvin A new version of TIS/DNSSEC is now available. This version is distinguished from the previous version as follows. in sync with bind Beta26 uses RSAREF For information on how to acquire TIS/DNSSEC retrieve the file /pub/DNSSEC/README on the host ftp.tis.com via anonymous FTP. If you have any questions or problems please send a note to tisdnssec-support@tis.com. Enjoy, Jim   Received: from relay.tis.com by neptune.TIS.COM id aa21608; 20 Sep 95 18:49 EDT Received: from ns.novell.com(137.65.1.1) by relay.tis.com via smap (g3.0.1) id xma018222; Wed, 20 Sep 95 18:35:00 -0400 Received: from na.SJF.Novell.COM ([130.57.6.3]) by ns.Novell.COM (4.1/SMI-4.1) id AA09207; Wed, 20 Sep 95 16:46:39 MDT Received: by na.SJF.Novell.COM (4.1/SMI-4.1) id AA03331; Wed, 20 Sep 95 15:43:52 PDT From: Alex Alten Message-Id: <9509202243.AA03331@na.SJF.Novell.COM> Subject: comments on secure DNS spec To: dee@cybercash.com, charlie_kaufman@iris.com Date: Wed, 20 Sep 1995 15:43:51 -0700 (PDT) Cc: dns-security@TIS.COM X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 4399 Hello Charles and Donald, I have some comments about the latest secure DNS draft dated Aug. 16. Overall I think the paper is good. It does a clean job of fitting a secure framework over the existing DNS infrastructure. 1. On page 15 the MD5/RSA algorithm is specified as 1. I'd recommend that MD5 not be explicitly specified. The algorithm octet should only specify an (asymmetric) encryption algorithm. For example specify the following on page 21: hash = MD5 ( data ) signature ( 01 | FF* | 00 | prefix | implicit tag | hash ) ** e (mod n) Where 'implicit tag' = A0 10 for MD5 A1 14 for SHA1 The first byte the hex 'A' means an ASN.1 Context specific Class i.e. this document, Constructed constructor i.e. a non-atomic data type (similer a C struct definition). The '0' or '1' are the tag numbers for each hash type. The 2nd byte is simply the number of bytes that will follow it. The ASN.1 grammar notation is as follows: HashMd5 ::= [0] IMPLICIT OCTET STRING (SIZE (16)) HashSha ::= [1] IMPLICIT OCTET STRING (SIZE (20)) The reason I recommend this is for two reasons: A. To allow other protocols to interoperate with this specification. A proposed draft for secure SNMP uses this to specify MD5 and SHA1 hashes. I would like to see secure Telnet and FTP adhere to this as well. This is more a coordination issue among the major Internet protocols, since they may be using secure DNS as a key management server. B. To allow more than one hash to be used. If improved hashes are designed or needed this allows a simple mechanism to upgrade hashes without modifying the algorithm number. 2. Why not use ElGamal instead of RSA for keys and signatures? This is a practical issue. Why not specify ElGamal instead of RSA? the RSA patent has 5 more years before it expires. ElGamal is unpatented and its underlying patent, Diffie-Hellman, expires in 1.5 years. I believe ElGamal is just as strong as RSA and has undergone over a decade of cryptanalysis. It is being used as the foundation of the US Digital Signature Standard. 3. Why not double encrypt the hash during DNS transactions? (pages 10, 22) This requires that a security aware resolver has a public/private key. Basically the resolver generates a SIG by hashing its request, then encrypting it with its own private key, and finally encrypting it with the DNS server's public key. When the server responds it encrypts its SIG hash with its own private key and then with the resolver's public key. The resolver's public key does not have to be stored on the DNS server, it could be sent as part of the request (KEY). Doing this would reduce the possibility of an intermediate gateway from replaying the response to multiple resolvers. Also it prevents the resolver's request from getting modified without detection. 4. Why not securely encapsulate the DNS packet? (pages 10, 22) Why not fully encapsulate the DNS packet, by using an authentication header and having the DNS packet as the data payload. This would simplify authentication machinery. A nice side benefit is that existing DNS servers could be retrofited without rewriting code. You have to fool them into thinking they are receiving the old DNS packet, when in fact the encapsulation machinery first receives, then verifies the authentication header, then strips the header off and finally passes the rest into the old DNS protocol machinery. The old DNS parotocol machinery never has to be recompiled, relinked, etc. The double encryption of the hash from #3 could be used here as well. 4. Why not use a larger key footprint? (page 20) I noticed that you use a "key footprint" of 16 bits. Other protocols that I seen typically use more bits. For example 64 bits (8 bytes). Would this larger size make more sense since DNS is distributed world-wide and there could eventually be millions of keys (assuming it will also be a key management server). Sincerely, - Alex -- Alexander I. Alten Alten@Na.Sjf.Novell.Com (408) 577-8224 Novell, Inc. Member of Technical Staff Mail Stop F1-42-D2 2180 Fortune Drive San Jose, CA 95131 USA   Received: from relay.tis.com by neptune.TIS.COM id aa23675; 20 Sep 95 22:00 EDT Received: from callandor.cybercash.com(204.178.186.70) by relay.tis.com via smap (g3.0.1) id xma020172; Wed, 20 Sep 95 21:46:06 -0400 Received: by callandor.cybercash.com; id VAA15057; Wed, 20 Sep 1995 21:51:49 -0400 Received: from cybercash.com(204.254.34.52) by callandor.cybercash.com via smap (g3.0.1) id xma015048; Wed, 20 Sep 95 21:51:27 -0400 Received: by cybercash.com.cybercash.com (4.1/SMI-4.1) id AA12101; Wed, 20 Sep 95 22:00:19 EDT Date: Wed, 20 Sep 1995 22:00:17 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: Alex Alten Cc: charlie_kaufman@iris.com, "Donald E. Eastlake" , dns-security@TIS.COM Subject: Re: comments on secure DNS spec In-Reply-To: <9509202243.AA03331@na.SJF.Novell.COM> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 20 Sep 1995, Alex Alten wrote: > Hello Charles and Donald, > I have some comments about the latest secure DNS draft dated Aug. 16. > Overall I think the paper is good. It does a clean job of fitting > a secure framework over the existing DNS infrastructure. > 1. On page 15 the MD5/RSA algorithm is specified as 1. I'd > recommend that MD5 not be explicitly specified. The algorithm > octet should only specify an (asymmetric) encryption algorithm. > > For example specify the following on page 21: > > hash = MD5 ( data ) > > signature ( 01 | FF* | 00 | prefix | implicit tag | hash ) ** e (mod n) > > Where 'implicit tag' = A0 10 for MD5 > A1 14 for SHA1 > > The first byte the hex 'A' means an ASN.1 Context specific Class i.e. > this document, Constructed constructor i.e. a non-atomic data type > (similer a C struct definition). The '0' or '1' are the tag numbers > for each hash type. The 2nd byte is simply the number of bytes that > will follow it. > > The ASN.1 grammar notation is as follows: > > HashMd5 ::= [0] IMPLICIT OCTET STRING (SIZE (16)) > HashSha ::= [1] IMPLICIT OCTET STRING (SIZE (20)) Your idea seems pretty simiple. I don't know why you clutter it up with all this ASN.1 cruft. In fact, your material above is yet another good example of how ASN.1 makes something very simple much harder to understand and a little more complex to implement. *If* we put this in, I would like just a one byte hash selector field. > The reason I recommend this is for two reasons: > > A. To allow other protocols to interoperate with this specification. > A proposed draft for secure SNMP uses this to specify MD5 and SHA1 > hashes. I would like to see secure Telnet and FTP adhere to this > as well. This is more a coordination issue among the major Internet > protocols, since they may be using secure DNS as a key management > server. SNMP long ago made the error of using ASN.1, something regretted by many of those involved. We don't need to duplicate that error. I think secure Telnet and FTP and the plethora of other point to point security protocols in the Internet should go away and be replaced by IPSEC. If the decision were up to me, I'd seriously consider an embargo on any "improvements" to these other point-to-point protocols to encourage development and deployment of IPSEC. (These comments do not apply to store-and-forward security such as DNS and email.) > B. To allow more than one hash to be used. If improved hashes > are designed or needed this allows a simple mechanism to > upgrade hashes without modifying the algorithm number. I don't see how this additional complexity of two numbers to specify the full algorithm makes things simpler. True, it allows easier combinations of different algorithms and hashes. But we are talking about the DNS here, a fundamental global naming system of the Internet, not just some point-to-point Telnet connections or something. If people switch to secure DNS in significant numbers, and some people wanted to add SHA as an alternative hash algorithm, I think it should take a standards action and, unless it is an emergency, a *lot* of advance notice. MD5 is the Internet standard for now. I'm included to leave things as they are and see how it goes. This change seems to invite the proliferation of non-interoperable options. It could always be added later. > 2. Why not use ElGamal instead of RSA for keys and signatures? > > This is a practical issue. Why not specify ElGamal instead of RSA? > the RSA patent has 5 more years before it expires. ElGamal is > unpatented and its underlying patent, Diffie-Hellman, expires in > 1.5 years. I believe ElGamal is just as strong as RSA and has > undergone over a decade of cryptanalysis. It is being used as the > foundation of the US Digital Signature Standard. Some of your points are good but RSA is the standard for use in the Internet now. Defining additional key types, such a ElGamal and Diffie-Hellman is reasonable for storage in the DNS but a variety of SIGs in DNS raises interoperability questions unless everyone implements every algorithm. > 3. Why not double encrypt the hash during DNS transactions? (pages 10, 22) > > This requires that a security aware resolver has a public/private key. > Basically the resolver generates a SIG by hashing its request, then > encrypting it with its own private key, and finally encrypting it > with the DNS server's public key. When the server responds it > encrypts its SIG hash with its own private key and then with the > resolver's public key. The resolver's public key does not have to > be stored on the DNS server, it could be sent as part of the > request (KEY). Doing this would reduce the possibility of an > intermediate gateway from replaying the response to multiple > resolvers. Also it prevents the resolver's request from getting > modified without detection. You are talking one hell of a lot of expensive public key operations at a busy DNS server for no gain that I can see. An intermediate gateway (like a caching server?) replaying the response to multiple servers sounds like a good thing if it's data that the servers want. If it's not, then it's not much different from other denial of service attacks. It would take a lot less work for many DNS servers to just answer a tampered with request rather than figure out its bad. And if the optional transaction security is in use, the requester knows if the query was tampered with anyway, if they can't tell from the data in the response. A fundamental WG assumption is that DNS queries and data are public. Why bother signing the query when you can tell if it got through by just checking the sig on the response if transaction security is being used? If you want a secure private pipe to your DNS server, use IPSEC. > 4. Why not securely encapsulate the DNS packet? (pages 10, 22) > > Why not fully encapsulate the DNS packet, by using an authentication > header and having the DNS packet as the data payload. This would > simplify authentication machinery. A nice side benefit is that > existing DNS servers could be retrofited without rewriting code. > You have to fool them into thinking they are receiving the old DNS > packet, when in fact the encapsulation machinery first receives, > then verifies the authentication header, then strips the header off > and finally passes the rest into the old DNS protocol machinery. > The old DNS parotocol machinery never has to be recompiled, relinked, > etc. The double encryption of the hash from #3 could be used here > as well. Now that IPSEC is a Proposed Standard, I think the last think people need is yet another point to point transport level security protocol. There is never a need to authenticate the source of an DNS request since a fundamental WG assumption is that DNS gives the same answer to everyone so it does not matter where a request came from. I don't see that it is of much use securing a DNS response unless it's to an insecure resolver from a secure DNS server. Just putting authentication on all or any large subset of the DNS point to point transmissions would have approximately no effect on DNS security. If might help for some small network if you maintained host access control lists and only ran DNS components on trusted machines, which seems pretty unrealistic and uninteresting to me. The transaction security optionally provided in dnssec seems to answer the need of a stub resolver for secure communications with a secure recursive resolver. It was an interim measure pending IPSEC and should be re-evaluated when IPSEC is significantly deployed. It may still be a saving since it secures two packets with one sig. > 4. Why not use a larger key footprint? (page 20) > > I noticed that you use a "key footprint" of 16 bits. Other protocols > that I seen typically use more bits. For example 64 bits (8 bytes). > Would this larger size make more sense since DNS is distributed > world-wide and there could eventually be millions of keys (assuming > it will also be a key management server). The key footprint is used only to help pick between and to provide a really trivial insecure first level validity check on the keys associated with a particular DNS name. I doubt there will be millions of keys assoicated with any single DNS name. > Sincerely, > > - Alex > > -- > > Alexander I. Alten > Alten@Na.Sjf.Novell.Com > (408) 577-8224 > > Novell, Inc. > Member of Technical Staff > Mail Stop F1-42-D2 > 2180 Fortune Drive > San Jose, CA 95131 > USA Donald ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)   Received: from relay.tis.com by neptune.TIS.COM id aa12897; 21 Sep 95 18:35 EDT Received: from ns.novell.com(137.65.1.1) by relay.tis.com via smap (g3.0.1) id xma005307; Thu, 21 Sep 95 18:20:38 -0400 Received: from na.SJF.Novell.COM ([130.57.6.3]) by ns.Novell.COM (4.1/SMI-4.1) id AA15904; Thu, 21 Sep 95 16:37:27 MDT Received: by na.SJF.Novell.COM (4.1/SMI-4.1) id AA09178; Thu, 21 Sep 95 15:35:34 PDT From: Alex Alten Message-Id: <9509212235.AA09178@na.SJF.Novell.COM> Subject: Re: comments on secure DNS spec To: "Donald E. Eastlake 3rd" Date: Thu, 21 Sep 1995 15:35:33 -0700 (PDT) Cc: alten@novell.com, charlie_kaufman@iris.com, dee@cybercash.com, dns-security@TIS.COM In-Reply-To: from "Donald E. Eastlake 3rd" at Sep 20, 95 10:00:17 pm X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 4417 Don, Thanks for replying so promptly. I agree with most of your answers. >> hash = MD5 ( data ) >> >> signature ( 01 | FF* | 00 | prefix | implicit tag | hash ) ** e (mod n) >> >> Where 'implicit tag' = A0 10 for MD5 >> A1 14 for SHA1 >> >> The first byte the hex 'A' means an ASN.1 Context specific Class i.e. >> this document, Constructed constructor i.e. a non-atomic data type >> (similer a C struct definition). The '0' or '1' are the tag numbers >> for each hash type. The 2nd byte is simply the number of bytes that >> will follow it. >> >> The ASN.1 grammar notation is as follows: >> >> HashMd5 ::= [0] IMPLICIT OCTET STRING (SIZE (16)) >> HashSha ::= [1] IMPLICIT OCTET STRING (SIZE (20)) > >Your idea seems pretty simiple. I don't know why you clutter it up >with all this ASN.1 cruft. In fact, your material above is yet >another good example of how ASN.1 makes something very simple much >harder to understand and a little more complex to implement. > >*If* we put this in, I would like just a one byte hash selector field. > Good point. I'm so used to ASN.1 from my work with SNMP that I usually don't think twice about it. Speaking of ASN.1 I noticed in your document that you do have an ASN.1 construct called the "prefix" (p 21). It is as follows: prefix = hex 3020300c06082a864886f70d020505000410 signature = ( 01 | FF* | 00 | prefix | hash ) ** e (mod n) Why are you bothering with this "cruft"? Why not just pad out the hash with random numbers? Or at least pseudo-random numbers if the secure DNS server can't generate true random numbers. Wouldn't this strengthen the resulting signature? When we decrypt the signature we already know that the hash is in the last 16 bytes of the buffer. Or if you use the hash selector byte then place it and the hash in the front and pad with random bytes to the end of the buffer. >I think secure Telnet and FTP and the plethora of other point to point >security protocols in the Internet should go away and be replaced by >IPSEC. If the decision were up to me, I'd seriously consider an >embargo on any "improvements" to these other point-to-point protocols >to encourage development and deployment of IPSEC. (These comments do >not apply to store-and-forward security such as DNS and email.) > I'm afraid that I must disagree with you about Telnet and FTP. These protocols depend on user authentication. IP level authentication is not enough to distinguish between users on a multi-user system. Some protocols like SNMP are also used over other non-Internet protocols, such as Appletalk and IPX. From an overall design perspective I doubt IPSEC will be able to adequately deal with the security needs of all higher level protocols. I'm finding out that each one has its individual needs which cannot always be covered by a "one size fits all" solution. >> 2. Why not use ElGamal instead of RSA for keys and signatures? >> >> This is a practical issue. Why not specify ElGamal instead of RSA? >> the RSA patent has 5 more years before it expires. ElGamal is >> unpatented and its underlying patent, Diffie-Hellman, expires in >> 1.5 years. I believe ElGamal is just as strong as RSA and has >> undergone over a decade of cryptanalysis. It is being used as the >> foundation of the US Digital Signature Standard. > >Some of your points are good but RSA is the standard for use in the >Internet now. Defining additional key types, such a ElGamal and >Diffie-Hellman is reasonable for storage in the DNS but a variety of >SIGs in DNS raises interoperability questions unless everyone >implements every algorithm. Unless I missed it, RSA has not been specified as a proposed standard RFC. RSA has a major drawback, its licensing costs. This is not a trivial point, many people will object to this. I'm asking you and the WG to seriously consider using ElGamal instead of RSA for signatures because we will avoid many years of licensing costs. I sincerely believe that this will enhance the acceptance of secure DNS in the Internet community by removing a financial constraint during the first half decade of its deployment. - Alex -- Alexander I. Alten Alten@Na.Sjf.Novell.Com (408) 577-8224 Novell, Inc. Member of Technical Staff Mail Stop F1-42-D2 2180 Fortune Drive San Jose, CA 95131 USA   Received: from relay.tis.com by neptune.TIS.COM id aa22506; 22 Sep 95 7:17 EDT Received: from ctrvx1.vanderbilt.edu(129.59.1.21) by relay.tis.com via smap (g3.0.1) id xma011300; Fri, 22 Sep 95 07:02:03 -0400 Received: from ctrvax.Vanderbilt.Edu by ctrvax.Vanderbilt.Edu (PMDF V5.0-5 #11488) id <01HVKB8537OG8WVYQ9@ctrvax.Vanderbilt.Edu> for listys@ctrvax.Vanderbilt.Edu; Fri, 22 Sep 1995 04:44:43 -0500 (CDT) Date: Fri, 22 Sep 1995 04:44:43 -0500 (CDT) From: BEZALEL GAVISH Subject: CFP 4th International Conference on Telecommunication Systems To: listys: ;, tis.com@ctrvax.vanderbilt.edu MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Message-id: <01HVKB853HBM8WVYQ9@ctrvax.Vanderbilt.Edu> X-VMS-To: IN%"listys" X-VMS-Cc: GAVISHB MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT TSMCFP96 Below you will find a copy of the call for papers for the 4th international conference on telecommunication systems which will be held March 21-24, 1996 in Nashville, TN. If you appear on multiple mailing lists or exploders, you might receive multiple copies of this message. I hope it does not cause you too much trouble, you have my apologies for it. ********************************************************************* C A L L for P A P E R S 4th International Conference on Telecommunication Systems Modelling and Analysis March 21-24, 1996 Nashville, TN Sponsored by: Bell South Telecommunications INFORMS Technical Section on Telecommunications INFORMS College of Information Systems Owen Graduate School of Management The 4th International Conference on Telecommunication Systems - Modelling and Analysis will be held in Nashville, Tennessee on March 21-24, 1996. The conference location will be the Bell South Tower in downtown Nashville. The conference will build on the tradition of the earlier conferences with a few changes in format due to the new conference location. The general idea is to limit the number of participants, concentrate on a few topics, present new problems and problem areas, encouraging informal interaction and exchanges of ideas. The objective is to advance the state of the modelling and analysis in telecommunications by stimulating research activity on new and important problems. The conference will be divided into segments with each segment devoted to a specific topic. This will allow for little conflict between segments. All papers will be screened by the program committee to ensure the quality of presentations. A decentralized paper handling process will be used, the Program Committee has been divided along geographical areas with a separate Program Subcommittee assigned to each area. Abstracts and papers should be submitted directly to Program Committee Chair of the appropriate area. It is expected that this will expedite the paper review process. In response to suggestions made by last year's participants, social and cultural activities will be included in the 1996 agenda. Lead Speakers and Keynote speakers include: Leonard Kleinrock, "Nomadic Computing and its Implications for Network Support" Alan Konheim, "A Monitor for Controlling Peak and Average ATM Input Traffic" Bezalel Gavish, "Low Earth Orbit Satellite Based Communication Systems - Research Issues" The Chairmen of the geographic Program Committees are: ---Australia, New Zealand and South East Asia: Prof. Richard Harris Department of Communication and Electronic Engineering Royal Melbourne Institute of Technology GPO Box 2476V Tel: 61 3660 2457 Melbourne, 3001 FAX: 61 3660 1060 Australia Email: richard@catt.citri.edu.au ---Europe: Prof. Guy Pujolle Laboratoire PRiSM Universite de Versailles - Saint-Quentin 45, avenue des Etats-Unis Tel: 33 1 39 25 40 61 78 035 Versailles Cedex FAX: 33 1 39 25 40 57 France Email: guy.pujolle@prism.uvsq.fr ---North America: Prof. Andre Girard INRS-Telecommunications 16, place du Commerce Tel: 514-765-7832 Verdun, Quebec FAX: 514-765-8785 Canada H3E 1H6 Email: andre@inrs-telecom.uquebec.ca ---North East Asia: Prof. Yutaka Takahashi Department of Applied Mathematics and Physics Faculty of Engineering Kyoto University Tel: 81 757535493 Yoshida-Honmachi, Sakyo-ku, Kyoto 606 FAX: Japan Email: yutaka@kuamp.kyoto-u.ac.jp ---South and Central America: Dr. Ernesto Santibanez-Gonzalez School of Industrial Engineering Catholic University of Valparaiso Tel: 56 32 257331 Av. Brasil 2147 FAX: 56 32 214823 Chile Email: esantiba@aix1.ucv.cl and Prof. Henrique Pacca L. Luna Department of Computer Science Federal University of Minas Gerais Tel: 31270-901 Belo Horizonte - MG FAX: Brazil Email: pacca@dcc.ufmg.br ---Chairman of the Economics track: Prof. Jeffrey Mackie-Mason Department of Economics Tel: 313-764-7438 University of Michigan FAX: 313-763-9181 Ann Arbor, MI 48109-1220 Email: jmm@umich.edu and Prof. William W. Sharkey ---All other geographic areas: Prof. Bezalel Gavish Owen Graduate School of Management Vanderbilt University Tel: 615-322-3659 401 21st Avenue South FAX: 615-343-7177 Nashville, TN 37203 Email: gavishb@ctrvax.vanderbilt.edu Listed below are some of the potential segments: -- Configuration of ATM networks -- Internet and its impact on commerce -- Topological Design and Network Configuration Problems -- Design and Analysis of Local Access Networks and Outside Plant Problems -- Low Earth Orbit Satellite communication systems -- Cellular Systems and PCS Modelling and Configuration -- Time Dependent Expansion of Telecommunication Systems -- Designing Networks for Reliability and Availability -- Network Design Problems in Gigabit and Terabit Networks -- LAN, WAN Global Network Interconnection -- ATM, ISDN, BISDN Modeling and Analysis Issues -- Artificial Intelligence/Heuristics in Telecommunication Systems -- Quantitative Methods in Network Management -- Pricing and Economic Analysis of Telecommunications -- Impact of Telecommunications on Industrial Organization -- Performance Evaluation of Telecommunication Systems -- Distributed Computing and Distributed Data Bases -- Security and Privacy issues in Telecommunications -- Virtual reality, Multimedia and their impact The Program Committee is open to any ideas you might have regarding additional topics or format of the conference. The intention is to limit the number of parallel sessions to two. The conference is scheduled over a weekend so as to reduce teaching conflicts for academic participants, take advantage of weekend hotel and airfare rates and of the many events that take place in the downtown area. Due to the limit on the number of participants early registration is recommended. To ensure your participation, please use the following steps: 1. Send to the appropriate Program Committee Chair by October 1, 1995, a paper (preferable), or titles and abstracts for potential presentations to be considered for the conference. Sending more than one abstract is encouraged, enabling the Program Committee to have a wider choice in terms of assigning talks to segments. Use E-mail to expedite the submission of titles and abstracts. 2. Use the form at the end of this message to preregister for the conference. Let us also know if you would like to have a formal duty during the conference as: Session Chair, or Discussant. 3. You will be notified by December 1, 1995, which abstract/s has been selected for the conference. Detailed instructions on how to prepare camera ready copies will be sent to authors of accepted presentations. January 30, 1996, is the deadline for sending a final version of the paper. Participants will receive copies of the collection of papers to be presented. All papers submitted to the conference will be considered for publication in the "Telecommunication Systems" Journal. The Program Committee looks forward to receiving your feedback/ideas. Feel free to volunteer any help you can offer. If you have suggestions for Segment Leaders (i.e., individuals who will have a longer time to give an overview/state of the art talk on their segment subject) please E-mail them to Prof Gavish. Also, if there are individuals whose participation you view as important, please send their names and E-mail addresses to the Program Committee Chairman, or forward to them a copy of this message. I look forward to a very successful conference. Sincerely yours, Bezalel Gavish ------------------------------------------------------------------------------- Cut Here ------------------------------------------------------------------------------- Fourth International Conference on Telecommunication Systems Modelling and Analysis REGISTRATION FORM Date: __________________ Location: Nashville, TN Dates: March 21, 1996 (afternoon) to March 24, 1996 Name: ________________________________________ Title: __________________ Affiliation: __________________________________________________________________ Address: __________________________________________________________________ __________________________________________________________________ Phone: ____________________________ FAX: _______________________________ E-mail: __________________________________________________________________ Potential Title of Paper(s): __________________________________________________ ____________________________________________________________________ I would like to Volunteer as Comments A Session Chair : Yes No ________________________________________________ A Discussant : Yes No ________________________________________________ Organize a Session: Yes No ________________________________________________ ________________________________________________ REGISTRATION RATES and DEADLINES Last Applicable Participant Type Date Academic Industry ---------------- -------- -------- 1. Preregistration Until Dec. 1, 1996 $ 350 $ 450 2. Registration Until Feb. 1, 1996 $ 400 $ 500 3. Registration After Feb. 1, 1996 $ 450 $ 650 Mail your registration form and check to: Mrs. Dru Lundeng Owen Graduate School of Management Vanderbilt University 401 21st Avenue, South Nashville, TN 37203, USA The check should be addressed to: 4th Int'l. Telecomm Systems Conference Refund Policy: Half refund, for requests received by February 1, 1996. No refund after February 1, 1996. If you have any questions regarding the conference, please contact Dru Lundeng at 615-322-3694 or through E-mail at lundeng@ctrvax.vanderbilt.edu. ------------------------------------------------------------------------------- Bezalel Gavish Owen Graduate School of Management Vanderbilt University Nashville, TN, 37203 Bitnet: GAVISHB@VUCTRVAX Internet: GAVISHB@CTRVAX.VANDERBILT.EDU Tel: (615) 322-3659 Home: (615) 370-0813 FAX: (615) 343-7177 -------------------------------------------------------------------------------   Received: from relay.tis.com by neptune.TIS.COM id aa24595; 22 Sep 95 9:14 EDT Received: from callandor.cybercash.com(204.178.186.70) by relay.tis.com via smap (g3.0.1) id xma012498; Fri, 22 Sep 95 08:58:58 -0400 Received: by callandor.cybercash.com; id JAA28410; Fri, 22 Sep 1995 09:05:25 -0400 Received: from cybercash.com(204.254.34.52) by callandor.cybercash.com via smap (g3.0.1) id xma028407; Fri, 22 Sep 95 09:05:07 -0400 Received: by cybercash.com.cybercash.com (4.1/SMI-4.1) id AA26602; Fri, 22 Sep 95 09:14:03 EDT Date: Fri, 22 Sep 1995 09:14:03 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: Alex Alten Cc: charlie_kaufman@iris.com, "Donald E. Eastlake" , dns-security@TIS.COM Subject: Re: comments on secure DNS spec In-Reply-To: <9509212235.AA09178@na.SJF.Novell.COM> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 21 Sep 1995, Alex Alten wrote: > Don, > > Thanks for replying so promptly. I agree with most of your answers. > > >> hash = MD5 ( data ) > >> > >> signature ( 01 | FF* | 00 | prefix | implicit tag | hash ) ** e (mod n) > >> > >> Where 'implicit tag' = A0 10 for MD5 > >> A1 14 for SHA1 > >> > >> The first byte the hex 'A' means an ASN.1 Context specific Class i.e. > >> this document, Constructed constructor i.e. a non-atomic data type > >> (similer a C struct definition). The '0' or '1' are the tag numbers > >> for each hash type. The 2nd byte is simply the number of bytes that > >> will follow it. > >> > >> The ASN.1 grammar notation is as follows: > >> > >> HashMd5 ::= [0] IMPLICIT OCTET STRING (SIZE (16)) > >> HashSha ::= [1] IMPLICIT OCTET STRING (SIZE (20)) > > > >Your idea seems pretty simiple. I don't know why you clutter it up > >with all this ASN.1 cruft. In fact, your material above is yet > >another good example of how ASN.1 makes something very simple much > >harder to understand and a little more complex to implement. > > > >*If* we put this in, I would like just a one byte hash selector field. > > Good point. I'm so used to ASN.1 from my work with SNMP that I usually > don't think twice about it. > > Speaking of ASN.1 I noticed in your document that you do have an ASN.1 > construct called the "prefix" (p 21). It is as follows: > > prefix = hex 3020300c06082a864886f70d020505000410 > > signature = ( 01 | FF* | 00 | prefix | hash ) ** e (mod n) > > Why are you bothering with this "cruft"? Why not just pad out the hash > with random numbers? Or at least pseudo-random numbers if the secure > DNS server can't generate true random numbers. Wouldn't this strengthen > the resulting signature? When we decrypt the signature we already know > that the hash is in the last 16 bytes of the buffer. Or if you use the > hash selector byte then place it and the hash in the front and pad with > random bytes to the end of the buffer. We are bothering with this silly cruft for exactly one reason: it is required to implement on top of RSAREF, the royalty free reference implementation that you have to use in the USA for non-commercial use to avoid either infringing or paying a license fee. We were requested to make this change by the IETF Security Area Head. As for the FF*, this is a signature, not encyption. Producing random numbers is an effort that buys you nothing in this case. You have the public key so you are supposed to be able to decyrpt the sig. It is a benefit, not a bug, if two sigs by the same authenticator over the same data to be authentiated are identical. The situation is entirely different if you are encyrpting in which case I agree fully that you need random padding. > >I think secure Telnet and FTP and the plethora of other point to point > >security protocols in the Internet should go away and be replaced by > >IPSEC. If the decision were up to me, I'd seriously consider an > >embargo on any "improvements" to these other point-to-point protocols > >to encourage development and deployment of IPSEC. (These comments do > >not apply to store-and-forward security such as DNS and email.) > > I'm afraid that I must disagree with you about Telnet and FTP. These > protocols depend on user authentication. IP level authentication is > not enough to distinguish between users on a multi-user system. Some > protocols like SNMP are also used over other non-Internet protocols, > such as Appletalk and IPX. From an overall design perspective I doubt > IPSEC will be able to adequately deal with the security needs of all > higher level protocols. I'm finding out that each one has its individual > needs which cannot always be covered by a "one size fits all" solution. This is not the place to discuss IPSEC, whose key management is not yet a standard, but you can bet it will provide user level authentication, multi-level secure level authentication, etc., as well as host/interface level authentication. I never claimed that IPSEC would answer all needs, just almost all point-to-point needs. > >> 2. Why not use ElGamal instead of RSA for keys and signatures? > >> > >> This is a practical issue. Why not specify ElGamal instead of RSA? > >> the RSA patent has 5 more years before it expires. ElGamal is > >> unpatented and its underlying patent, Diffie-Hellman, expires in > >> 1.5 years. I believe ElGamal is just as strong as RSA and has > >> undergone over a decade of cryptanalysis. It is being used as the > >> foundation of the US Digital Signature Standard. > > > >Some of your points are good but RSA is the standard for use in the > >Internet now. Defining additional key types, such a ElGamal and > >Diffie-Hellman is reasonable for storage in the DNS but a variety of > >SIGs in DNS raises interoperability questions unless everyone > >implements every algorithm. > > Unless I missed it, RSA has not been specified as a proposed standard RFC. > RSA has a major drawback, its licensing costs. This is not a trivial > point, many people will object to this. As far as I am aware, every Internet standard that specified a public key algorithm specifies RSA and none specify ElGamal. That's enough of a standard for me for this first pass at a standard for DNS security. ElGamal is not free of licensing costs as of this date. > I'm asking you and the WG to seriously consider using ElGamal instead of > RSA for signatures because we will avoid many years of licensing costs. I > sincerely believe that this will enhance the acceptance of secure DNS in > the Internet community by removing a financial constraint during the > first half decade of its deployment. > - Alex > -- > Alexander I. Alten > Alten@Na.Sjf.Novell.Com > (408) 577-8224 > > Novell, Inc. > Member of Technical Staff > Mail Stop F1-42-D2 > 2180 Fortune Drive > San Jose, CA 95131 > USA Donald ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)   Received: from relay.tis.com by neptune.TIS.COM id aa25035; 22 Sep 95 9:41 EDT Received: from itd.nrl.navy.mil(132.250.80.2) by relay.tis.com via smap (g3.0.1) id xma012854; Fri, 22 Sep 95 09:26:30 -0400 Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA20247; Fri, 22 Sep 95 09:42:25 EDT Date: Fri, 22 Sep 95 09:42:25 EDT From: Ran Atkinson Message-Id: <9509221342.AA20247@itd.nrl.navy.mil> To: alten@novell.com Subject: IP security Cc: dns-security@TIS.COM Don Eastlake wrote: >I think secure Telnet and FTP and the plethora of other point to point >security protocols in the Internet should go away and be replaced by >IPSEC. If the decision were up to me, I'd seriously consider an >embargo on any "improvements" to these other point-to-point protocols >to encourage development and deployment of IPSEC. (These comments do >not apply to store-and-forward security such as DNS and email.) Alex Alten responded: % I'm afraid that I must disagree with you about Telnet and FTP. % These protocols depend on user authentication. IP level % authentication is not enough to distinguish between users on a % multi-user system. The above comment tells me that you must not have read RFC-1825 thru RFC-1827 carefully enough. The IPsec Proposed Standards _require_ that implementations support user-oriented keying so that one _can_ distinguish between users on a multi-user system with cryptographic assurances. The NRL IPsec implementation does support keying on a per-socket basis NOW. (We have a BSD based implementation, so sockets are the appropriate term; one could do the same thing with TLI/XTI though the implementation details would differ). % Some protocols like SNMP are also used over other non-Internet protocols, % such as Appletalk and IPX. True, though at last report ALL security was being removed from SNMPv2 by the working group. Also, Don did not say that there were no applications needing application security, just that most applications did not need application layer security. % From an overall design perspective I doubt IPSEC will be able to % adequately deal with the security needs of all higher level protocols. % I'm finding out that each one has its individual needs which cannot % always be covered by a "one size fits all" solution. I agree with Don that IPsec can fully handle the security needs of MOST higher level protocols and that we probably ought not keep stuffing security into EVERY upper-layer protocol. DNS and PEM are good examples of higher level protocols that really need application layer security. Ran rja@cs.nrl.navy.mil [Followups probably belong on the IPsec list or in private email rather than on the DNS Security list...]   Received: from relay.tis.com by neptune.TIS.COM id aa06095; 22 Sep 95 20:05 EDT Received: from gw.home.vix.com(192.5.5.1) by relay.tis.com via smap (g3.0.1) id xma023883; Fri, 22 Sep 95 19:49:46 -0400 Received: by gw.home.vix.com id AA23694; Fri, 22 Sep 95 17:05:50 -0700 Date: Fri, 22 Sep 95 17:05:50 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: dns-security@TIS.COM From: Paul A Vixie Subject: Re: comments on secure DNS spec Organization: Vixie Enterprises Message-Id: References: <9509212235.AA09178@na.SJF.Novell.COM> Nntp-Posting-Host: wisdom.home.vix.com In-Reply-To: alten@novell.com's message of 21 Sep 1995 16:13:57 -0700 >>> This is a practical issue. Why not specify ElGamal instead of RSA? >>> the RSA patent has 5 more years before it expires. ElGamal is >>> unpatented and its underlying patent, Diffie-Hellman, expires in >>> 1.5 years. I believe ElGamal is just as strong as RSA and has >>> undergone over a decade of cryptanalysis. It is being used as the >>> foundation of the US Digital Signature Standard. >> >> Some of your points are good but RSA is the standard for use in the >> Internet now. Defining additional key types, such a ElGamal and >> Diffie-Hellman is reasonable for storage in the DNS but a variety of >> SIGs in DNS raises interoperability questions unless everyone >> implements every algorithm. > > Unless I missed it, RSA has not been specified as a proposed standard RFC. > RSA has a major drawback, its licensing costs. This is not a trivial > point, many people will object to this. Not just "object". DNSSEC cannot go to "recommended standard" until we have a signed license agreement from RSA in favour of ISOC. RFC 1601 or 1602 (my memory is lapsing) pretty much requires this. I recommend that you send mail to the IETF Security Area Director(s) explaining your concerns; perhaps they will let you (or all of us?) know the status of their work with RSA on this point. Note that I do not expect RSA to give away _everything_; they'll likely want licenses with vendors and individual users who _generate_ signatures, but to merely _verify_ one is something that we can't require users to pay for or DNSSEC will not catch on. > I'm asking you and the WG to seriously consider using ElGamal instead of > RSA for signatures because we will avoid many years of licensing costs. I > sincerely believe that this will enhance the acceptance of secure DNS in > the Internet community by removing a financial constraint during the > first half decade of its deployment. I strongly agree with this, but from my own efforts in this area I have learned that RSA is the 600-pound gorilla in this picture, it will sit anywhere it wants to. Your objection will no doubt be noted, along with mine. -- Paul Vixie La Honda, CA "Illegitimi non carborundum." pacbell!vixie!paul (dont let the bastards grind you down)   Received: from relay.tis.com by neptune.TIS.COM id aa07238; 22 Sep 95 21:59 EDT From: smb@research.att.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Message-Id: <199509230144.VAA24795@relay.tis.com> Received: from research.att.com(192.20.225.3) by relay.tis.com via smap (g3.0.1) id xma024793; Fri, 22 Sep 95 21:43:53 -0400 Received: by gryphon; Fri Sep 22 21:59:40 EDT 1995 To: Paul A Vixie cc: dns-security@TIS.COM Subject: Re: comments on secure DNS spec Date: Fri, 22 Sep 95 21:59:40 EDT I strongly agree with this, but from my own efforts in this area I have learned that RSA is the 600-pound gorilla in this picture, it will sit anywhere it wants to. Your objection will no doubt be noted, along with mine. Note that the world has changed. A few days ago, an arbitration panel *dissolved* PKP. The so-called Stanford patents, most notably Diffie- Hellman, reverted to Cylink; the others reverted to RSA. The press releases from RSA and Cylink are flat-out contradictory on what licenses one needs for which algorithms -- but there's no doubt that RSA is in a much weaker position than it was, since Bidzos no longer controls the Diffie-Hellman patent. Not, of course, that this necessarily makes our life any easier, just different...   Received: from relay.tis.com by neptune.TIS.COM id aa07354; 22 Sep 95 22:06 EDT Received: from oahu.cs.umass.edu(128.119.40.142) by relay.tis.com via smap (g3.0.1) id xma024883; Fri, 22 Sep 95 21:51:23 -0400 Received: (from ramesh@localhost) by oahu.cs.umass.edu (8.6.11/8.6.9) id WAA05189; Fri, 22 Sep 1995 22:08:57 -0400 Date: Fri, 22 Sep 1995 22:08:57 -0400 From: Ramesh Sitaraman Message-Id: <199509230208.WAA05189@oahu.cs.umass.edu> To: arpanet-bboard@mc.lcs.mit.edu, atm@bbn.com, cnom@meatro.bellcore.com, dbworld@cs.wisc.edu, dns-security@TIS.COM, end2end-interest@isi.edu, f-troup@aurora.cis.upenn.edu, globecom@signet.com.sig, hipparch@sophia.inria.fr, ietf-announce@cnri.reston.va.us, ipsec@ans.net, mobile-ip@tadpole.com, ost237-transport@comp.lancs.ac.uk, rdd@cc.bellcore.com, rem-conf-request@es.net, rem-conf@es.net, reres@laas.fr, sigmedia@bellcore.com, www-security@ns2.rutgers.edu, xtp-relay@cs.concordia.ca Subject: CFP: Special Issue of Wireless Networks; Deadline Oct 1st. ******************************************************************* ***********************CALL FOR PAPERS***************************** ******************************************************************* The ACM journal on WIRELESS NETWORKS, published in cooperation with Baltzer Science publishers announces a special issue on, MOBILITY MANAGEMENT IN WIRELESS NETWORKS with guest editors, Prof. Christopher Rose Prof. Ramesh Sitaraman Director of Mobility Studies Department of Computer Science Rutgers University, WINLAB University of Massachusetts, Amherst OVERVIEW: Our highly mobile society and its increasing demand for immediate access to knowledge will require that future information networks gracefully accommodate mobility of both users and services. For example, a particular user might wish to gain network access through any number of different ports or connection media. Likewise, a network service might reside on one of many possible processors. Under such a scenario, where both users and network services change location, the distinction between the ``fixed'' and ``mobile'' network blurs; all networks are mobile networks. The overall costs of maintaining accurate location records are at present only poorly understood. However, recent work indicates that simply for telephone traffic, the excess network signaling load expense would be much larger than that required for classical fixed traffic. If migrant services and databases are included, the aggregate signaling load can only be greater. In addition, for wireless systems, the relevant signaling events require use of radio channels and such use must be minimized owing to the scarcity of bandwidth. Thus, either from the standpoint of modifying existing fixed network signaling structures or designing wireless network paging/registration strategies, it is important to understand, quantify and devise methods for handling the impact of location uncertainty on signaling. SCOPE: This special issue will concentrate on the problems associated with acquiring and maintaining mobile unit location information in the wireless environment. A representative sampling of topics is provided below: - Mobility modeling - Location prediction - Empirical measurements for user profiles - Location tracking and mobile network topology - Location tracking for handoff - Paging/Registration cost minimization - Multi-unit paging techniques - Performance Analysis of location management strategies PUBLICATION SCHEDULE: MANUSCRIPT DUE: October 1, 1995 ACCEPTANCE NOTIFICATION: January 1, 1996 FINAL MANUSCRIPT DUE: March 1 1996 Publication Date: Summer 1996. SUBMISSION GUIDELINES: Authors should email an electronic Postscript copy of their paper to winet_mobility@cs.umass.edu by October 1, 1995. The editors will acknowledge the receipt of the paper within a few days. Submissions should be limited to 20 pages, excluding figures and references. If email submission is inconvenient, then six (6) copies of their paper (double-sided if possible) should be sent by the due date to Christopher Rose P.O. Box 909 Piscataway, N.J. 08855-0909 VOICE: (908) 445-5250 FAX: (908) 445-2820 EMAIL: winet_mobility@cs.umass.edu We look forward to your participation in providing a stimulating special issue on an important topic.   Received: from relay.tis.com by neptune.TIS.COM id aa12420; 25 Sep 95 12:14 EDT Received: from callandor.cybercash.com(204.178.186.70) by relay.tis.com via smap (g3.0.1) id xma013527; Mon, 25 Sep 95 11:57:45 -0400 Received: by callandor.cybercash.com; id MAA24472; Mon, 25 Sep 1995 12:05:05 -0400 Received: from cybercash.com(204.254.34.52) by callandor.cybercash.com via smap (g3.0.1) id xma024467; Mon, 25 Sep 95 12:04:41 -0400 Received: by cybercash.com.cybercash.com (4.1/SMI-4.1) id AA22387; Mon, 25 Sep 95 12:13:46 EDT Date: Mon, 25 Sep 1995 12:13:45 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: Paul A Vixie Cc: dns-security@TIS.COM Subject: Re: comments on secure DNS spec In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Humm...., I suppose if PKP is really disolved then the RFC from them which guarantees reasonable and non-discriminatory licensing is no longer in effect and no IETF standards using RSA can proceed until new assurances are in place. In this regard, RSA and ElGamal are in the same boat right now. Donald On Fri, 22 Sep 1995, Paul A Vixie wrote: > >>> This is a practical issue. Why not specify ElGamal instead of RSA? > >>> the RSA patent has 5 more years before it expires. ElGamal is > >>> unpatented and its underlying patent, Diffie-Hellman, expires in > >>> 1.5 years. I believe ElGamal is just as strong as RSA and has > >>> undergone over a decade of cryptanalysis. It is being used as the > >>> foundation of the US Digital Signature Standard. > >> > >> Some of your points are good but RSA is the standard for use in the > >> Internet now. Defining additional key types, such a ElGamal and > >> Diffie-Hellman is reasonable for storage in the DNS but a variety of > >> SIGs in DNS raises interoperability questions unless everyone > >> implements every algorithm. > > > > Unless I missed it, RSA has not been specified as a proposed standard RFC. > > RSA has a major drawback, its licensing costs. This is not a trivial > > point, many people will object to this. > > Not just "object". DNSSEC cannot go to "recommended standard" until we > have a signed license agreement from RSA in favour of ISOC. RFC 1601 or > 1602 (my memory is lapsing) pretty much requires this. I recommend that > you send mail to the IETF Security Area Director(s) explaining your > concerns; perhaps they will let you (or all of us?) know the status of > their work with RSA on this point. Doesn't need any actual license. Just a guarantee that licenses will be available on a reasonable and non-discriminatory basis. > Note that I do not expect RSA to give away _everything_; they'll likely > want licenses with vendors and individual users who _generate_ signatures, > but to merely _verify_ one is something that we can't require users to > pay for or DNSSEC will not catch on. > > > I'm asking you and the WG to seriously consider using ElGamal instead of > > RSA for signatures because we will avoid many years of licensing costs. I > > sincerely believe that this will enhance the acceptance of secure DNS in > > the Internet community by removing a financial constraint during the > > first half decade of its deployment. > > I strongly agree with this, but from my own efforts in this area I have > learned that RSA is the 600-pound gorilla in this picture, it will sit > anywhere it wants to. Your objection will no doubt be noted, along with > mine. > -- > Paul Vixie > La Honda, CA "Illegitimi non carborundum." > > pacbell!vixie!paul (dont let the bastards grind you down) Donald ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)   Received: from relay.tis.com by neptune.TIS.COM id aa13356; 25 Sep 95 13:17 EDT Received: from south-station-annex.mit.edu(18.72.1.2) by relay.tis.com via smap (g3.0.1) id xma014455; Mon, 25 Sep 95 13:01:15 -0400 Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA19481; Mon, 25 Sep 95 13:17:44 EDT Received: by dcl.MIT.EDU (5.0/4.7) id AA07610; Mon, 25 Sep 1995 13:18:07 -0400 Date: Mon, 25 Sep 1995 13:18:07 -0400 From: Theodore Ts'o Message-Id: <9509251718.AA07610@dcl.MIT.EDU> To: "Donald E. Eastlake 3rd" Cc: Paul A Vixie , dns-security@TIS.COM In-Reply-To: Donald E. Eastlake 3rd's message of Mon, 25 Sep 1995 12:13:45 -0400 (EDT), Subject: Re: comments on secure DNS spec Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 909 Date: Mon, 25 Sep 1995 12:13:45 -0400 (EDT) From: "Donald E. Eastlake 3rd" I suppose if PKP is really disolved then the RFC from them which guarantees reasonable and non-discriminatory licensing is no longer in effect and no IETF standards using RSA can proceed until new assurances are in place. In this regard, RSA and ElGamal are in the same boat right now. In the RSAREF license, RSADSI indemnified the users of the RSAREF license against "any claim, suit or proceeding against you on the basis of infringement of any United States patent in the field of cryptography by the unmodified Program". Hence, users of RSAREF have nothing to fear, since RSADSI has promised to defend (or at its option settle) any patent claims brought against those users from Cylink. Another Good Reason for making the dns-sec patent formats compatible with RSAREF. - Ted   Received: from relay.tis.com by neptune.TIS.COM id aa25281; 26 Sep 95 1:54 EDT Received: from servo.qualcomm.com(129.46.128.14) by relay.tis.com via smap (g3.0.1) id xma023910; Tue, 26 Sep 95 01:38:46 -0400 Received: (karn@localhost) by servo.qualcomm.com (8.6.12/QC-BSD-2.5.1) id WAA18552; Mon, 25 Sep 1995 22:53:01 -0700 Date: Mon, 25 Sep 1995 22:53:01 -0700 From: Phil Karn Message-Id: <199509260553.WAA18552@servo.qualcomm.com> To: dee@cybercash.com CC: alten@novell.com, charlie_kaufman@iris.com, dee@cybercash.com, dns-security@TIS.COM In-reply-to: (dee@cybercash.com) Subject: Re: comments on secure DNS spec >It is a >benefit, not a bug, if two sigs by the same authenticator over the >same data to be authentiated are identical. Is this true? I thought the consensus among the cryptographers was that you should never sign something unless you control part of the message to be signed. Phil   Received: from relay.tis.com by neptune.TIS.COM id aa25512; 26 Sep 95 2:14 EDT Received: from sonicsys.sonicsys.stph.net(196.12.54.2) by relay.tis.com via smap (g3.0.1) id xma024038; Tue, 26 Sep 95 01:58:03 -0400 Received: from [196.12.54.11] (vasu.sonicsys.stph.net [196.12.54.11]) by sonicsys.sonicsys.stph.net (8.6.9/8.6.9) with SMTP id MAA00655 for ; Tue, 26 Sep 1995 12:01:38 +0500 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 26 Sep 1995 12:02:56 +0000 To: dns-security@TIS.COM From: VASUDEV Subject: un subscribe un subscribe E-MAIL:   Received: from relay.tis.com by neptune.TIS.COM id aa03355; 26 Sep 95 11:03 EDT Received: from callandor.cybercash.com(204.178.186.70) by relay.tis.com via smap (g3.0.1) id xma029301; Tue, 26 Sep 95 10:47:49 -0400 Received: by callandor.cybercash.com; id KAA06253; Tue, 26 Sep 1995 10:55:10 -0400 Received: from cybercash.com(204.254.34.52) by callandor.cybercash.com via smap (g3.0.1) id xma006246; Tue, 26 Sep 95 10:54:47 -0400 Received: by cybercash.com.cybercash.com (4.1/SMI-4.1) id AA02872; Tue, 26 Sep 95 11:03:54 EDT Date: Tue, 26 Sep 1995 11:03:54 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: Phil Karn Cc: alten@novell.com, dns-security@TIS.COM Subject: Re: comments on secure DNS spec In-Reply-To: <199509260553.WAA18552@servo.qualcomm.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Well, you never want to sign something, especially with RSA, that someone else gives you because they might be secretly getting you to decrypt something or the like. But signing a hash of what they give you should be fine. If they can control what you are signing then, it means they can invert the hash function in which case you are sunk anyway and your signatures provide no security. Donald On Mon, 25 Sep 1995, Phil Karn wrote: > >It is a > >benefit, not a bug, if two sigs by the same authenticator over the > >same data to be authentiated are identical. > > Is this true? I thought the consensus among the cryptographers was > that you should never sign something unless you control part of the > message to be signed. > > Phil > ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)   Received: from relay.tis.com by neptune.TIS.COM id aa05356; 26 Sep 95 12:57 EDT Received: from newton.ncsa.uiuc.edu(141.142.2.2) by relay.tis.com via smap (g3.0.1) id xma001555; Tue, 26 Sep 95 12:40:31 -0400 Received: from [141.142.150.60] (aslan.ncsa.uiuc.edu [141.142.150.60]) by newton.ncsa.uiuc.edu (8.6.11/8.6.12) with SMTP id LAA23891; Tue, 26 Sep 1995 11:55:59 -0500 X-Sender: kerowe@newton Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 26 Sep 1995 11:55:23 -0800 To: "Donald E. Eastlake 3rd" From: "Kenneth E. Rowe" Subject: Re: comments on secure DNS spec Cc: Phil Karn , alten@novell.com, dns-security@TIS.COM At 11:03 AM 9/26/95, Donald E. Eastlake 3rd wrote: >Well, you never want to sign something, especially with RSA, that >someone else gives you because they might be secretly getting you to >decrypt something or the like. But signing a hash of what they give >you should be fine. If they can control what you are signing then, it >means they can invert the hash function in which case you are sunk >anyway and your signatures provide no security. > The first problem is an argument for using SHA/DSA instead of RSA. I don't understand the concern with the hash function. Is it invertable?! Can you be a little more descriptive than "sunk"? Ken, ------------------------------------------------------------- Kenneth E. Rowe (kerowe@ncsa.uiuc.edu) Senior Security Engineer (217) 244-5270 (Office) / Security Coordinator (217) 244-0710 (NCSA IRST) National Center for Supercomputing Applications *** email ncsa-irst@ncsa.uiuc.edu for computer incident response ***   Received: from relay.tis.com by neptune.TIS.COM id aa09105; 26 Sep 95 16:17 EDT Received: from callandor.cybercash.com(204.178.186.70) by relay.tis.com via smap (g3.0.1) id xma005175; Tue, 26 Sep 95 16:01:34 -0400 Received: by callandor.cybercash.com; id QAA10010; Tue, 26 Sep 1995 16:05:14 -0400 Received: from cybercash.com(204.254.34.52) by callandor.cybercash.com via smap (g3.0.1) id xma010007; Tue, 26 Sep 95 16:04:49 -0400 Received: by cybercash.com.cybercash.com (4.1/SMI-4.1) id AA05930; Tue, 26 Sep 95 16:13:56 EDT Date: Tue, 26 Sep 1995 16:13:56 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: "Kenneth E. Rowe" Cc: Phil Karn , alten@novell.com, dns-security@TIS.COM Subject: Re: comments on secure DNS spec In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 26 Sep 1995, Kenneth E. Rowe wrote: > At 11:03 AM 9/26/95, Donald E. Eastlake 3rd wrote: > >Well, you never want to sign something, especially with RSA, that > >someone else gives you because they might be secretly getting you to > >decrypt something or the like. But signing a hash of what they give > >you should be fine. If they can control what you are signing then, it > >means they can invert the hash function in which case you are sunk > >anyway and your signatures provide no security. > > The first problem is an argument for using SHA/DSA instead of RSA. The point about RSA is the signing is encrypting under the private key which is decrypting under the public key. Yes, this is an argument for other signature algorithms, but not a very stong one if you use proper procedures. > I don't understand the concern with the hash function. Is it invertable?! > Can you be a little more descriptive than "sunk"? If someone can invert a hash function and easily come up with things that hash to a particular hash value, they can probably find something that you wouldn't sign with the same hash as what you did sign so they can forge messages your signature will appear to sign. That's what I meant by sunk. There is no particular reason to think MD5 is weak in this regard. > Ken, > ------------------------------------------------------------- > Kenneth E. Rowe (kerowe@ncsa.uiuc.edu) > Senior Security Engineer (217) 244-5270 (Office) > / Security Coordinator (217) 244-0710 (NCSA IRST) > National Center for Supercomputing Applications > *** email ncsa-irst@ncsa.uiuc.edu for computer incident response *** Donald ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)   Received: from relay.tis.com by neptune.TIS.COM id aa10624; 26 Sep 95 17:29 EDT Received: from ns.novell.com(137.65.1.1) by relay.tis.com via smap (g3.0.1) id xma006862; Tue, 26 Sep 95 17:12:51 -0400 Received: from na.SJF.Novell.COM ([130.57.6.3]) by ns.Novell.COM (4.1/SMI-4.1) id AA22106; Tue, 26 Sep 95 15:29:46 MDT Received: by na.SJF.Novell.COM (4.1/SMI-4.1) id AA11965; Tue, 26 Sep 95 14:24:58 PDT From: Alex Alten Message-Id: <9509262124.AA11965@na.SJF.Novell.COM> Subject: Re: comments on secure DNS spec To: "Donald E. Eastlake 3rd" Date: Tue, 26 Sep 1995 14:24:57 -0700 (PDT) Cc: paul@vix.com, dns-security@TIS.COM In-Reply-To: from "Donald E. Eastlake 3rd" at Sep 25, 95 12:13:45 pm X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 4390 After thinking about this for a while, I've come to the conclusion that the Internet community needs to settle on a public key standard. The situation right now is untenable, defacto standards like PGP are implemented with homegrown RSA, RFC1824 (TESS) specifies ElGamal, many drafts are specifing RSAREF. Managing and distributing keys among all these protocols will be difficult, if not impossible. We need to issue a RFC that secure DNS, secure SNMP, and others can reference. Certainly RSA is a fine algorithm, albeit expensive over the next 5 years. We need to seriously consider other algorithms, such as ElGamal, for the standard. I think the choice should be one that has withstood years of cryptanalysis, it is reasonable to implement and use, and it will be unencumbered with patents, etc., as soon as possible. At this point in time I tend to favor ElGamal as having the best mix of these properties, it will be unencumbered in 1.5 years. - Alex > > Humm...., > > I suppose if PKP is really disolved then the RFC from them which > guarantees reasonable and non-discriminatory licensing is no longer > in effect and no IETF standards using RSA can proceed until new > assurances are in place. In this regard, RSA and ElGamal are in > the same boat right now. > > Donald > > On Fri, 22 Sep 1995, Paul A Vixie wrote: > > > >>> This is a practical issue. Why not specify ElGamal instead of RSA? > > >>> the RSA patent has 5 more years before it expires. ElGamal is > > >>> unpatented and its underlying patent, Diffie-Hellman, expires in > > >>> 1.5 years. I believe ElGamal is just as strong as RSA and has > > >>> undergone over a decade of cryptanalysis. It is being used as the > > >>> foundation of the US Digital Signature Standard. > > >> > > >> Some of your points are good but RSA is the standard for use in the > > >> Internet now. Defining additional key types, such a ElGamal and > > >> Diffie-Hellman is reasonable for storage in the DNS but a variety of > > >> SIGs in DNS raises interoperability questions unless everyone > > >> implements every algorithm. > > > > > > Unless I missed it, RSA has not been specified as a proposed standard RFC. > > > RSA has a major drawback, its licensing costs. This is not a trivial > > > point, many people will object to this. > > > > Not just "object". DNSSEC cannot go to "recommended standard" until we > > have a signed license agreement from RSA in favour of ISOC. RFC 1601 or > > 1602 (my memory is lapsing) pretty much requires this. I recommend that > > you send mail to the IETF Security Area Director(s) explaining your > > concerns; perhaps they will let you (or all of us?) know the status of > > their work with RSA on this point. > > Doesn't need any actual license. Just a guarantee that licenses will be > available on a reasonable and non-discriminatory basis. > > > Note that I do not expect RSA to give away _everything_; they'll likely > > want licenses with vendors and individual users who _generate_ signatures, > > but to merely _verify_ one is something that we can't require users to > > pay for or DNSSEC will not catch on. > > > > > I'm asking you and the WG to seriously consider using ElGamal instead of > > > RSA for signatures because we will avoid many years of licensing costs. I > > > sincerely believe that this will enhance the acceptance of secure DNS in > > > the Internet community by removing a financial constraint during the > > > first half decade of its deployment. > > > > I strongly agree with this, but from my own efforts in this area I have > > learned that RSA is the 600-pound gorilla in this picture, it will sit > > anywhere it wants to. Your objection will no doubt be noted, along with > > mine. > > -- > > Paul Vixie > > La Honda, CA "Illegitimi non carborundum." > > > > pacbell!vixie!paul (dont let the bastards grind you down) > > Donald > ===================================================================== > Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com > 318 Acton Street +1 508-371-7148(fax) dee@world.std.com > Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) > > -- Alexander I. Alten Alten@Na.Sjf.Novell.Com (408) 577-8224 Novell, Inc. Member of Technical Staff Mail Stop F1-42-D2 2180 Fortune Drive San Jose, CA 95131 USA   Received: from relay.tis.com by neptune.TIS.COM id aa14714; 26 Sep 95 22:27 EDT Received: from ns.novell.com(137.65.1.1) by relay.tis.com via smap (g3.0.1) id xma010060; Tue, 26 Sep 95 22:02:00 -0400 Received: from na.SJF.Novell.COM ([130.57.6.3]) by ns.Novell.COM (4.1/SMI-4.1) id AA23612; Tue, 26 Sep 95 20:18:55 MDT Received: by na.SJF.Novell.COM (4.1/SMI-4.1) id AA14608; Tue, 26 Sep 95 19:14:01 PDT From: Alex Alten Message-Id: <9509270214.AA14608@na.SJF.Novell.COM> Subject: Re: IP security To: Ran Atkinson Date: Tue, 26 Sep 1995 19:14:00 -0700 (PDT) Cc: alten@novell.com, dns-security@TIS.COM In-Reply-To: <9509221342.AA20247@itd.nrl.navy.mil> from "Ran Atkinson" at Sep 22, 95 09:42:25 am X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 5406 > > > Don Eastlake wrote: > >I think secure Telnet and FTP and the plethora of other point to point > >security protocols in the Internet should go away and be replaced by > >IPSEC. If the decision were up to me, I'd seriously consider an > >embargo on any "improvements" to these other point-to-point protocols > >to encourage development and deployment of IPSEC. (These comments do > >not apply to store-and-forward security such as DNS and email.) > > Alex Alten responded: > % I'm afraid that I must disagree with you about Telnet and FTP. > % These protocols depend on user authentication. IP level > % authentication is not enough to distinguish between users on a > % multi-user system. > > The above comment tells me that you must not have read RFC-1825 thru > RFC-1827 carefully enough. The IPsec Proposed Standards _require_ > that implementations support user-oriented keying so that one _can_ > distinguish between users on a multi-user system with cryptographic > assurances. The NRL IPsec implementation does support keying on a > per-socket basis NOW. (We have a BSD based implementation, so sockets > are the appropriate term; one could do the same thing with TLI/XTI > though the implementation details would differ). > I read 1825 and 1826. While these documents do comment on supporting user authentication, it is not clear to me how this information is actually percolated between IP, UDP/TCP, and the application protocols. IP can certainly communicate authentication information with UDP and TCP but without redesigning those protocols how does the information get to the application layer? For example how could FTP command and data sessions insert user authentication info into the IPSEC AH header? How does the IP layer coordinate with the FTP layer to verify an incoming packet? It seems this all becomes rather difficult unless you are willing to break the modularity of each layer. The NRL implementation must be reaching around the UDP and TCP headers in order to insert the user keys into the IPSEC AH header. If I have two FTP users establishing command sessions with a distant FTP server, how does that server's IP stack know which key belongs to which incoming packet? It would have to look into the TCP header to find out what is going on and then somehow look up the correct key associated with that incoming port number and IP address. What if an FTP client disconnects and then reconnects with a new command session source port number? Key management based on IP and port number (a socket) will be a challenge. Interoperability at the socket level between various vendors will be even more of a challenge. I believe that IP security should only concern itself with the IP layer e.g. authenticating IP addresses, etc. Nothing more, nothing less. > % Some protocols like SNMP are also used over other non-Internet protocols, > % such as Appletalk and IPX. > > True, though at last report ALL security was being removed from SNMPv2 > by the working group. Also, Don did not say that there were no > applications needing application security, just that most applications > did not need application layer security. > This is correct, I was one of those who recommended that it be dropped from the current round. We hope to continue with an effort focused only on security. > % From an overall design perspective I doubt IPSEC will be able to > % adequately deal with the security needs of all higher level protocols. > % I'm finding out that each one has its individual needs which cannot > % always be covered by a "one size fits all" solution. > > I agree with Don that IPsec can fully handle the security needs of MOST > higher level protocols and that we probably ought not keep stuffing > security into EVERY upper-layer protocol. DNS and PEM are good examples > of higher level protocols that really need application layer security. > I disagree with this statement for the following reasons: 1. If IPSEC fails to be accepted by the Internet community, then there is no alternative mechanism (except SSL?). An example of this is the failure of the old SNMP security design. I think it is important for application protocols to develop their own security mechanisms. 2. For the forseeable future IPSEC will not be uniformly deployed throughout the world. Thus one cannot be assured that data can be sent securely anywhere using only IPSEC. A company may be able to ensure that its employees can use a secure application level protocol since it can control it's host machines. But it may not be able to control intermediate gateways to guarentee end-to-end IP security. 3. An IP stack may not be under user control, therefore there is no assurance that user data is always safe. Security will depend on the trustworthiness of an administrator of the stack. Or the transport stack could be poorly implemented, allowing others to crack or retrieve keys (like the recent snafu with Netscape). > Ran > rja@cs.nrl.navy.mil > > [Followups probably belong on the IPsec list or in private email > rather than on the DNS Security list...] Please tell me how to register with the IPsec list. - Alex -- Alexander I. Alten Alten@Na.Sjf.Novell.Com (408) 577-8224 Novell, Inc. Member of Technical Staff Mail Stop F1-42-D2 2180 Fortune Drive San Jose, CA 95131 USA   Received: from relay.tis.com by neptune.TIS.COM id aa15109; 26 Sep 95 23:03 EDT Received: from optima.cs.arizona.edu(192.12.69.5) by relay.tis.com via smap (g3.0.1) id xma010456; Tue, 26 Sep 95 22:47:15 -0400 Received: from uncial.CS.Arizona.EDU by optima.cs.arizona.edu (5.65c/15) via SMTP id AA05404; Tue, 26 Sep 1995 20:04:21 MST Received: by uncial.CS.Arizona.EDU; (5.65/1.1.8.2/08Nov94-0446PM) id AA02359; Tue, 26 Sep 1995 20:04:19 -0700 Date: Tue, 26 Sep 1995 20:04:19 -0700 From: Hilarie Orman Message-Id: <9509270304.AA02359@uncial.CS.Arizona.EDU> To: alten@novell.com Cc: dns-security@TIS.COM, ipsec@ans.net In-Reply-To: Yourmessage <9509270214.AA14608@na.SJF.Novell.COM> Subject: Re: IP security The RFCs in question address IP message protection and authentication, not much more nor less, just as one would wish. Can there exist an interface to higher levels that provide authentication at the granularity of a "user" (whatever such an entity may be)? It appears so to several people, and the binding between security association identifiers and users is the central to the feasibility. The mechanism of that binding and the interface to it hasn't been defined in detail yet. So we have a network level mechanism with the informal claim that it covers almost all transport level uses, given an appropriate interface definition. One important use that the RFC's don't define is a way of providing message protection at a granularity smaller than one IP message. If this is crucial to one's need for security, then another mechanism will be required. Multipart secure messages seem like a useful thing for many applications, of course. So I think there is a legitimate argument that is brewing where the application layer security people clash with the ESP people on which territory is more rightfully theirs.   Received: from relay.tis.com by neptune.TIS.COM id aa22591; 28 Sep 95 14:43 EDT Received: from watson.ibm.com(129.34.139.4) by relay.tis.com via smap (g3.0.1) id xma005651; Thu, 28 Sep 95 14:27:12 -0400 Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 7213; Thu, 28 Sep 95 14:44:04 EDT Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.02 on VAGENT2" id 5371; Thu, 28 Sep 1995 14:44:04 EDT Received: from gimili.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2Rx) with TCP; Thu, 28 Sep 95 14:44:03 EDT Received: by gimili.watson.ibm.com (AIX 3.2/UCB 5.64/950830) id AA33730; Thu, 28 Sep 1995 14:43:42 -0400 Date: Thu, 28 Sep 1995 14:43:42 -0400 From: "S.Kutten" Message-Id: <9509281843.AA33730@gimili.watson.ibm.com> To: dns-security@TIS.COM Subject: call for papers Call for Papers For the new journal published in cooperation with the ACM: WIRELESS NETWORKS Special Issue: Mobility and Security Scope: Mobility introduces a new dimension to the problem of secure computing and communication. The securing becomes harder and often more important. This is sometimes due to the mobility of the communication devices, sometimes due to the mobility of users (without mobile device), or the mobility of objects, or that of the attackers. Papers are sought that address the requirements, designs, algorithms and implementation experience for securing networks, distributed systems, information, and applications in environments that can support mobility. Possible topics include, but are not limited to: Securing communication and distributed systems, such as: - Internet (TCP/IP, mobile IP, DNS, DHCP) - ATM - CDPD - GSM - SNA - Wireless LAN Cryptographic protocols, such as: - key distribution - authentication - payments - anonymity and privacy Cryptographic functions, such as: - encryption - message authentication - message digest - signatures Computer viruses and worms Security for intelligent and mobile objects and agents Secure electronic commerce Cryptographic hardware Security and cryptography for wireless communication systems. The authors should send 6 copies of their paper to one of the guest editors by November 15, 1995. The following time-table shall be followed: Manuscript Submission Deadline: November 15, 1995 Acceptance Notification: May 15, 1996 Final Manuscript Submission Deadline: July 15, 1996 Expected Publication Date: Last Quarter 1996 E-mail submissions are encouraged (post-script only). Set subject to `Submission to WINET special issue'. Guest Editors: Amir Herzberg IBM T.J. Watson Research Center P.O. Box 704 #H3-D18 Yorktown Heights, NY 10598 Telephone: (914) 784-6981 Facsimile: (914) 784-6205 Internet: amir@watson.ibm.com Shay Kutten IBM T.J. Watson Research Center P.O. Box 704 #H3-D38 Yorktown Heights, NY 10598 Telephone: (914) 784-7346 Facsimile: (914) 784-6205 Internet: kutten@watson.ibm.com