Received: from sol.tis.com by magellan.TIS.COM id aa07227; 14 Apr 94 11:45 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA10318; Thu, 14 Apr 94 11:45:21 EDT Received: by relay.tis.com; id AA14440; Thu, 14 Apr 94 11:46:16 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma014430; Thu Apr 14 11:46:06 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 15 Apr 94 00:40:07 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404141540.AA10587@necom830.cc.titech.ac.jp> Subject: Re: Security AD's assesment re RSAREF licensing To: Paul A Vixie Date: Fri, 15 Apr 94 0:40:05 JST Cc: pvm@isi.edu, kent@bbn.com, dns-security@tis.com In-Reply-To: <9404140512.AA27384@gw.home.vix.com>; from "Paul A Vixie" at Apr 13, 94 10:12 pm X-Mailer: ELM [version 2.3 PL11] > i agree that DNS responses (and perhaps queries) are growing and will need > more room. this isn't going to be a backward compatible change, though, and > once we're paying the rip-everything-apart-and-put-in-new-software penalty, > i think we should use the oppty to examine some other issues that have come > up in the last few years. I think we should start making name servers and resolvers can accept (but not send) 64K byte UDP packets, immediately. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa10502; 15 Apr 94 1:40 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA22681; Fri, 15 Apr 94 01:39:49 EDT Received: by relay.tis.com; id AA21981; Fri, 15 Apr 94 01:40:45 EDT Received: from gw.home.vix.com(192.5.5.1) by relay via smap (V1.3mjr) id sma021976; Fri Apr 15 01:40:14 1994 Received: by gw.home.vix.com id AA23717; Thu, 14 Apr 94 22:39:48 -0700 Message-Id: <9404150539.AA23717@gw.home.vix.com> X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: dns-security@tis.com Reply-To: paul@vix.com Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of "Fri, 15 Apr 1994 11:41:49 +0200." <9404150242.AA13052@necom830.cc.titech.ac.jp> Date: Thu, 14 Apr 1994 22:39:47 -0700 From: Paul A Vixie i remain convinced that this is not a thread that ought to be pursued on dns-security; it belongs in the DNS WG proper. however, several points here need addressing, so i'll address them here. > > >i was thinking that 1500 bytes would be reasonable, > > Reasonable today, but not in the future, I'm afraid. IPng will need 20 > byte NSAP or 8, 16, 24, ... byte ASEQ, at least. Rob Austin mentioned > the possibility to have a lot more root NSes at the last DNS BOF, 1500 bytes may or may not be a reasonable upper bound for DNS responses; that's not an issue i've considered debating. 1500 bytes _is_ a reasonable size for a UDP datagram that wants to avoid fragmentation in most of 1994's networks. 1500 bytes is also a reasonable buffer size for a stub resolver to use without unduly affecting the application it is being called from. > > >it reasonable to send a larger-than-512-byte datagram. sending it always > > >seems like a bad plan. sending it if the packet size is in some range > > >might not be right either. > > Like root NS cases, there will be a lot of cases when one must send > packets > 512. So, if we must change something, we should change the > protocol so that they can be sent always. i don't know who the DNS WG chair is; perhaps she would like to hear your suggestion. > > >allocating one of the unused bits in the header > > >to "long datagrams accepted" could be reasonable, but once again, this is > > >something i'll need to see a blessed FYI on before i add code to BIND. > > Still, it might be good to allocate a bit to indicate that client can > receive larger (maybe 4096 or 8192) packet or psuedo TCP reply. that's what i said? > > If its true that many DNS implementations blindly copy header bits > > from a query into recursive queries they send, as I believe Ohta-san > > said, then wouldn't this cause problems if such a bit were used to > > indicate receptivity to long datagrams? > > It is unlikely that forwarders can't have enough amount of buffer > (recent processors have more than 64KB of onchip chache), but if > you mind, make forwarders not blidnly copy bits. that doesn't matter! i admit that i am becoming most frustrated with your repeated misunderstandings of the ideas expressed in this forum. you cannot possibly be as ignorant of the actual issues as the above paragraph indicates; i therefore suspect a translation error or great carelessness or both. please take the time to understand the issues being discussed before you post a message to the entire forum which proclaims your ignorance as this one did. i will be glad to help you, constructively, to understand the issues under discussion; all you need to do is approach me privately rather than sending broadcast messages. (hint: many of the forwarders that are "blindly copying bits" are going to keep doing that, and we need to design any/all protocol enhancements with that thought clearly in our minds.) > As a candidate of other changes, I'd like to propose the preservance > of the order of RRs. It'll make load balancing work better. it would have been wonderful indeed if that had been designed into the DNS spec originally. however, i know of one popular caching forwarder that LIFO's its RR's under certain conditions. since DNS datagrams have no version stamp, it will never be possible for a resolver to know whether a response has been generated or cached by some forwarder that does this; absent a complete protocol turn, it will not be possible to depend on RR ordering. i have directed replies to myself, to spare the list any further messages on this non-security-related thread.   Received: from sol.tis.com by magellan.TIS.COM id aa10085; 14 Apr 94 22:18 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA18944; Thu, 14 Apr 94 22:17:43 EDT Received: by relay.tis.com; id AA20690; Thu, 14 Apr 94 22:18:39 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma020685; Thu Apr 14 22:18:07 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 15 Apr 94 11:09:45 +0859 From: Masataka Ohta Return-Path: Message-Id: <9404150210.AA12880@necom830.cc.titech.ac.jp> Subject: Re: Security AD's assesment re RSAREF licensing To: Christian Huitema Date: Fri, 15 Apr 94 11:09:43 JST Cc: paul@vix.com, pvm@isi.edu, kent@bbn.com, dns-security@tis.com In-Reply-To: <199404141651.AA29770@mitsou.inria.fr>; from "Christian Huitema" at Apr 14, 94 6:51 pm X-Mailer: ELM [version 2.3 PL11] > => I think we should start making name servers and resolvers can accept > => (but not send) 64K byte UDP packets, immediately. > That is really a terrible idea. The only error correction you can do on UDP is > repeat the whole packet. In case of semi congested link, this is a sure kill. That's why I haven't said we should generate 64K reply. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa10177; 14 Apr 94 22:50 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA19309; Thu, 14 Apr 94 22:49:53 EDT Received: by relay.tis.com; id AA20918; Thu, 14 Apr 94 22:50:49 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma020906; Thu Apr 14 22:50:02 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 15 Apr 94 11:41:50 +0859 From: Masataka Ohta Return-Path: Message-Id: <9404150242.AA13052@necom830.cc.titech.ac.jp> Subject: Re: Security AD's assesment re RSAREF licensing To: "Donald E. Eastlake 3rd" Date: Fri, 15 Apr 94 11:41:49 JST Cc: paul@vix.com, dns-security@tis.com In-Reply-To: <9404141918.AA23847@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Apr 14, 94 3:18 pm X-Mailer: ELM [version 2.3 PL11] > >i was thinking that 1500 bytes would be reasonable, Reasonable today, but not in the future, I'm afraid. IPng will need 20 byte NSAP or 8, 16, 24, ... byte ASEQ, at least. Rob Austin mentioned the possibility to have a lot more root NSes at the last DNS BOF, > >it reasonable to send a larger-than-512-byte datagram. sending it always > >seems like a bad plan. sending it if the packet size is in some range > >might not be right either. Like root NS cases, there will be a lot of cases when one must send packets > 512. So, if we must change something, we should change the protocol so that they can be sent always. > >allocating one of the unused bits in the header > >to "long datagrams accepted" could be reasonable, but once again, this is > >something i'll need to see a blessed FYI on before i add code to BIND. Still, it might be good to allocate a bit to indicate that client can receive larger (maybe 4096 or 8192) packet or psuedo TCP reply. > I would think something more like 1250 bytes of DNS payload would be > good. Then it would likely fit on Ethernet even with a considerable > amount of header info (IPng, IPsec, ...) wrapped around it. IPng is OK and 1250 might be reasonable. But, IPsec will be constructed over secure DNS, not vice versa, I think. > If its true that many DNS implementations blindly copy header bits > from a query into recursive queries they send, as I believe Ohta-san > said, then wouldn't this cause problems if such a bit were used to > indicate receptivity to long datagrams? It is unlikely that forwarders can't have enough amount of buffer (recent processors have more than 64KB of onchip chache), but if you mind, make forwarders not blidnly copy bits. Masataka Ohta PS As a candidate of other changes, I'd like to propose the preservance of the order of RRs. It'll make load balancing work better.   Received: from sol.tis.com by magellan.TIS.COM id aa15234; 18 Apr 94 11:18 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA28628; Mon, 18 Apr 94 11:18:26 EDT Received: by relay.tis.com; id AA18075; Mon, 18 Apr 94 11:19:27 EDT Message-Id: <9404181519.AA18075@relay.tis.com> Received: from labs-n.bbn.com(128.89.0.100) by relay via smap (V1.3mjr) id sma018067; Mon Apr 18 11:18:49 1994 To: "Donald E. Eastlake 3rd (Beast)" Cc: dns-security@tis.com Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of Thu, 14 Apr 94 10:16:48 -0400. <9404141416.AA20745@skidrow.lkg.dec.com> Date: Mon, 18 Apr 94 11:13:24 -0400 From: Steve Kent Donald, I didn't personally use the term "squeeing bits" but I think it is fair to say that the scheme in question, does strive to be space efficient, in that it eschews the algorithm-independent approach of basing signatures on one-way hash values, for a hybrid approach that relies on RSA's ability to sign data in a reversible fashion. Steve   Received: from sol.tis.com by magellan.TIS.COM id aa18583; 19 Apr 94 1:25 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA18128; Tue, 19 Apr 94 01:24:36 EDT Received: by relay.tis.com; id AA24249; Tue, 19 Apr 94 01:25:39 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma024199; Tue Apr 19 01:20:37 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 19 Apr 94 14:08:59 +0859 From: Masataka Ohta Return-Path: Message-Id: <9404190509.AA01554@necom830.cc.titech.ac.jp> Subject: Re: Security AD's assesment re RSAREF licensing To: paul@vix.com Date: Tue, 19 Apr 94 14:08:57 JST Cc: dns-security@tis.com In-Reply-To: <9404150539.AA23717@gw.home.vix.com>; from "Paul A Vixie" at Apr 14, 94 10:39 pm X-Mailer: ELM [version 2.3 PL11] > > Reasonable today, but not in the future, I'm afraid. IPng will need 20 > > byte NSAP or 8, 16, 24, ... byte ASEQ, at least. Rob Austin mentioned > > the possibility to have a lot more root NSes at the last DNS BOF, > > 1500 bytes may or may not be a reasonable upper bound for DNS responses; > that's not an issue i've considered debating. 1500 bytes _is_ a reasonable > size for a UDP datagram that wants to avoid fragmentation in most of 1994's > networks. 1500 bytes is also a reasonable buffer size for a stub resolver > to use without unduly affecting the application it is being called from. There are several goals and limitations on DNS packet data size. My estimations are: size which does not cause fragmentation (8) size which does not cause fragmentation most of the time in the past (512) size which does not cause fragmentation most of the time today (1400) size which does not cause serious fragmentation today (4K~8K) size which does not cause fragmentation most of the time in the future (4K~8K) size which does not cause serious fragmentation in the future (64K) size for stub resolvers (512~64K, opinions vary) minimum size necessary for DNS today (>512) minimum size necessary for DNS in the future (>1500) size which is assured to be accepted by existing servers (512) size which can be accepted by most of the existing servers (1024) > that doesn't matter! i admit that i am becoming most frustrated with your > repeated misunderstandings of the ideas expressed in this forum. You are too narrowly sighted on the issue. If we are to make backward incompatile change, we should do so not to require such a change again in the future. > (hint: many of the forwarders that are "blindly copying bits" are going to > keep doing that, and we need to design any/all protocol enhancements with > that thought clearly in our minds.) Many of the existing forwarders (including your BIND) won't accept packets larger than 1024 bytes, which makes the proposed protocaol change backward incompatible. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa19084; 19 Apr 94 5:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA18426; Tue, 19 Apr 94 01:42:42 EDT Received: by relay.tis.com; id AA24348; Tue, 19 Apr 94 01:43:45 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma024313; Tue Apr 19 01:39:43 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 19 Apr 94 14:33:16 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404190533.AA01660@necom830.cc.titech.ac.jp> Subject: Re: Security AD's assesment re RSAREF licensing To: Steve Kent Date: Tue, 19 Apr 94 14:33:14 JST Cc: dee@skidrow.lkg.dec.com, dns-security@tis.com In-Reply-To: <9404181519.AA18075@relay.tis.com>; from "Steve Kent" at Apr 18, 94 11:13 am X-Mailer: ELM [version 2.3 PL11] > Donald, > > I didn't personally use the term "squeeing bits" but I think > it is fair to say that the scheme in question, does strive to be space > efficient, in that it eschews the algorithm-independent approach of > basing signatures on one-way hash values, for a hybrid approach that > relies on RSA's ability to sign data in a reversible fashion. It is signature which is large. Unfortunately, as signatures are truely random, you can't squeeze bits at all. On the other hand, other data are small. You don't have to vigorously squeeze bits from them unless it is absoltely necessary. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa21055; 19 Apr 94 9:58 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02472; Tue, 19 Apr 94 09:58:13 EDT Received: by relay.tis.com; id AA27367; Tue, 19 Apr 94 09:59:17 EDT Message-Id: <9404191359.AA27367@relay.tis.com> Received: from labs-n.bbn.com(128.89.0.100) by relay via smap (V1.3mjr) id sma027358; Tue Apr 19 09:58:17 1994 To: Masataka Ohta Cc: dns-security@tis.com Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of Tue, 19 Apr 94 14:33:14 +0200. <9404190533.AA01660@necom830.cc.titech.ac.jp> Date: Tue, 19 Apr 94 09:53:54 -0400 From: Steve Kent Masataka, While it is true that signatures are large, the use of RSA in the current scheme enables one to pack multiple, short data items into a single signature block. If one were required to sign hashes, not data items, then data items that are shorter than the hash could not be packed in this fashion. This is the feature of the current scheme that makes its RSA-dependent and which is clearly motivated by a desire to optimize for space in server responses. Steve   Received: from sol.tis.com by magellan.TIS.COM id aa21807; 19 Apr 94 13:13 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA22373; Tue, 19 Apr 94 13:12:56 EDT Received: by relay.tis.com; id AA29263; Tue, 19 Apr 94 13:14:00 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma029258; Tue Apr 19 13:13:39 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA20397; Tue, 19 Apr 94 10:05:15 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA17982; Tue, 19 Apr 1994 13:06:55 -0400 Message-Id: <9404191706.AA17982@skidrow.lkg.dec.com> To: Masataka Ohta Cc: dns-security@tis.com Subject: Re: SIG RR location in responses & Re: Real truncation problem In-Reply-To: Your message of "Thu, 07 Apr 94 12:04:18 +0200." <9404070304.AA00261@necom830.cc.titech.ac.jp> Date: Tue, 19 Apr 94 13:06:55 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: Masataka Ohta To: "Donald E. Eastlake 3rd" Cc: dns-security@tis.com In-Reply-To: <9404062135.AA10640@skidrow.lkg.dec.com>; from "Donald E. Eastlak e 3rd" at Apr 6, 94 5:35 pm X-Mailer: ELM [version 2.3 PL11] >> Well, I went and read Section 4.2.1 of RFC 1034 very carefully and it >> didn't change my opinion that you could retrieve the type A glue >> record with a separate query, just like you can retrieve the RSA >> and/or SIG RR's with a separate query. You seem to be assuming that I >> meant an A RR query to the server pointed to by the NS RR and, as you >> say, you can't query that unless you have its IP address. What I >> meant was an A RR query to the same server where you initially found >> the NS for this lower level zone, i.e., the server where the A record >> is present as glue. Would this actually not work in current >> implementations? > >It does not work. Have you actually tried it? Using nslookup I have no problems at all retrieving type A glue records by doing specific queries for them. That includes from the root servers which, I understand, have chaching turned off. So I must really be getting it from their zone database and not because they also happen to have cached, it. I still think that if you need a name (NS, for example) and its IP address and the key for its zone and you need all this signed because you are doing secure resolution and all this won't fit in a UDP packet, then it makes no logical difference what is dropped as long as you can get it later with an additional query(s). Having said all that, it is probably more "natural" for a resolver to do additional queries for RRs of the same name, such as key or signature RRs, and less "natural" to do a glue RR retrieval with the appropriate different owner name. The current draft already clearly states that additional info type A's are included in the additional info seciton with *higher* priority than the corresponding key RR. I've put in a change that says that if an additional info type A and its SIG won't both fit, the type A should be included. (Previously said it may be included.) >What do you think "truncation problem" means, at all? It seems to me that what problem is caused by truncation depends on the context. In the context we are talking about, it could, for example, be that all the name servers for a zone had names inside that zone so you could never get to any of them unless you could get their IP address via a type A glue record. However, a sufficiently clever resolver could, on noticing truncation in the additional information section on an NS retreival, do explicit A retrieval from the server where it got the NS's looking for glue information. I don't know if any existing resolvers do that. >> As long as you need the A glue RR and the RSA RR and the SIG RR >> signing them to securely look into a zone, I just don't see that much >> difference between truncation losing different ones of them. > >Anyway, if you think the problem does not exist, it's OK. If you have >any further concern on the real truncation prolem related to glue records, >ask it in "namedroppers". > >The conclusion here is not to make secure DNS complex only trying to >solve non-existent problem. > >That's because you don't udnerstand Sorry I don't always understand you but I find many of your remarks to be very short and cryptic. While I certainly don't claim that all of my remarks are models of clarity or anything, when there is confusion, I try my best to give clearer and more complete explanations. >> >That is: >> > 1) Don't introduce new abbreviaiton and use the RR format >> > currently used in the DNS packets. >> > 2) Always use MD5 >> > 3) Use a single record for authenticaiton, not multiple SIGs >> >> Re your points 1 & 2: >> A specific requirement decided at the Houston IETF was not to >> take significantly more queries. If you start getting lots of >> truncation, you will start having to make twice as many queries. Many >> people think this would be a problem. > >With 1 and 2, there will be no extra queries, because there won't be >much truncations occure. Only statistics and/or reasonable projections are going to convince anyone on this question. >> Re your point 3: >> I am not willing to accept the limits a single SIG RR with >> only hash signets places on the number of types of RR you can have >> under a name. Even completely ignoring glue and message signets, you >> need 18 bytes. With the minimum allowed key size, then only 3 types >> of RRs you would be allowed to have securely under a name. > >I'm assuming to use something like RSA-CBC here. Sorry, but I don't know what you means by RSA-CBC. And the kinds of things "RSA-CBC" suggest to me don't seem like they would be useful in the DNS case. Please give a more detailed explatation. >> >SD copied by security unaware forwarders will cause a lot of problems. >> >> Ahh... It was not clear to me that you were talking about copying >> into forwarded requests rather than responses. If they are being >> copied forward like that, then it clearly is a problem. The next >> thing I would suggest is not to set the SD bit until you actually get >> a reply with the SA (security available bit). This means your first >> query would be less efficient but you would cache this flag and later >> queries could be more efficient. > >It might be an acceptable hack if your scheme were already widely deplyed. > >Otherwise, IMHO, it is too complex to be acceptable. According to later posts by Paul Vixie, at least BIND clears all these bits in queries it sends so it would not have problems with an initial resolver set SD bit. >> If unused bits are also being copied >> back into replies sent by servers in response to recursive queries >> from the bit set on replies they receive, then using header bits to >> indicate security awareness is pretty hopeless and security awareness >> will probably have to wait for "DNS-II" or whatever based on a >> different op code or something else that does not have these unused >> header bit problems. > >I'm afraid your proposal, using new representation of RR records and >breaks several DNS architechture, is pretty much close to DNS-II. > >SD bit on means too much. I don't think so. I'm about to post something re "DNS-II" on namedroppers so you can see what I mean. The SD bit just means that the resolver is announcing it is security aware. If you are ever going to have a server do anything different for security aware resolvers, you need some way to signal this. >> >> >Is it really meaningfull to remove one or two 14 byte record when you >> >> >are using 128 byte (1024) SIG RR(s)? >> >> >> >> I make no assumptions about the total size of RRs >> > >> >Then, you can't evaluate the effect of your optimizaiton. >> >> What I meant was that I tried to make the minimum of limiting >> assumptions on the total size of RRs. > >Neither do I. > >> By not assuming such limits, I >> came up with a scheme which works when the optimizations it proposes >> are required and when a scheme without such optimizations will not >> work. Thus, under my broad assumptions, I can evaluate my >> optimizations as being required to meet the dns security design goals. > >My opinion is that with usual circumstance, your optimization is >ineffective and, thus, should be removed. Why are the optimizations in our scheme "ineffective"? They do save space and there are cases when they reduce the number of queries necessary. Or did you mean "unnecessary" becasue you don't think such cases will ever occur? >> >> Eliminating an RR when it is incorporated inside the SIG is optional >> >> under the current draft. >> > >> >Name servers with different OPTIONS can't communicate each other. >> >So, it can't be optional. >> >> Why can't they communicate with each other? >> >> Under the proposal, a security aware server composing a reply to a >> security aware resolver can surpress RR's included in a SIG or not. A >> security aware resolver has to be able to handle it either way. > >Then, it is mandatory for resolvers. Yes, it is mandatory for resolvers that declare themselves to be security aware using the SD bit (or possibly in some other way if there turn out to be insurmountable problems with the SD bit). Non-security aware resolvers don't have to do anything about it because they won't get replies where RRs have been surpressed. >> Under >> the general Internet principle of being conservative in what you send >> and liberal in what you accept, security aware servers should always >> surpress the RR in replies they send but security aware resolvers >> should accept replies where they are not surpressed. > >I'm afraid you completely misunderstand the Internet. > >Under the general Internet principle of being conservative in what you >send, security aware servers should always ADD the RR in replies, which >is what current DNS is doing. I guess what is conservative and what is liberal is in the eye of the beholder. You are comparing behavious with current DNS. I am comparing behavior (for an exchange between a secruity aware resolver and a security aware server only) with the recommended optimized behavior. >As such a behaviour is quite basic to the current DNS, even the >most conservative secutiry aware resolvers don't have to accept >completely broken replies. > >Your proposal to try to handle partial RRs makes many assumptions, >such as caching behaviour, of the current implementaiton of DNS. ? There aren't any "partial RRs" in our proposal. Perhaps you mean the partial RR signet? >> >> But there are clearly cases when not >> >> eliminating a plain text RR that did fit into the SIG will cause >> >> truncation. It might, for example, force the RSA RR additional >> >> information mentioned above to not fit and cause truncation. >> > >> >Unlike glue As, you can remove large RRs from the additional >> >section without causing any problem. OK? >> >> It causes the problem of twice as many queries. > >In rare case when SIG is large, yes, which affect the expected number >of queries very little. See remarks above about how this will only be settled by reasonable statistics/projections. >> >> I thought people considered the draft complicated enough as it is. >> > >> >That's why I suggest simplification. Why don't we use MD5 all the time? >> >> Because it leads to bigger replies, more truncation, and more queries. > >No. If RRs of a type is large, truncation occurs anyway. If it is small >truncation won't occure. The latter is almost always the case. See remarks above about how this will only be settled by reasonable statistics/projections. >> >> suppose some compression scheme could be added but I would not want to >> >> do that unless implementation experience indicated it was necessary. >> >> >> >> If I did want to add compression, >> > >> >No, please. >> >> Sorry, I thought you were complaining about the lack of compression of >> RRs when they were incorporated in SIGs. Certainly more compression >> could be done. > >I'm complaining about the complexity of your scheme trying to reduce >the packet size which will, most of the time, result in the increase >of the size. ? The various signature encoding means in our proposal provide many ways to get the maximum benefit from each signature RR. I don't see why you say they will increase the packet size. >> >What I suggested was to use block authentication to cover larger >> >number of signets. >> >> ? Block authentication? Do you mean transaction/message >> authentication? If you suggested something like this in an earlier >> message, either I didn't understand it or I don't remember it. > >As I wrote, something like RSA-CBC. As I say above, I really have no idea what you mean by RSA-CBC. > Masataka Ohta Donald   Received: from sol.tis.com by magellan.TIS.COM id aa21879; 19 Apr 94 13:17 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA22707; Tue, 19 Apr 94 13:17:00 EDT Received: by relay.tis.com; id AA29297; Tue, 19 Apr 94 13:18:03 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma029290; Tue Apr 19 13:18:00 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA20803; Tue, 19 Apr 94 10:11:37 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA18021; Tue, 19 Apr 1994 13:13:16 -0400 Message-Id: <9404191713.AA18021@skidrow.lkg.dec.com> To: Paul A Vixie Cc: dns-security@tis.com Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of "Tue, 12 Apr 94 15:22:30 PDT." <9404122222.AA23689@gw.home.vix.com> Date: Tue, 19 Apr 94 13:13:16 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: Paul A Vixie >I'd like to speak to the recurring statement in this forum that since RSA's >technology has already been written into the PEM standard, why should we >readdress those issues now in DNS? I have never said that. I think, however, that the selection of RSA public keys for PEM, various international security standards, and many other systems is one factor that it is quite reasonable to take into account, along with numerious other factors. >My answer comes in several parts. > >First and foremost, the PEM agreements were wrong-headed and politically >motivated, in my view. DNS could [use] PEM as a PKP/RSA precedent only if the >decision to use RSA had been quite a bit less controversial during the PEM >standardization process, or if the results of that standardization process >had been an uncontestable win. Neither case obtains. PEM is so far a >failure, after having been a divisive, bitter battle between people who had >formerly been but will probably not again become partners in various common >causes. I agree that PEM is dismal failure but, unfortunately, I don't agree with much else in the paragraph above. The failure of PEM has nothing to do with RSA. (In my opinion, it has to do with trying to force a single hierarchy instead of making any hierarchy optional, using the hopeless "Distinguished Name"s, X.500 viewpoint, Asinine One syntax, etc.) Look at a more successful secure mail system, PGP. It uses RSA also. Secondly, the harder fought was the decision to use RSA in PEM, the stronger a precedent it is. If RSA had just sailed through, the decision to adopt there could have been overlooked problems. But if it was highly controversial, then I think it very likely that most problems were considered and overcome. >Second, DNS is an ``essential service'' in Internet. Mail has been important >and will no doubt continue to be important, but I personally know several >people who use only NNTP and WWW and consider themselves ``Internet citizens.' ' >I do not know of any person or any service which can survive and prosper on >the Internet without being able to translate symbolic names into addresses, >and vice-versa. So? There is no proposal to cause any existing DNS service to stop working. >Third, while PEM will (if it succeeds, which is still possible) merely >enable new uses for Mail, an RSA version of DNS will have far more sweeping >effects. Even if PEM becomes common, people will still be able to do the >same things with unauthenticated mail that they did before PEM came out; ditto DNS. >the risk will be that senders of mail cannot be authenticated, allowing all >kinds of forgeries. People whose businesses depend on authenticity of Mail >can pay for and use PEM; it would be wildly silly of them to do otherwise, >given its existence as an Internet standard. However, once a secure >version of DNS comes out, people who aren't able to use it will be subject >to all kinds of forgeries involving actual sessions on their computers or >refusal of their sessions on other people's computers -- I predict that when >secure DNS comes out, ``everybody'' will use it, out of a concern for self- >defense that drawfs any worries they may have had about unauthenticated Mail. Come on. Based on the type of analysis you are doing above, there is no difference at all between secure mail and secure DNS. With unsecure mail, you get bogus messages. With unsecure DNS, you get bogus RRs. Your wording above strongly suggests that the deployment of secure DNS will *cause* people without it to be subject to forgeries they are not subject to now. I can't see how that can be true. Furthermore, secure DNS does not protect you against forged TCP sessions. All it does in enable you to tell if RRs you have retrieved are authentic. Period. Someone can still forge random TCP/IP packets. So I think the gains of secure DNS are not such that "everyone" will be compelled to jump on it immediately, though of course it will be quite useful and, I hope, popular. >Unless someone wants to debate this point in greater detail, I would like all >participants in the larger "should we use RSA in DNS" debate to stop quoting >PEM as either a success story or a precedent. PEM has not been a success, >and did/does not have a comparable result-domain. I don't quote PEM as a success story. And, while the importance of PEM as a precedent is debatable, I don't see how you can claim it is not a precedent. I plan to continue to quote PEM, PGP, ISO, Lotus Notes (which uses RSA) and other precedents where appropriate. >Paul Vixie >Redwood City, CA >decwrl!vixie!paul > ><><><><><><><><><><><><><><><><><><><><><><><><><>< I believe that public key tchnology is essential to a workable secure DNS and that RSA is technically superior to alternatives. Why are we giving such enormous weight to the small cost that will temporarily be imposed on US providers of services requiring secure DNS that have not bought their DNS with a pubic key license included? Any public key system will impose some cost on this segment of the market. No one outside the US needs to worry about RSA at all (although they would for some other public key technologies). No one giving away their TCP/IP stack or BIND in the US needs to worry. No one selling their TCP/IP stack inside the US needs to worry if either they are already licensed for RSA or they are willing to simply sell their product with non-secure DNS and give away the tailored secure DNS that goes with their product. No one offering a commercial service requiring secure DNS inside the US need worry if they buy their DNS from someone who is licensed. So what's left? A few years in which people in the US only who offer services requiring secure DNS and who don't get their DNS software from a licensed vendor will have to pay a reasonable license fee. Donald From: Paul A Vixie To: Masataka Ohta Cc: dns-security@tis.com In-Reply-To: Your message of "Tue, 12 Apr 1994 12:54:21 +0200." <9404120354.AA26666@necom830.cc.titech.ac.jp> >> Does someone know what happens if my RSA-BIND interact with RSA-BIND in US? > >that depends on how complete the eventual RFC is. if it specifies the >algorythm, than if the RSA you use in japan is different from the one >released publically by RSA here in the US, i suspect that japan's will >lose out. Paul, Given the simplicity and elegance of RSA (there is really only one right answer to modular exponentiation of positive whole integers), I can't see how different sets of RSA routines could be any problem at all. You sound a little like the people from NSA trying to convince Congressmen that there is something inferior to foreign (ie, non-US) implemented DES and that only American DES is good DES, to justify export restrictions. Really, all DESes and all RSAs interoperatve whether implemented by US citizens in the USA or otherwise. Donald   Received: from sol.tis.com by magellan.TIS.COM id aa23077; 19 Apr 94 15:33 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA03224; Tue, 19 Apr 94 15:33:06 EDT Received: by relay.tis.com; id AA00679; Tue, 19 Apr 94 15:34:10 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma000672; Tue Apr 19 15:34:03 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA29445; Tue, 19 Apr 94 12:26:39 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA19319; Tue, 19 Apr 1994 15:28:19 -0400 Message-Id: <9404191928.AA19319@skidrow.lkg.dec.com> To: Masataka Ohta Cc: dns-security@tis.com Subject: Re: DNS security draft In-Reply-To: Your message of "Thu, 14 Apr 94 11:28:28 +0200." <9404140228.AA06895@necom830.cc.titech.ac.jp> Date: Tue, 19 Apr 94 15:28:19 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: Masataka Ohta To: "Donald E. Eastlake 3rd" In-Reply-To: <9404111650.AA15440@skidrow.lkg.dec.com>; from "Donald E. Eastlak e 3rd" at Apr 11, 94 12:50 pm >> >A resolver must be able to securely know whether SIG RRs are available >> >or not for which purpose SA is nothing. >> >> In a secure environment, your resolver will hopefully start from a >> known secure zone. The way it tells whether other zones are secure is >> by travering the DNS tree and looking at the RSA RRs. > >I now thinking your scheme does not work at all for traversing. I'm not sure what you mean. See below. >You wrote: > > 7.1 Boot File Format > > While it might seem logical for everyone to start with the key for > the root zone, this has problems. The logistics of updating every > DNS resolver in the world when the root key changes would be > excessive. It may be some time before there even is a root key. And > furthermore, some organizations may explicitly wish their "interior" > DNS implementations to trust only their own zone. These interior > resolvers can then go through the organization's zone server to > access data outsize the organization's domain. > >But I think updating of root keys is only as difficut as updating of >root name servers and should be done anyway. Yes, the root zone key should be updated occasionally. The draft recommends chainging zone keys annually. My point was that if there are 1,000,000 stub resolvers out there, having them all start only knowing the root zone key is a *bad* idea. >As for traversing, suppose that there are Zones: A, B and C and assume >the following: > > 1) B is a child zone of A > 2) A and C is located independent region of the entire DNS tree > 3) Neither A's nor C's parent is secure. > 4) A is served by host X > 5) B is served by host Y > 6) C is served by host Z Security is based on the zone structure. What zone is on what server(s) does not make any difference. All the zones could be served from one host or all from different hosts. It makes no difference. > 7) B is pointed from A > 8) C is pointed from B > 9) host H knows KEY of A > 10) Neither X nor H does not know that C is pointed from B. > > > A C > / \ / \ > / \ / \ > / \ / \ > B / \ / \ > / \ / \ > / \ > / > pointer to C > > >If zone C is traversed from the root, it is not secure, of course. > >So, how can a resolver on host H traverse DNS tree to know C is secure? For host H to securely know that C is secure, it must get to it entirely through secured RRs. In the case you describe, then if H tries to go up to root or the first common domain name from A and then back down to C, it must treat C as not secure. After all, someone may be spoofing output from root or this common higher node. The only way around this is for the pointer to C in zone B to be accompanied by an RSA RR for zone C. Since zone B is secure, this RSA RR will be signed. Since zone A was secure, the key for zone B was signed by A along with the NS RRs for B in A. So host H can trust zone C. This was the question that Jeff Schiller was asking at the DNS SEC WG meeting in Seattle. >In general, I think resolvers can't be sure that a zone is secure >unless it knows key of its ancestor zone in advance. That's easier but there is nothing to stop horizontal signing of keys between arbitrary parts of the DNS tree. >> The SA bit, which tells >> about the characteristics of a particular server, has nothing to do >> with this. Different servers for the same zone might some be security >> aware with the SA bit on in their responses and some be security >> non-aware with the SA bit off. > >Hmmm, I see. > > Masataka Ohta Donald   Received: from sol.tis.com by magellan.TIS.COM id aa23931; 19 Apr 94 18:12 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13319; Tue, 19 Apr 94 18:12:29 EDT Received: by relay.tis.com; id AA01990; Tue, 19 Apr 94 18:13:33 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma001983; Tue Apr 19 18:13:25 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA09128; Tue, 19 Apr 94 15:05:40 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA21085; Tue, 19 Apr 1994 18:07:19 -0400 Message-Id: <9404192207.AA21085@skidrow.lkg.dec.com> To: pkarger@gte.com Cc: dns-security@tis.com Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of "Thu, 14 Apr 94 10:21:05 EDT." <9404141421.AA02924@pkarger.tcc> Date: Tue, 19 Apr 94 18:07:19 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp The Domain Name System seems like one are where you really want global interoperability and universal adoption of one algorithm at a time. This was discussed at the Working Group Meeting and it was felt that some must be zero bits that could be used to signal a change to a new algorithm, should one ever prove necessary, were adequate. Actually, while there are such bits in the signature RR, right now there is no such bit in the key RR. The write up on the key RR says to ignore ones in the undefined bits so I will change that so there is a clear escape bit. From: "Paul A. Karger" To: Masataka Ohta Cc: Steve Kent , paul@vix.com, dns-security@tis.com, pak0@gte.com Reply-To: pkarger@gte.com Phone: +1 (617) 466-3844 Fax: +1 (617) 890-9320 Organization: GTE Laboratories In-Reply-To: Your message of "Wed, 13 Apr 94 13:34:52 +0200." <9404130435.AA02338@necom830.cc.titech.ac.jp> >The last few messages have discussed algorithm independence in >the context of patents/licensing/legal issues. There is >another more fundamental reason to design standards to be >encryption algorithm independent. The history >of cryptology clearly teaches us that (except for one-time pads) >no algorithm lasts forever. Whether the algorithm is DES >or RSA or ROT-13, a communications protocol DES and ROT-13 are terrible examples for you to pick. ROT-13 is a deliberately trivial algorithm. DES was known to be just on the verge of computational inadequacy from day one. These algorithms were doomed from the start. No forseeable amount of processor improvement or an reasonable projection of algorithm improvements will obsolete RSA in the next few decades with the key sizes provided which is all I'm willing to worry about. It would take a discontinuous mathematical breakthrough, which is certainly not impossible but, in my mind, improbable. >should always have a provision for easily and quickly switching to >a new algorithm in preparation for the day when the current algorithm >of choice gets broken. > > - Paul While I do not believe that RSA will be broken anytime soon, I agree that there should be a provision for phasing over to some other algorithms should that prove necessary for any reason. Putting the flag bytes first in the signature and key RRs and having a must-be-zero bit to flag such a change seems adequate to me. Donald   Received: from sol.tis.com by magellan.TIS.COM id aa24011; 19 Apr 94 18:52 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13788; Tue, 19 Apr 94 18:51:46 EDT Received: by relay.tis.com; id AA02250; Tue, 19 Apr 94 18:52:50 EDT Received: from ns.gte.com(132.197.8.9) by relay via smap (V1.3mjr) id sma002245; Tue Apr 19 18:52:20 1994 Received: from bunny.gte.com by ns.gte.com (5.65c/IDA-1.4.4) id AA17172; Tue, 19 Apr 1994 18:50:02 -0400 Received: from pkarger by bunny.gte.com (5.61/GTEL2.19) id AA06391; Tue, 19 Apr 94 18:48:30 -0400 Received: from localhost by pkarger.tcc (4.1/SMI-4.1) id AA13784; Tue, 19 Apr 94 18:49:21 EDT Message-Id: <9404192249.AA13784@pkarger.tcc> To: "Donald E. Eastlake 3rd (Beast)" Cc: pkarger@gte.com, dns-security@tis.com Reply-To: pkarger@gte.com Phone: +1 (617) 466-3844 Fax: +1 (617) 890-9320 Organization: GTE Laboratories Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of "Tue, 19 Apr 94 18:07:19 EDT." <9404192207.AA21085@skidrow.lkg.dec.com> Date: Tue, 19 Apr 94 18:49:15 -0400 From: "Paul A. Karger" Don Eastlake writes: >DES and ROT-13 are terrible examples for you to pick. ROT-13 is a >deliberately trivial algorithm. DES was known to be just on the verge >of computational inadequacy from day one. These algorithms were >doomed from the start. > >No forseeable amount of processor improvement or an reasonable >projection of algorithm improvements will obsolete RSA in the next few >decades with the key sizes provided which is all I'm willing to worry >about. It would take a discontinuous mathematical breakthrough, which >is certainly not impossible but, in my mind, improbable. I don't expect RSA to be broken anytime soon, either, BUT ----- The entire history of cryptography is littered with crypto algorithms that were thought to be unbreakable until someone broke them. The ONLY provably unbreakable algorithm is one-time pads. Everything else is potentially breakable. I really think that no matter how secure we think RSA (or any other algorithm) is, a communications standard should provide a mechanism to allow a change in algorithm if the unthinkable should actually happen. >While I do not believe that RSA will be broken anytime soon, I agree >that there should be a provision for phasing over to some other >algorithms should that prove necessary for any reason. Putting the >flag bytes first in the signature and key RRs and having a >must-be-zero bit to flag such a change seems adequate to me. A one bit flag to define an algorithm change is not adequate. Just as for many other protocols, the right thing to do is to define an algorithm type field and a registry of algorithms and define a protocol negotiation over what algorithm is actually going to be used. I have no problem with defining a default algorithm, so that negotiation need not be done unless you actually want some other algorithm. By doing this, you also provide the mechanism so that communities of interest who find RSA unacceptable (for whatever reason) can substitute crypto algorithms of their own choosing. That would allow substituting a weak algorithm for compliance with US export control or an NSA-provided algorithm for DoD purposes or some other algorithm whose use was required in some other country or an algorithm free of patent license restrictions, etc. (NO - I'm not advocating CLIPPER here - only flexibility in choice of algorithm) Obviously, if different communities choose different algorithms, then communications between those communities will fail, but that is by their choice.   Received: from sol.tis.com by magellan.TIS.COM id aa24523; 20 Apr 94 0:49 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA22592; Wed, 20 Apr 94 00:48:46 EDT Received: by relay.tis.com; id AA04447; Wed, 20 Apr 94 00:49:51 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma004442; Wed Apr 20 00:48:58 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA22103; Tue, 19 Apr 94 21:06:39 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA23362; Wed, 20 Apr 1994 00:08:17 -0400 Message-Id: <9404200408.AA23362@skidrow.lkg.dec.com> To: pkarger@gte.com Cc: dns-security@tis.com Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of "Tue, 19 Apr 94 18:49:15 EDT." <9404192249.AA13784@pkarger.tcc> Date: Wed, 20 Apr 94 00:08:17 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: "Paul A. Karger" To: "Donald E. Eastlake 3rd (Beast)" Cc: pkarger@gte.com, dns-security@tis.com Reply-To: pkarger@gte.com Phone: +1 (617) 466-3844 Fax: +1 (617) 890-9320 Organization: GTE Laboratories In-Reply-To: Your message of "Tue, 19 Apr 94 18:07:19 EDT." <9404192207.AA21085@skidrow.lkg.dec.com> Paul, >Don Eastlake writes: >>DES and ROT-13 are terrible examples for you to pick. ROT-13 is a >>deliberately trivial algorithm. DES was known to be just on the verge >>of computational inadequacy from day one. These algorithms were >>doomed from the start. >> >>No forseeable amount of processor improvement or an reasonable >>projection of algorithm improvements will obsolete RSA in the next few >>decades with the key sizes provided which is all I'm willing to worry >>about. It would take a discontinuous mathematical breakthrough, which >>is certainly not impossible but, in my mind, improbable. > >I don't expect RSA to be broken anytime soon, either, BUT ----- > >The entire history of cryptography is littered with crypto algorithms >that were thought to be unbreakable until someone broke them. The ONLY >provably unbreakable algorithm is one-time pads. Everything else >is potentially breakable. So? I agreed with you that RSA might be broken. Why are you still pounding on a point where I agree with you? >I really think that no matter how secure we think RSA (or any >other algorithm) is, a communications standard should provide a >mechanism to allow a change in algorithm if the unthinkable should >actually happen. So? I agreed with you that a mechanism should be provided to "allow a change in algorithm if the unthinkable should actually happen" and will make the one minor change in the draft needed to complete this feature. Why are you still pounding on a point where I agree with you? >>While I do not believe that RSA will be broken anytime soon, I agree >>that there should be a provision for phasing over to some other >>algorithms should that prove necessary for any reason. Putting the >>flag bytes first in the signature and key RRs and having a >>must-be-zero bit to flag such a change seems adequate to me. > >A one bit flag to define an algorithm change is not adequate. >Just as for many other protocols, the right thing to do is to define >an algorithm type field and a registry of algorithms and define a >protocol negotiation over what algorithm is actually going to be used. >I have no problem with defining a default algorithm, so that negotiation >need not be done unless you actually want some other algorithm. WRONG! This is not IPSEC, where it is reasonable for different groups to be able to communicate only disjointly. This is The Domain Name Service. It is designed on the principles that all of the information in it is public, that it gives the same answers to all who query it, that there is one unified service. The DNS Security Working group, without a single objection, rejected any ideas of access control or confidentiality. And you want to have different groups unable to communicate due to different algorithms! The WG, quite reasonably, didn't want *any* increase in the number of datagram involved in queries, if possible. And you want to add cyrpto algorithm negotiation!?!? >By doing this, you also provide the mechanism so that communities of >interest who find RSA unacceptable (for whatever reason) can substitute >crypto algorithms of their own choosing. That would allow substituting >a weak algorithm for compliance with US export control or an NSA-provided >algorithm for DoD purposes or some other algorithm whose use was required >in some other country or an algorithm free of patent license restrictions, >etc. (NO - I'm not advocating CLIPPER here - only >flexibility in choice of algorithm) Give me a break with this export crap. Can you name one Internet connected country that does not have the domestic expertise to implement RSA or use anonymous ftp? And they have no patent considerations being outside the US. Weak security is usually a *bad* idea, whether for export or other reasons. It's frequently misleading and thus worse than no security. And what in the world is the use of exporting this braindamaged weak security DNS when it then couldn't interoperate with stronger hypothetically non-exported security? Or do you think we should just give up on being secure because of the short sighted US Government policies? If DoD or some other country wants something different, its a free world and they can screw themselves by cutting themselves off from the main DNS servic if they want. The patent restrictions on RSA, which I believe to be the techncially superior public key algorithm choice, seem so minor that I really don't understand what all the fuss is about. >Obviously, if different communities choose different algorithms, then >communications between those communities will fail, but that is by >their choice. If it does not interoperate with the real DNS, its not DNS. Any community that wants to can write their own informational RFC on how they are doing DNS security and, if they want too, set up their own root and do their own thing. But none on that has anything to do with the secure Internet DNS service. No all "communications" protocols are the same (actully DNS is more of a database protocol...). The right thing for DNS is that tere should be EXACTLY ONE security algorithm for The DNS for global interoperability. However, it is reasonable to make provisions for rolling over to a new algorithm eventually, should that prove necessary for any reason. Donald   Received: from sol.tis.com by magellan.TIS.COM id aa24996; 20 Apr 94 4:14 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA25583; Wed, 20 Apr 94 04:13:52 EDT Received: by relay.tis.com; id AA05810; Wed, 20 Apr 94 04:14:57 EDT Received: from munnari.oz.au(128.250.1.21) by relay via smap (V1.3mjr) id sma005802; Wed Apr 20 04:14:48 1994 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02264; Wed, 20 Apr 1994 17:03:22 +1000 (from kre@munnari.OZ.AU) To: "Donald E. Eastlake 3rd (Beast)" Cc: Masataka Ohta , dns-security@tis.com Subject: Re: SIG RR location in responses & Re: Real truncation problem In-Reply-To: Your message of "Tue, 19 Apr 1994 13:06:55 -0400." <9404191706.AA17982@skidrow.lkg.dec.com> Date: Wed, 20 Apr 1994 17:03:23 +1000 Message-Id: <14814.766825403@munnari.OZ.AU> From: Robert Elz Date: Tue, 19 Apr 94 13:06:55 -0400 From: "Donald E. Eastlake 3rd (Beast)" Message-ID: <9404191706.AA17982@skidrow.lkg.dec.com> >> What I >> meant was an A RR query to the same server where you initially found >> the NS for this lower level zone, i.e., the server where the A record >> is present as glue. Would this actually not work in current >> implementations? > >It does not work. Have you actually tried it? I was going to stay out of this, however ... In most present implementations this probably will work (ie: in BIND it works). However it probably shouldn't work. Unless a request is asking for a recursive search (RD) of a server that permits recursive queries (RA), I believe that the proper response to an A query in a zone that is (one or more levels) delegated from the current server is to return the NS records for the delegation, and in the additional info section, any extra data that may be present, appropriate, and fit (ie: generate a referral). Returning the A record, just because the current server happens to know it, or think it knows it, seems totally bogus to me, whether or not BIND (and possibly other servers) act that way now. If the reason for the A request was that a previous NS request was returned without the necessary A glue records in the additional info section, then I can't think of a single reason why an A query of the same server (unless it happens to be authoritative for the zone in question) should return anything even slightly different. kre   Received: from sol.tis.com by magellan.TIS.COM id aa24375; 19 Apr 94 23:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA20559; Tue, 19 Apr 94 22:33:05 EDT Received: by relay.tis.com; id AA03745; Tue, 19 Apr 94 22:34:09 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma003740; Tue Apr 19 22:34:05 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 20 Apr 94 11:27:56 +0859 From: Masataka Ohta Return-Path: Message-Id: <9404200228.AA05898@necom830.cc.titech.ac.jp> Subject: Re: Security AD's assesment re RSAREF licensing To: Steve Kent Date: Wed, 20 Apr 94 11:27:55 JST Cc: dns-security@tis.com In-Reply-To: <9404191340.AA24373@cc.titech.ac.jp>; from "Steve Kent" at Apr 19, 94 9:53 am X-Mailer: ELM [version 2.3 PL11] > Masataka, > > While it is true that signatures are large, the use of RSA in > the current scheme enables one to pack multiple, short data items into > a single signature block. Most of the time, the data item is small so that it is not meaningful to try to remove it. > If one were required to sign hashes, not > data items, then data items that are shorter than the hash could not > be packed in this fashion. Data shorter than hash? That is exactly the case where removal of the data (it's short) is not so meaningful. > This is the feature of the current scheme > that makes its RSA-dependent and which is clearly motivated by a > desire to optimize for space in server responses. My point is that such an optimizaiton is just an optimization at most, not an optimization most of the time and incompatible to basic architechture of name servers. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa24785; 20 Apr 94 3:35 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA25018; Wed, 20 Apr 94 03:34:39 EDT Received: by relay.tis.com; id AA05369; Wed, 20 Apr 94 03:35:44 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma005361; Wed Apr 20 03:35:25 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 20 Apr 94 16:29:12 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404200729.AA07346@necom830.cc.titech.ac.jp> Subject: Re: SIG RR location in responses & Re: Real truncation problem To: "Donald E. Eastlake 3rd" Date: Wed, 20 Apr 94 16:29:10 JST Cc: dns-security@tis.com In-Reply-To: <9404191706.AA17982@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Apr 19, 94 1:06 pm X-Mailer: ELM [version 2.3 PL11] > >It does not work. > > Have you actually tried it? Using nslookup I have no problems at all > retrieving type A glue records by doing specific queries for them. The problem is that the information returned is glue information and should not be treated otherwise. Unlike authoritative information, it should not be cached lightly. Though BIND (4.8.3, at least) is doing otherwise, it is a secutiry hole. RFC1034 says: :4.2.1. Technical considerations :To fix this problem, a zone contains "glue" RRs which are not :part of the authoritative data, and are address RRs for the servers. :These RRs are only necessary if the name server's name is "below" the :cut, and are only used as part of a referral response. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Having said all that, it is probably more "natural" for a resolver to > do additional queries for RRs of the same name, such as key or > signature RRs, and less "natural" to do a glue RR retrieval with the > appropriate different owner name. Exactly. Unlike As, SIGs shouldn't be glue and can be dropped. So, elaborated compaction is not necessary. > >What do you think "truncation problem" means, at all? > It seems to me that what problem is caused by truncation depends on > the context. In the context we are talking about, it could, for > example, be that all the name servers for a zone had names inside that > zone so you could never get to any of them unless you could get their > IP address via a type A glue record. Correct. > However, a sufficiently clever > resolver could, on noticing truncation in the additional information > section on an NS retreival, do explicit A retrieval from the server > where it got the NS's looking for glue information. I don't know if > any existing resolvers do that. The problem is that properly implemented name servers shouldn't answer such queries unless it also have (a cached copy of) authoritative information. > >> >That is: > >> > 1) Don't introduce new abbreviaiton and use the RR format > >> > currently used in the DNS packets. > >> > 2) Always use MD5 > >> > 3) Use a single record for authenticaiton, not multiple SIGs > >> > >> Re your points 1 & 2: > >> A specific requirement decided at the Houston IETF was not to > >> take significantly more queries. If you start getting lots of > >> truncation, you will start having to make twice as many queries. Many > >> people think this would be a problem. > > > >With 1 and 2, there will be no extra queries, because there won't be > >much truncations occure. > > Only statistics and/or reasonable projections are going to convince > anyone on this question. I have locally run etherfind. Most DNS replay are less then 256 bytes. > Sorry, but I don't know what you means by RSA-CBC. And the kinds of > things "RSA-CBC" suggest to me don't seem like they would be useful in > the DNS case. Please give a more detailed explatation. As you should know, block encryption for long text is done block by block. That's all. I'm not interested in the detail of whether it is by EBC or CBC (Cipher Block Chaining). > According to later posts by Paul Vixie, at least BIND clears all these > bits in queries it sends so it would not have problems with an initial > resolver set SD bit. What? He wrote: >Moreover, aren't the current name servers copying the unused bits >of query packets? yes. and later > (hint: many of the forwarders that are "blindly copying bits" are going to > keep doing that, and we need to design any/all protocol enhancements with > that thought clearly in our minds.) > >My opinion is that with usual circumstance, your optimization is > >ineffective and, thus, should be removed. > > Why are the optimizations in our scheme "ineffective"? Ineffective? No, it's often worse than compressed domain names. > >Under the general Internet principle of being conservative in what you > >send, security aware servers should always ADD the RR in replies, which > >is what current DNS is doing. > > I guess what is conservative and what is liberal is in the eye of the > beholder. Wrong. You just misunderstand conservative behaviour of SD bit copying. > >Your proposal to try to handle partial RRs makes many assumptions, > >such as caching behaviour, of the current implementaiton of DNS. > > ? There aren't any "partial RRs" in our proposal. Perhaps you mean > the partial RR signet? No. I mean partial set of SIG RRs. See section 7.4 of RFC1035. > ? The various signature encoding means in our proposal provide many > ways to get the maximum benefit from each signature RR. I don't see > why you say they will increase the packet size. Lack of domain name compression. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa24964; 20 Apr 94 4:03 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA25446; Wed, 20 Apr 94 04:02:48 EDT Received: by relay.tis.com; id AA05605; Wed, 20 Apr 94 04:03:53 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma005597; Wed Apr 20 04:03:19 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 20 Apr 94 16:57:26 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404200757.AA07527@necom830.cc.titech.ac.jp> Subject: Re: DNS security draft To: "Donald E. Eastlake 3rd" Date: Wed, 20 Apr 94 16:57:24 JST Cc: dns-security@tis.com In-Reply-To: <9404191928.AA19319@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Apr 19, 94 3:28 pm X-Mailer: ELM [version 2.3 PL11] > >But I think updating of root keys is only as difficut as updating of > >root name servers and should be done anyway. > > Yes, the root zone key should be updated occasionally. The draft > recommends chainging zone keys annually. Hmmm, I think it is bad to specify the period of time to update keys in the draft. It is an operational issue to be determinded elsewhere. > My point was that if there > are 1,000,000 stub resolvers out there, having them all start only > knowing the root zone key is a *bad* idea. What? Stub resolvers knows friendly recursive name servers (by thier addresses and, optionaly, host keys (not zone keys)) only. > > > > A C > > / \ / \ > > / \ / \ > > / \ / \ > > B / \ / \ > > / \ / \ > > / \ > > / > > pointer to C > >So, how can a resolver on host H traverse DNS tree to know C is secure? > The only way around this is for the pointer to C in zone B to be > accompanied by an RSA RR for zone C. Since zone B is secure, this RSA > RR will be signed. Since zone A was secure, the key for zone B was > signed by A along with the NS RRs for B in A. So host H can trust > zone C. Things does not work in such a way. As H serves zone A only, not zone B, it can't traverse the secure pointers from zone A through B to zone C. H won't perform exhaustive search of secure zones to know whether C is reachable or not. Note that the pointer to C in Zone B is not authoritative to B. It seems to me that you, again, don't understand what authoritativeness implies. > This was the question that Jeff Schiller was asking at the DNS SEC WG > meeting in Seattle. I remembeer. I now think that is the real problem. > >In general, I think resolvers can't be sure that a zone is secure > >unless it knows key of its ancestor zone in advance. > > That's easier but there is nothing to stop horizontal signing of keys > between arbitrary parts of the DNS tree. Why, do you think, the current DNS is designed NOT to horizontaly travers name servers? There ARE reasons. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa29452; 20 Apr 94 12:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA09588; Wed, 20 Apr 94 11:29:33 EDT Received: by relay.tis.com; id AA09116; Wed, 20 Apr 94 11:30:39 EDT Received: from fnal.fnal.gov(131.225.9.1) by relay via smap (V1.3mjr) id sma009111; Wed Apr 20 11:30:14 1994 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HBE85DK1O0000ZNO@FNAL.FNAL.GOV>; Wed, 20 Apr 1994 10:29:31 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1) id AA09926; Wed, 20 Apr 94 10:28:46 CDT Date: Wed, 20 Apr 1994 10:28:45 -0500 From: Matt Crawford Subject: Re: DNS security draft In-Reply-To: Your message of Wed, 20 Apr 94 16:57:24 +0200. <9404200757.AA07527@necom830.cc.titech.ac.jp> To: dns-security@tis.com Cc: Masataka Ohta , "Donald E. Eastlake 3rd" Message-Id: <9404201528.AA09926@munin.fnal.gov> Content-Transfer-Encoding: 7BIT What it boils down to seems to be this. Any resolver or server which preserves the distinction between authoritative and non-authoritative (example: glue) data better than BIND does will break the proposed scheme of cross-authentication of zones. What other ways are there for a client to start with one trusted zone A (a zone whose public it believes it knows) and find the public key of another zone B, or learn that B is not secured? In the most general case, A's zone administrator will not have signed B's key. If there isn't a chain of certificates for parent zones of A all the way up to a common ancestor C of A and B, and a then chain of certificates for subzones from C down to B, then I don't see any deterministic way to get trusted information about B by mechanisms stridtly within DNS. What about putting certificates of arbitrary other zones within zone A's authoritative namespace? This could be done with or without a special name in the zone, in order to place certificates at a known point, such as B.certificates.A (example: es.net.certificate.fnal.gov). We don't have special names now, and I don't suppose anyone is keen to introduce them. Without a special name, all certificates would have to be stored at the top of a zone, and include information within the RDATA. The client could only ask for all certificates at once, and should expect to need a TCP connection to get them. The RSA RDATA format described in the draft has no room for the name of the owner of the key, so I propose a third RR type: the CERT, or "certificate" RR. The RDATA field of a CERT RR would contain a (as defined in RFC 1035) and all the fields of the RSA RDATA. Needless to say, a CERT not covered by a SIG record MUST be discarded. Because of the similarity between the RSA and the CERT RR, an alternative is to add a usually-redundant to the RSA RDATA. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab   Received: from sol.tis.com by magellan.TIS.COM id aa00965; 20 Apr 94 17:48 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA03406; Wed, 20 Apr 94 17:47:49 EDT Received: by relay.tis.com; id AA13002; Wed, 20 Apr 94 17:48:55 EDT Received: from gw.home.vix.com(192.5.5.1) by relay via smap (V1.3mjr) id sma012995; Wed Apr 20 17:47:54 1994 Received: by gw.home.vix.com id AA02559; Wed, 20 Apr 94 14:47:21 -0700 Date: Wed, 20 Apr 94 14:47:21 -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: DNS security draft Organization: Vixie Enterprises Message-Id: References: <9404201528.AA09926@munin.fnal.gov> Nntp-Posting-Host: office.home.vix.com In-Reply-To: crawdad@munin.fnal.gov's message of 20 Apr 1994 10:03:42 -0700 >What it boils down to seems to be this. Any resolver or server which >preserves the distinction between authoritative and non-authoritative >(example: glue) data better than BIND does will break the proposed >scheme of cross-authentication of zones. > >[...] BIND as of 4.9 preserves the distinction between authoritative and nonauthoritative data; a future (post-4.9.3) version will probably answer with a NOERROR/referral if a query arrives without RD for a name with non-authoritative matching RR's. as of 4.9 we are already deleting all previous data in a node when more-authoritative info comes in. credibility levels are, in increasing order: additional or authority data nonauthoritative answer authoritative answer authoritative local zone (pri or sec) more details wouldn't be relevant to this thread. i just wanted to keep everybody from believing the BIND is still as brain-dead as it used to be. -- Paul Vixie Redwood City, CA decwrl!vixie!paul   Received: from sol.tis.com by magellan.TIS.COM id aa01808; 21 Apr 94 3:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA14066; Thu, 21 Apr 94 03:22:06 EDT Received: by relay.tis.com; id AA16564; Thu, 21 Apr 94 03:23:12 EDT Received: from munnari.oz.au(128.250.1.21) by relay via smap (V1.3mjr) id sma016558; Thu Apr 21 03:22:56 1994 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28124; Thu, 21 Apr 1994 17:20:27 +1000 (from kre@munnari.OZ.AU) To: Masataka Ohta Cc: Paul A Vixie , dns-security@tis.com Subject: Re: DNS security draft In-Reply-To: Your message of "Thu, 21 Apr 1994 15:23:54 +0200." <9404210624.AA13149@necom830.cc.titech.ac.jp> Date: Thu, 21 Apr 1994 17:20:21 +1000 Message-Id: <14973.766912821@munnari.OZ.AU> From: Robert Elz Date: Thu, 21 Apr 94 15:23:54 JST From: Masataka Ohta Message-ID: <9404210624.AA13149@necom830.cc.titech.ac.jp> That's not enough. For a little more secure DNS, if RD is on, the server should perform recursive search even if it has glue data. My preference would be for glue A's to be treated just like the root server hints, and for the server to query the appropriate servers soon after it starts and replace the glue with answers from the authoritative servers, and then refresh that as the TTL requires (I'd probably start a refresh at about half TTL expired - except for TTL's that are absurdly small, in which case I'd probably just refresh at some moderate period). Given that, the recursive search has already been performed, and the glue can be returned like any other cached answer. It would slow the DNS system absurdly if we required that cached answers never be used to reply to queries. Still, other additional information such as A for MX is a security hole, I'm afraid. I'm not sure I believe that. Or, not any more than any other non security aware DNS lookup is a security hole. If I trust a DNS server enough to tell me the name of the host to which I should send mail for some domain, then I think I will also trust it enough to tell me the associated address. If that server is in untrustworthy hands, then anything goes anyway (the MX name value isn't worth anything), if on the other hand it can be fooled into believing an invalid address, then I see no reason that any other server can't be fooled the same way. ie: I see nothing inherantly wrong in believing the A record that may be in additional info with an MX answer. kre   Received: from sol.tis.com by magellan.TIS.COM id aa01692; 21 Apr 94 2:30 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13094; Thu, 21 Apr 94 02:29:54 EDT Received: by relay.tis.com; id AA16260; Thu, 21 Apr 94 02:30:59 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma016254; Thu Apr 21 02:30:20 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 21 Apr 94 15:23:56 +0859 From: Masataka Ohta Return-Path: Message-Id: <9404210624.AA13149@necom830.cc.titech.ac.jp> Subject: Re: DNS security draft To: Paul A Vixie Date: Thu, 21 Apr 94 15:23:54 JST Cc: dns-security@tis.com In-Reply-To: ; from "Paul A Vixie" at Apr 20, 94 2:47 pm X-Mailer: ELM [version 2.3 PL11] > BIND as of 4.9 preserves the distinction between authoritative and > nonauthoritative data; a future (post-4.9.3) version will probably answer > with a NOERROR/referral if a query arrives without RD for a name with > non-authoritative matching RR's. That's not enough. For a little more secure DNS, if RD is on, the server should perform recursive search even if it has glue data. Still, other additional information such as A for MX is a security hole, I'm afraid. > more details wouldn't be relevant to this thread. i just wanted to keep > everybody from believing the BIND is still as brain-dead as it used to be. So, in general, DNS, not specifically BIND, is unsecure. That's why secure DNS is necessary. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa04243; 21 Apr 94 9:55 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA24975; Thu, 21 Apr 94 09:55:16 EDT Received: by relay.tis.com; id AA18963; Thu, 21 Apr 94 09:56:23 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma018951; Thu Apr 21 09:55:25 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA03281; Thu, 21 Apr 94 06:46:35 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA08028; Thu, 21 Apr 1994 09:48:17 -0400 Message-Id: <9404211348.AA08028@skidrow.lkg.dec.com> To: Matt Crawford , Robert Elz Cc: dns-security@tis.com Subject: Re: DNS security draft In-Reply-To: Your message of "Wed, 20 Apr 94 10:28:45 CDT." <9404201528.AA09926@munin.fnal.gov> Date: Thu, 21 Apr 94 09:48:16 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Matt, From: Matt Crawford In-Reply-To: Your message of Wed, 20 Apr 94 16:57:24 +0200. <9404200757.AA07527@necom830.cc.titech.ac.jp> To: dns-security@tis.com >What it boils down to seems to be this. Any resolver or server which >preserves the distinction between authoritative and non-authoritative >(example: glue) data better than BIND does will break the proposed >scheme of cross-authentication of zones. I believe I understand this issue much better now. >What other ways are there for a client to start with one trusted zone >A (a zone whose public it believes it knows) and find the public key >of another zone B, or learn that B is not secured? > >In the most general case, A's zone administrator will not have signed >B's key. If there isn't a chain of certificates for parent zones of >A all the way up to a common ancestor C of A and B, and a then chain of >certificates for subzones from C down to B, then I don't see any >deterministic way to get trusted information about B by mechanisms >strictly within DNS. > >What about putting certificates of arbitrary other zones within zone >A's authoritative namespace? This could be done with or without a >special name in the zone, in order to place certificates at a known >point, such as B.certificates.A (example: es.net.certificate.fnal.gov). >We don't have special names now, and I don't suppose anyone is keen to >introduce them. In the proposed dns security scheme, a certificate is just a signed key RR. Special names seem kind of kludgy... >Without a special name, all certificates would have to be stored at the >top of a zone, and include information within the RDATA. The client >could only ask for all certificates at once, and should expect to need >a TCP connection to get them. The RSA RDATA format described in the >draft has no room for the name of the owner of the key, so I propose a >third RR type: the CERT, or "certificate" RR. The RDATA field of a >CERT RR would contain a (as defined in RFC 1035) and all >the fields of the RSA RDATA. Needless to say, a CERT not covered by a >SIG record MUST be discarded. If a key for anther zone is present for some particular reason, such as an NS for a subzone or because of an MX, PTR, CNAME, or whatever, then the key RR should have the same owner name. It would usually be retrieved as additional info if you have a security aware resolver and server. This doesn't have anything to do with finding the zone where, say, the CNAME is. It just means that if you find it via non-secure intervening zones, you will have a trusted key that you can use to validate it. If you find it via secure intervening zones, you could end up with another trusted key which is probably more recent but you can trust the results if they are signed either key. However, in the general case, you can just store some other zone keys under the zone name. For a secure zone, its own key and the superzone key would normally occur at the zone name node anyway. (You need the superzone to be able to climb the tree and its a good idea to have its own key so that even if you get to the zone insecurely, you can at least do internal signature verification in the zone.) The only problem with this is that if enough keys were there that they overflowed the UDP limit then, as you say, you would need to use TCP. I tend to think of the superzone key as the most important so perhaps the spec should require that it be returned first so you could always get it with UDP even if other keys were lost to truncation... I don't know how much cross certfication like this is going to occur but, if you are willing to use TCP, there is no particular reason you couldn't have hundreds of keys for miscellaneous zones stored in and vouched for by your trusted local zone. >Because of the similarity between the RSA and the CERT RR, an >alternative is to add a usually-redundant to the RSA >RDATA. This is the first thing that occurred to me. Unless people object, I'll change the key RR in the next draft to have the object name that the key is associated with explicit rather than being the RR owner name. In the common case where they are the same, this will cost only one byte with DNS name compression. >_________________________________________________________ >Matt Crawford crawdad@fnal.gov Fermilab All this means that a secure DNS implementation will have to be able to find keys based on the domain name of the object the key is associated with, not just the owner name of the key RR. Donald To: Robert Elz cc: dns-security@tis.com Subject: Re: SIG RR location in responses & Re: Real truncation problem In-reply-to: Your message of "Wed, 20 Apr 94 17:03:23 +1000." <14814.766825403@munnari.OZ.AU> -------- Robert, Thanks for your clear and detailed response. From: Robert Elz To: "Donald E. Eastlake 3rd (Beast)" Cc: Masataka Ohta , dns-security@tis.com In-Reply-To: Your message of "Tue, 19 Apr 1994 13:06:55 -0400." <9404191706.AA17982@skidrow.lkg.dec.com> > Date: Tue, 19 Apr 94 13:06:55 -0400 > From: "Donald E. Eastlake 3rd (Beast)" > Message-ID: <9404191706.AA17982@skidrow.lkg.dec.com> > > >> What I > >> meant was an A RR query to the same server where you initially found > >> the NS for this lower level zone, i.e., the server where the A record > >> is present as glue. Would this actually not work in current > >> implementations? > > > >It does not work. > > Have you actually tried it? > >I was going to stay out of this, however ... In most present >implementations this probably will work (ie: in BIND it works). > >However it probably shouldn't work. Unless a request is asking >for a recursive search (RD) of a server that permits recursive >queries (RA), I believe that the proper response to an A >query in a zone that is (one or more levels) delegated from the >current server is to return the NS records for the delegation, >and in the additional info section, any extra data that may be >present, appropriate, and fit (ie: generate a referral). Minor comment: It seems to me that even currently required glue records need not be to an inferior zone. I'm not sure if such cases occur but you could have zone A serverd by host A and zone X served by host X and then have B.A served by Y.X and Y.X served by B.A (or equivalent more realistic and complicated cases). In this case zone A must have glue to Y.X and zone X must have glue to B.A or you aren't going to get very far. >Returning the A record, just because the current server happens >to know it, or think it knows it, seems totally bogus to me, >whether or not BIND (and possibly other servers) act that way >now. > >If the reason for the A request was that a previous NS request >was returned without the necessary A glue records in the >additional info section, then I can't think of a single reason >why an A query of the same server (unless it happens to be >authoritative for the zone in question) should return anything >even slightly different. > >kre Donald   Received: from sol.tis.com by magellan.TIS.COM id aa04477; 21 Apr 94 11:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA28596; Thu, 21 Apr 94 10:48:43 EDT Received: by relay.tis.com; id AA19543; Thu, 21 Apr 94 10:49:49 EDT Received: from ns.gte.com(132.197.8.9) by relay via smap (V1.3mjr) id sma019538; Thu Apr 21 10:49:02 1994 Received: from bunny.gte.com by ns.gte.com (5.65c/IDA-1.4.4) id AA22503; Thu, 21 Apr 1994 10:47:09 -0400 Received: from pkarger by bunny.gte.com (5.61/GTEL2.19) id AA11781; Thu, 21 Apr 94 10:44:51 -0400 Received: from localhost by pkarger.tcc (4.1/SMI-4.1) id AA17525; Thu, 21 Apr 94 10:46:28 EDT Message-Id: <9404211446.AA17525@pkarger.tcc> To: "Donald E. Eastlake 3rd (Beast)" Cc: pkarger@gte.com, dns-security@tis.com Reply-To: pkarger@gte.com Phone: +1 (617) 466-3844 Fax: +1 (617) 890-9320 Organization: GTE Laboratories Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of "Wed, 20 Apr 94 00:08:17 EDT." <9404200408.AA23362@skidrow.lkg.dec.com> Date: Thu, 21 Apr 94 10:46:22 -0400 From: "Paul A. Karger" I'm sorry that you found my suggestion of supporting multiple crypto algorithms so controversial or that you thought I was "pounding on a point". I was only trying to make what I thought was a mild and non-controversial suggestion that mandating a particular algorithm is not necessarily the best approach, even for a public directory service, such as DNS. If my messages came across otherwise, then I apologize for causing a problem. Multiple algorithm support provides a number of features, some of which may be of value to DNS and some of which may only be "nice to haves" or may be irrelevant to DNS. The remainder of this message will try to summarize what these features are in as non-controversial a way as I can manage. I will repeat some thoughts from my previous message, not to "pound a point", but to put all the thoughts together in one place for easy reading. I am not an advocate of the current export control laws in the US, nor of the CLIPPER proposals. However, it is reality that not all countries will accept the use of the same cryptographic algorithms either in their own countries or for export to other countries. While those attitudes are regrettable, they are also reality. Supporting multiple algorithms can make life under some of these irrational export and use rules easier. Some algorithms are subject to patent and licensing restrictions. Supporting multiple algorithms can make it possible for selected communities to choose not to pay license fees if they don't want to. I don't personally consider this a major problem, but some members of the Internet community get very upset at the thought of paying royalties on the RSA patent. Supporting multiple algorithms might make it easier to adopt RSA as the preferred algorithm, if those who don't wish to pay royalties have a way to avoid them. If DNS security is for one and only one DNS for one and only one true Internet, then one algorithm is sufficient. On the other hand, if the DNS protocols are to be useful in a broader environment where one community may wish to establish a second network that uses the same protocols but has only limited connections to the one true Internet, then there might be value for multiple algorithms. However, this is not a big issue, and if the DNS community has decided that this is not a feature of sufficient value (as your message indicates), then this benefit may be totally irrelevant to DNS. Cryptographic algorithms (other than one-time pads) do get broken periodically. Allowing for replacing an algorithm that proves too weak is a good thing. Allowing for replacing the replacement algorithm is also a good thing, because the replacement might also be broken. This implies that a single bit indicating old or new algorithm is not sufficient. Instead, some kind of algorithm version number is preferable. Finally, negotiating crypto algorithms adds overhead to a communications protocol. If we believe that the vast majority of users will in fact use a single algorithm that we don't expect to be broken any time soon, then algorithm negotiation should be designed to not add extra messages in the case of the default algorithm. This can be achieved by the client and server both assuming the default, unless one or the other sends a special message requesting something else. In conclusion, I hope my suggestions are useful to the DNS security WG. I am not an active participant in the WG, and I only wanted to offer what might be useful ideas. If they are not relevant or useful, then feel free to throw them away. If they are partially useful, then feel free to take those parts that are useful and ignore the rest. I am NOT trying to start a flame war or a major controversy! - Paul   Received: from sol.tis.com by magellan.TIS.COM id aa05028; 21 Apr 94 14:12 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA17647; Thu, 21 Apr 94 14:12:19 EDT Received: by relay.tis.com; id AA21599; Thu, 21 Apr 94 14:13:26 EDT Message-Id: <9404211813.AA21599@relay.tis.com> Received: from labs-n.bbn.com(128.89.0.100) by relay via smap (V1.3mjr) id sma021594; Thu Apr 21 14:13:13 1994 To: pkarger@gte.com Cc: dns-security@tis.com Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of Thu, 21 Apr 94 10:46:22 -0400. <9404211446.AA17525@pkarger.tcc> Date: Thu, 21 Apr 94 14:11:13 -0400 From: Steve Kent Paul, I think your message does a good job of explaining your concerns for algorithm independence in the DNS context. There may be some others as well. Some organizations operate closed internets (with reused IP net numbers) and may employ closed DNS systems. Such organizations might wish to adopt a crypto-secure form of DNS, but might have reasons for using an algorithm other than the one widely used in the open Internet. It is not inconcievable that the DNS could be configured to support multiple algorithms, though at the cost of added management complexity and extra space. Multiple records carrying signatues and keys for use with different algorithms could be established. Given the DNS capability to add new record types, to configure multiple aliases, to introduce new domains for wholly new applications (e.g., the Internet fax facility), the addition of more records does not seem out of character. Some people have argued for the ability to accommodate multiple signature algorithms in certification systems and it is concievable to do this, though it raises the spectre of non-interoperability among portions of the system, e.g., should the signature algorithms used in some areas not be available to users in others. The same could be true here, e.g., non-interoperability across zone boundaries. The possibility of non-interoperability is certainly a concern. However, given a laize fare approach this proposal alreday embodies, enabling arbitrary cross-certification in the name hierarchy, it's not clear that accommodating multiple algorithms would be inconsistent with the overall flavor of the proposal. Steve   Received: from sol.tis.com by magellan.TIS.COM id aa05673; 21 Apr 94 15:26 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA29373; Thu, 21 Apr 94 15:26:06 EDT Received: by relay.tis.com; id AA22508; Thu, 21 Apr 94 15:27:12 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma022500; Thu Apr 21 15:26:44 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA23491; Thu, 21 Apr 94 12:16:13 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA11256; Thu, 21 Apr 1994 15:17:54 -0400 Message-Id: <9404211917.AA11256@skidrow.lkg.dec.com> To: dns-security@tis.com Cc: dee@lkg.dec.com, Charlie Kaufman Subject: no key flag and improved hash Changes Date: Thu, 21 Apr 94 15:17:53 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Unless there is substantial of opposition, we would like to make two additional changes in the next draft, one very simple and one more subtle: No key flag: The current draft says that an RSA RR with a modulus length of zero specifically asserts the absence of a key. This will be changed to a "no key" bit in the flag byte. Since the next version will have some sort of algorithm version field, it will in any case be necessary to look at the initial fixed part of the RDATA before looking at anything else in a key RR as, with some other algorithm, their might not be a "modulus length" field at all. Improved hash: The hash codes used inside signatures will be made stronger by having them change more often. This gives adversaries less time to find a false hash match by brute force. This will be accomplished by including the "self hash" field as part of the data hashed into all other hashes inside the signature. Since the self hash includes the date signed, all hashes will change with the frequency with which the zone is re-signed. Assuming their might otherwise have been hashes of RR sets that could have been unchanging for 10 years and that a zone is signed daily, this reduces the time an adversary has to find a false hash match by three and half orders of magnitude. (The attack being defended against is one where, for example, there is a set of MX RRs under a name which are signed by a hash inside the signature. If an adversary can find another set of MXs that hash to the same value and the have the adversary's host as the highest priority reachable MX destination and can substitute these RRs, along with the original genuine signature, in a DNS response, they can steal your mail.) Donald --------------------------------------------------------------------------- Donald E. Eastlake, III DTN: 226-6577(w) dee@lkg.dec.com 550 King St, LKG2-1/BB3 1-508-486-6577(w) dee@ranger.enet.dec.com Littleton, MA 01460 USA 1-508-486-7417(fax) 1-508-287-4877(h)   Received: from sol.tis.com by magellan.TIS.COM id aa07188; 22 Apr 94 0:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA26067; Thu, 21 Apr 94 23:58:22 EDT Received: by relay.tis.com; id AA26492; Thu, 21 Apr 94 23:59:30 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma026487; Thu Apr 21 23:58:46 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 22 Apr 94 12:52:18 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404220352.AA18149@necom830.cc.titech.ac.jp> Subject: Re: DNS security draft To: Robert Elz Date: Fri, 22 Apr 94 12:52:16 JST Cc: paul@vix.com, dns-security@tis.com In-Reply-To: <14973.766912821@munnari.OZ.AU>; from "Robert Elz" at Apr 21, 94 5:20 pm X-Mailer: ELM [version 2.3 PL11] > Given that, the recursive search has already been performed, and > the glue can be returned like any other cached answer. It > would slow the DNS system absurdly if we required that cached > answers never be used to reply to queries. > > Still, other additional information such as A for MX is a security hole, > I'm afraid. > > I'm not sure I believe that. Or, not any more than any other > non security aware DNS lookup is a security hole. If I trust > a DNS server enough to tell me the name of the host to which I > should send mail for some domain, then I think I will also trust > it enough to tell me the associated address. You can believe DNS servers provide correct information of the zone it serves. The problem is that a DNS server can put false information for other zones in the addtional section. foo.bar. MX 10 mail.foo.bar. MX 100 your.host. foo.bar A your.host A To make DNS as secure as IP, information in the additional section may be cached and copied to additional sections of other answers but should never be copied to the answer section, unless it belongs to the same domain to the answer. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa09239; 22 Apr 94 9:27 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA18267; Fri, 22 Apr 94 09:27:15 EDT Received: by relay.tis.com; id AA29832; Fri, 22 Apr 94 09:28:23 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma029821; Fri Apr 22 09:27:48 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA16625; Fri, 22 Apr 94 06:20:34 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA17466; Fri, 22 Apr 1994 09:22:17 -0400 Message-Id: <9404221322.AA17466@skidrow.lkg.dec.com> To: Masataka Ohta Cc: dns-security@tis.com Subject: Re: DNS security draft In-Reply-To: Your message of "Fri, 22 Apr 94 20:51:01 +0200." <9404221151.AA20068@necom830.cc.titech.ac.jp> Date: Fri, 22 Apr 94 09:22:17 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: Masataka Ohta To: Matt Crawford Cc: dns-security@tis.com, dee In-Reply-To: <9404201528.AA09926@munin.fnal.gov>; from "Matt Crawford" at Apr 20, 94 10:28 am >> Without a special name, all certificates would have to be stored at the >> top of a zone, and include information within the RDATA. > >It's too much inelegant. Such information should properly be included >in "named.boot" of BIND and should carefully maintained. To be really secure you need at least one key in the boot file of each host running secure DNS. The current proposal allows putting however may trusted keys you want there. But it seems to me that there would be cases where putting cross certification keys in a zone and maintaining them just in the zone master file would be easier than maintaining these keys in many boot files. This would not eliminate the need to have at least one key in every boot file. >Why, do you think, current DNS does not have list of name servers of >all the related zones at the top of a zone? Because it will create >a total chaos. > >What, do you think, will happen, when a key of some zone is changed? How >can a zone administrator know from which zones his zone is pointed by? > >What happens when a key of root or near root zone is changed to which >a lot of zones point? You do an excellent job of pointing out operational problems with keeping cross certification pointers up to date. It's much easier to avoid them and use the hierarchy if you can. However, being able to do such cross certification was specified as a requirement by the DNSSEC WG. Such cross certification is necessary to do secure resolution if any zones on the hierarchy path from where you start to the zone holding the node you are seeking are either insecure or all their servers are inaccessible to you. > Masataka Ohta Donald   Received: from sol.tis.com by magellan.TIS.COM id aa07650; 22 Apr 94 4:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA00195; Fri, 22 Apr 94 03:50:31 EDT Received: by relay.tis.com; id AA27721; Fri, 22 Apr 94 03:51:39 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma027716; Fri Apr 22 03:51:33 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 22 Apr 94 16:44:19 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404220744.AA19145@necom830.cc.titech.ac.jp> Subject: Re: Security AD's assesment re RSAREF licensing To: "Donald E. Eastlake 3rd" Date: Fri, 22 Apr 94 16:44:17 JST Cc: pkarger@gte.com, dns-security@tis.com In-Reply-To: <9404200408.AA23362@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Apr 20, 94 12:08 am X-Mailer: ELM [version 2.3 PL11] > >A one bit flag to define an algorithm change is not adequate. > >Just as for many other protocols, the right thing to do is to define > >an algorithm type field and a registry of algorithms and define a > >protocol negotiation over what algorithm is actually going to be used. > >I have no problem with defining a default algorithm, so that negotiation > >need not be done unless you actually want some other algorithm. > > WRONG! This is not IPSEC, where it is reasonable for different groups > to be able to communicate only disjointly. This is The Domain Name > Service. It is designed on the principles that all of the information > in it is public, that it gives the same answers to all who query it, > that there is one unified service. Having multiple authentication mechanism will make DNS a little more complex. As the mechanism would be cleanly modularized, it is not so complex. Moreover, even if authentication fails, raw data is still available. That all. > The DNS Security Working group, without a single objection, rejected > any ideas of access control or confidentiality. On the other hand, with your scheme with RSA which contains raw data, access restriction is possible by restricting the distribution of the public keys. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa11584; 22 Apr 94 11:18 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA27362; Fri, 22 Apr 94 11:17:48 EDT Received: by relay.tis.com; id AA01512; Fri, 22 Apr 94 11:18:55 EDT Received: from fnal.fnal.gov(131.225.9.1) by relay via smap (V1.3mjr) id sma001501; Fri Apr 22 11:18:33 1994 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HBH0BIQ8IO001OI4@FNAL.FNAL.GOV>; Fri, 22 Apr 1994 10:17:44 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1) id AA14817; Fri, 22 Apr 94 10:17:00 CDT Date: Fri, 22 Apr 1994 10:17:00 -0500 From: Matt Crawford Subject: Re: DNS security draft In-Reply-To: Your message of Fri, 22 Apr 94 20:51:01 +0200. <9404221151.AA20068@necom830.cc.titech.ac.jp> To: Masataka Ohta Cc: dns-security@tis.com, dee@skidrow.lkg.dec.com Message-Id: <9404221517.AA14817@munin.fnal.gov> Content-Transfer-Encoding: 7BIT > > Without a special name, all certificates would have to be stored at the > > top of a zone, and include information within the RDATA. > It's too much inelegant. Such information should properly be included > in "named.boot" of BIND and should carefully maintained. I don't see any difference in elegance. I see a difference in convenience, since I rarely touch named.boot. And named.boot does not now contain any RRs at all. Might you have meant the initial cache file? > What, do you think, will happen, when a key of some zone is changed? How > can a zone administrator know from which zones his zone is pointed by? He can't know. But he can do one of two things to ease the transition when he changes keys: Sign his zone with both the old and new keys or (better) Sign his new key with his old key. Thus zones primed with his old key can securely learn the new. > What happens when a key of root or near root zone is changed to which > a lot of zones point? Same as above, for a transitional period. DNS administrators will no doubt run a tool that looks for changes in keys for zones whose keys they have previously certified. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab   Received: from sol.tis.com by magellan.TIS.COM id aa12130; 22 Apr 94 12:08 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA01399; Fri, 22 Apr 94 12:08:16 EDT Received: by relay.tis.com; id AA02162; Fri, 22 Apr 94 12:09:24 EDT Received: from fnal.fnal.gov(131.225.9.1) by relay via smap (V1.3mjr) id sma002157; Fri Apr 22 12:09:22 1994 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HBH23JS14W001PF4@FNAL.FNAL.GOV>; Fri, 22 Apr 1994 11:08:33 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1) id AA15071; Fri, 22 Apr 94 11:07:51 CDT Date: Fri, 22 Apr 1994 11:07:50 -0500 From: Matt Crawford Subject: Re: Authenticated NXDOMAIN response In-Reply-To: Your message of Fri, 22 Apr 94 21:44:55 +0200. <9404221245.AA20257@necom830.cc.titech.ac.jp> To: Masataka Ohta Cc: dns-security@tis.com Message-Id: <9404221607.AA15071@munin.fnal.gov> Content-Transfer-Encoding: 7BIT > If a list of all the names in a zone is available, authenticated NXDOMAIN > is easy. But it is unrealistic to extract such lengthy information. > > So, how is the following idea to make NXDOMAIN response authenticated? > > Have the following new RR type: XD (eXisting Domains) > > XD ... Why isn't the carried in a separate SIG RR, as for other RRs?   Received: from sol.tis.com by magellan.TIS.COM id aa08165; 22 Apr 94 8:03 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA04659; Fri, 22 Apr 94 08:02:38 EDT Received: by relay.tis.com; id AA29084; Fri, 22 Apr 94 08:03:46 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma029048; Fri Apr 22 08:03:05 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 22 Apr 94 20:51:03 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404221151.AA20068@necom830.cc.titech.ac.jp> Subject: Re: DNS security draft To: Matt Crawford Date: Fri, 22 Apr 94 20:51:01 JST Cc: dns-security@tis.com, dee@skidrow.lkg.dec.com In-Reply-To: <9404201528.AA09926@munin.fnal.gov>; from "Matt Crawford" at Apr 20, 94 10:28 am X-Mailer: ELM [version 2.3 PL11] > Without a special name, all certificates would have to be stored at the > top of a zone, and include information within the RDATA. It's too much inelegant. Such information should properly be included in "named.boot" of BIND and should carefully maintained. Why, do you think, current DNS does not have list of name servers of all the related zones at the top of a zone? Because it will create a total chaos. What, do you think, will happen, when a key of some zone is changed? How can a zone administrator know from which zones his zone is pointed by? What happens when a key of root or near root zone is changed to which a lot of zones point? Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa08179; 22 Apr 94 8:12 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA06025; Fri, 22 Apr 94 08:11:44 EDT Received: by relay.tis.com; id AA29147; Fri, 22 Apr 94 08:12:51 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma029139; Fri Apr 22 08:12:46 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 22 Apr 94 21:06:19 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404221206.AA20138@necom830.cc.titech.ac.jp> Subject: Re: no key flag and improved hash Changes To: "Donald E. Eastlake 3rd" Date: Fri, 22 Apr 94 21:06:18 JST Cc: dns-security@tis.com, dee@lkg.dec.com, kaufman@zk3.dec.com In-Reply-To: <9404211917.AA11256@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Apr 21, 94 3:17 pm X-Mailer: ELM [version 2.3 PL11] > Unless there is substantial of opposition, we would like to make two > additional changes in the next draft, one very simple and one more > subtle: As I'm tired of correcting your misunderstandings, I would like to write another draft which is fanatically royal to the existing DNS architechture. As a result, it will be simpler than yours and proved to work in the real world environment. Any objections? Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa13055; 22 Apr 94 15:08 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13339; Fri, 22 Apr 94 15:07:46 EDT Received: by relay.tis.com; id AA03706; Fri, 22 Apr 94 15:08:55 EDT Received: from fnal.fnal.gov(131.225.9.1) by relay via smap (V1.3mjr) id sma003697; Fri Apr 22 15:08:04 1994 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HBH8CA91JK001OX2@FNAL.FNAL.GOV>; Fri, 22 Apr 1994 14:07:24 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1) id AA15421; Fri, 22 Apr 94 14:06:42 CDT Date: Fri, 22 Apr 1994 14:06:42 -0500 From: Matt Crawford Subject: Re: Authenticated NXDOMAIN response In-Reply-To: Your message of Fri, 22 Apr 94 11:07:50 CDT. <9404221607.AA15071@munin.fnal.gov> To: Masataka Ohta Cc: dns-security@tis.com Message-Id: <9404221906.AA15421@munin.fnal.gov> Content-Transfer-Encoding: 7BIT (I should finish thinking before I send ...) > > Have the following new RR type: XD (eXisting Domains) > > > > XD ... > > Why isn't the carried in a separate SIG RR, as for other RRs? Also, you need the SIG record's "time signed", or something equivalent, to prevent replays. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab   Received: from sol.tis.com by magellan.TIS.COM id aa09074; 22 Apr 94 9:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA11923; Fri, 22 Apr 94 08:49:59 EDT Received: by relay.tis.com; id AA29535; Fri, 22 Apr 94 08:51:06 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma029527; Fri Apr 22 08:50:37 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 22 Apr 94 21:44:57 +0859 From: Masataka Ohta Return-Path: Message-Id: <9404221245.AA20257@necom830.cc.titech.ac.jp> Subject: Authenticated NXDOMAIN response To: dns-security@tis.com Date: Fri, 22 Apr 94 21:44:55 JST X-Mailer: ELM [version 2.3 PL11] If a list of all the names in a zone is available, authenticated NXDOMAIN is easy. But it is unrealistic to extract such lengthy information. So, how is the following idea to make NXDOMAIN response authenticated? Have the following new RR type: XD (eXisting Domains) XD ... where is the neggative cache period, , ... are all the domain names within the zone (including the toplevel name of child zones) which is located between and with some dictionary order. covers the data of the record (not all the XD records) signed by the zone's key. Then, to authenticate that some domain does not exist, an XD (not necessarily all the XDs) containing the queried domain between and should be added in the additional section. As there should be a lot of XD, the additional section should almost always be truncated, even if the query is by TCP. For example, if "com." zone contains only the following three domains beginning with "b": bar.com. bizzare.com. buzz.com. XD for them will be com. XD 3600 b.com. c.com. bar.com. bizzare.com. buzz.com. Then, a query for "best.com." will fail with authentication. To authenticate "foo.bar.com." does not exist, it is further necessary to confirm NS for "bar.com" does not exist. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa10449; 22 Apr 94 10:01 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA22124; Fri, 22 Apr 94 10:00:37 EDT Received: by relay.tis.com; id AA00410; Fri, 22 Apr 94 10:01:45 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma000396; Fri Apr 22 10:00:57 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 22 Apr 94 22:54:50 +0859 From: Masataka Ohta Return-Path: Message-Id: <9404221355.AA20519@necom830.cc.titech.ac.jp> Subject: Re: DNS security draft To: "Donald E. Eastlake 3rd" Date: Fri, 22 Apr 94 22:54:48 JST Cc: dns-security@tis.com In-Reply-To: <9404221322.AA17466@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Apr 22, 94 9:22 am X-Mailer: ELM [version 2.3 PL11] > >> Without a special name, all certificates would have to be stored at the > >> top of a zone, and include information within the RDATA. > > > >It's too much inelegant. Such information should properly be included > >in "named.boot" of BIND and should carefully maintained. > > To be really secure you need at least one key in the boot file of each > host running secure DNS. The current proposal allows putting however > may trusted keys you want there. But it seems to me that there would > be cases where putting cross certification keys in a zone and > maintaining them just in the zone master file would be easier than > maintaining these keys in many boot files. I don't mind someone develop a secure protocol to distribute boot files around all the related servers, OUTSIDE of the DNS protocol. If the protocol can somehow solve the serious operational issues I raised, it might be used by some of the people. If it can't, it won't be used widely. Doesn't it effectively satisfies the (rather bogus) cross certification requirement? > This would not eliminate > the need to have at least one key in every boot file. Boot file should contain as much keys as necessary. To make the scheme of secure DNS parallel to the existing one, all the name servers should know the public key of the root zone in "root.cache" file of BIND. Then, for each zone served by a name server as a secondary, the boot file should contain IP address(es) of other name server(s) of the zone and zone's public key. > Such cross certification is necessary to do secure > resolution if any zones on the hierarchy path from where you start to > the zone holding the node you are seeking are either insecure or all > their servers are inaccessible to you. No, it's not necessary. If you want to cover two disconnected zones, you should configure your name server boot file with public keys of both zones. That's all. You don't have to put them as DNS data with glue-like style, which does not work. So, put them in the boot file. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa12189; 22 Apr 94 12:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA27016; Fri, 22 Apr 94 11:13:44 EDT Received: by relay.tis.com; id AA01469; Fri, 22 Apr 94 11:14:52 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma001463; Fri Apr 22 11:14:40 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sat, 23 Apr 94 00:08:33 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404221508.AA20758@necom830.cc.titech.ac.jp> Subject: Re: DNS security draft To: Masataka Ohta Date: Sat, 23 Apr 94 0:08:31 JST Cc: dee@skidrow.lkg.dec.com, dns-security@tis.com In-Reply-To: <9404221355.AA20519@necom830.cc.titech.ac.jp>; from "Masataka Ohta" at Apr 22, 94 10:54 pm X-Mailer: ELM [version 2.3 PL11] > > This would not eliminate > > the need to have at least one key in every boot file. > > Boot file should contain as much keys as necessary. > > To make the scheme of secure DNS parallel to the existing one, > all the name servers should know the public key of the root zone > in "root.cache" file of BIND. Then, for each zone served by a name > server as a secondary, the boot file should contain IP address(es) > of other name server(s) of the zone and zone's public key. A minor improvement. MD5 signature of the zone's public key is enough for boot files and for referral information. Masataka Ohta PS May we assume MD5 is unforgeable forever?   Received: from sol.tis.com by magellan.TIS.COM id aa22892; 23 Apr 94 2:16 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA08136; Sat, 23 Apr 94 02:16:25 EDT Received: by relay.tis.com; id AA08048; Sat, 23 Apr 94 02:17:31 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma008043; Sat Apr 23 02:16:39 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sat, 23 Apr 94 15:10:32 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404230610.AA22841@necom830.cc.titech.ac.jp> Subject: Re: Authenticated NXDOMAIN response To: Matt Crawford Date: Sat, 23 Apr 94 15:10:31 JST Cc: dns-security@tis.com In-Reply-To: <9404221607.AA15071@munin.fnal.gov>; from "Matt Crawford" at Apr 22, 94 11:07 am X-Mailer: ELM [version 2.3 PL11] > > If a list of all the names in a zone is available, authenticated NXDOMAIN > > is easy. But it is unrealistic to extract such lengthy information. > > > > So, how is the following idea to make NXDOMAIN response authenticated? > > > > Have the following new RR type: XD (eXisting Domains) > > > > XD ... > > Why isn't the carried in a separate SIG RR, as for other RRs? Because it is necessary that: covers the data of the record (not all the XD records) ^^^^^^^^^^^^^^^^^^^^^^ signed by the zone's key. > > If a list of all the names in a zone is available, authenticated NXDOMAIN > > is easy. But it is unrealistic to extract such lengthy information. As you pointed out, time signed (and some additional informaton, maybe) should also be signed. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa22928; 23 Apr 94 2:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA08174; Sat, 23 Apr 94 02:22:25 EDT Received: by relay.tis.com; id AA08080; Sat, 23 Apr 94 02:23:33 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma008069; Sat Apr 23 02:22:39 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sat, 23 Apr 94 15:16:30 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404230616.AA22876@necom830.cc.titech.ac.jp> Subject: Re: DNS security draft To: Matt Crawford Date: Sat, 23 Apr 94 15:16:28 JST Cc: dns-security@tis.com, dee@skidrow.lkg.dec.com In-Reply-To: <9404221517.AA14817@munin.fnal.gov>; from "Matt Crawford" at Apr 22, 94 10:17 am X-Mailer: ELM [version 2.3 PL11] > I don't see any difference in elegance. I see a difference in > convenience, since I rarely touch named.boot. It is a lot more convenient if you don't have to touch something so often, which is, in some sense, engineering elegance. > And named.boot does > not now contain any RRs at all. Might you have meant the initial > cache file? Named.boot doesn't and won't contain any RRs, of course. Named.boot does contain raw IP addresses of name servers and will contain raw MD5 signature of zone keys. > > What, do you think, will happen, when a key of some zone is changed? How > > can a zone administrator know from which zones his zone is pointed by? > > He can't know. But he can do one of two things to ease the > transition when he changes keys: > > Sign his zone with both the old and new keys > > or (better) > > Sign his new key with his old key. Thus zones primed with > his old key can securely learn the new. So, the remaining job is to develop automatic mechanism to propagate such a change. I'll be happy if you do so outside of DNS protocol. > > What happens when a key of root or near root zone is changed to which > > a lot of zones point? > > Same as above, for a transitional period. DNS administrators will no > doubt run a tool that looks for changes in keys for zones whose keys > they have previously certified. Fine. Put it boot files. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa28709; 25 Apr 94 2:38 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA15194; Mon, 25 Apr 94 02:38:25 EDT Received: by relay.tis.com; id AA21680; Mon, 25 Apr 94 02:39:33 EDT Received: from gw.home.vix.com(192.5.5.1) by relay via smap (V1.3mjr) id sma021675; Mon Apr 25 02:38:50 1994 Received: by gw.home.vix.com id AA05035; Sun, 24 Apr 94 23:38:10 -0700 Message-Id: <9404250638.AA05035@gw.home.vix.com> X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: dns-security@tis.com Subject: here's something i just sent off to the big-internet and SIPP lists Date: Sun, 24 Apr 1994 23:38:09 -0700 From: Paul A Vixie ------- Forwarded Message Message-Id: <9404250618.AA04495@gw.home.vix.com> To: big-Internet@munnari.oz.au, sipp@sunroof2.Eng.Sun.COM Subject: Re: SIPP Routing Header & security In-Reply-To: Your message of "Sun, 24 Apr 1994 22:32:43 PDT." <9404250532.AA20742@jurassic.Eng.Sun.COM> Date: Sun, 24 Apr 1994 23:18:58 -0700 From: Paul A Vixie I've been watching this discussion for a couple of days now, and I've been alarmed to see references to the RSA proposal on dns-security as if it were a given. That work is very much still ``in progress'' and should not form a part of the strata on which you folks base any IP++ ideas. Today, Bob Hinden made an oblique reference to something I've been thinking about in connection with DNS security, when he said: >I don't think we should delay deploying IPng based on this. I do think >that we should send a strong message to the security folks that the >Internet needs a key-management mechanism soon. We shouldn't delay the >IPng work, we should accelerate the security work. I likewise feel that a standard mechanism for key distribution has to come about before we start trying to implement lots of different protocols which depend on it. After all, when a protocol designer wants to _depend_on_ some cryptographic tool which itself depends on key distribution, and then at some point realizes, "oh, yeah, and we need key distribution if this is going to work," then the key distribution mechanism is likely to be (a) less robust than the protocol which happens to require it, (b) incompatible with other key distribution mechanisms, (c) not scalable or generalized enough so that other protocols can also use it, or (d) all three. I didn't come to this thought through quite the same means Bob Hinden did, though. My problem is that the DNS protocol is not extensible in the dimension dns-security is currently requiring it to bend and stretch, and I came up with an "it sure would be nice if..." when I realized that It Sure Would Be Nice If any given host "just knew" or had the means to determine whether it could (or had already) exchange(d) keys with any other given host. Of course, the protocol itself would probably have to look a lot like DNS, since it would have as its key some unique host identifier (not just a name or an address, given multi-homed hosts, but probably some kind of hash of all its names and addresses, with CNAME-ish links to that hash from each individual name or address) and as its data a list of tuples of the form: (algorithm, public key) With enough rending and tearing and gnashing, this could probably be made a new RR in the existing DNS. But I don't think that's a terribly good idea. Ideally it would be or become the basis for the next rev of the DNS, which is an idea whose time has long since come except that I don't think we have collectively enough cycles to take on this general a problem right now. But I have seen the chaos that can erupt when the same feature is needed by lots of different protocols or subsystems but never becomes a ``first class'' subsystem or protocol of its own. Consider the feature called "queuing" and examine for yourself the many suboptimal implementations of it in the various UNIX subsystems (sendmail, uucp, lpd, at, and so on.) I dread the day when there are two sets of encryption datum offered by each host: one for IP++, one for Secure DNS. And two protocols for this. And two probably-variant implementations, each with their own foibles. Say it isn't so, someone, please! This sounds to me like a task for another new working group. (Sorry!) ------- End of Forwarded Message   Received: from sol.tis.com by magellan.TIS.COM id aa01807; 25 Apr 94 9:38 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA27626; Mon, 25 Apr 94 09:37:52 EDT Received: by relay.tis.com; id AA24113; Mon, 25 Apr 94 09:39:05 EDT Received: from fnal.fnal.gov(131.225.9.1) by relay via smap (V1.3mjr) id sma024108; Mon Apr 25 09:38:45 1994 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HBL3OSS6TC00273X@FNAL.FNAL.GOV>; Mon, 25 Apr 1994 08:37:53 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1) id AA18747; Mon, 25 Apr 94 08:37:05 CDT Date: Mon, 25 Apr 1994 08:37:05 -0500 From: Matt Crawford Subject: Re: Authenticated NXDOMAIN response In-Reply-To: Your message of Sat, 23 Apr 94 15:10:31 +0200. <9404230610.AA22841@necom830.cc.titech.ac.jp> To: Masataka Ohta Cc: dns-security@tis.com Message-Id: <9404251337.AA18747@munin.fnal.gov> Content-Transfer-Encoding: 7BIT > > > Have the following new RR type: XD (eXisting Domains) > > > XD ... > > > > Why isn't the carried in a separate SIG RR, as for other RRs? > > Because it is necessary that: > covers the data of the record (not all the XD records) > signed by the zone's key. The off-line process that signs a zone could know that XD records must be signed individually. The Eastlake & Kaufman draft does have a zone file syntax for showing which RRs are covered by each SIG. (But it's really ugly!) _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab   Received: from sol.tis.com by magellan.TIS.COM id aa01826; 25 Apr 94 9:42 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA27888; Mon, 25 Apr 94 09:41:57 EDT Received: by relay.tis.com; id AA24149; Mon, 25 Apr 94 09:43:10 EDT Received: from fnal.fnal.gov(131.225.9.1) by relay via smap (V1.3mjr) id sma024141; Mon Apr 25 09:42:49 1994 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HBL3TUH6BK00274P@FNAL.FNAL.GOV>; Mon, 25 Apr 1994 08:41:57 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1) id AA18763; Mon, 25 Apr 94 08:41:13 CDT Date: Mon, 25 Apr 1994 08:41:13 -0500 From: Matt Crawford Subject: Re: DNS security draft In-Reply-To: Your message of Sat, 23 Apr 94 15:16:28 +0200. <9404230616.AA22876@necom830.cc.titech.ac.jp> To: Masataka Ohta Cc: dns-security@tis.com, dee@skidrow.lkg.dec.com Message-Id: <9404251341.AA18763@munin.fnal.gov> Content-Transfer-Encoding: 7BIT > Named.boot doesn't and won't contain any RRs, of course. > > Named.boot does contain raw IP addresses of name servers and will > contain raw MD5 signature of zone keys. Then how do the DNS *clients* securely get that information? They can be told the address of a server they should trust, but without transaction authentication, that server could be spoofed. I think you need a whole zone key in the resolv.conf file (or the equivalent of it). _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab   Received: from sol.tis.com by magellan.TIS.COM id aa01945; 25 Apr 94 10:15 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA29694; Mon, 25 Apr 94 10:15:11 EDT Received: by relay.tis.com; id AA24550; Mon, 25 Apr 94 10:16:23 EDT Received: from atc.boeing.com(130.42.28.80) by relay via smap (V1.3mjr) id sma024544; Mon Apr 25 10:16:14 1994 Received: by atc.boeing.com (5.57) id AA10782; Mon, 25 Apr 94 07:10:48 -0700 Received: from commanche.ca.boeing.com by splinter.boeing.com with SMTP (16.6/16.2) id AA05999; Mon, 25 Apr 94 07:10:28 -0700 Received: by commanche.ca.boeing.com (AIX 3.2/UCB 5.64/4.03.TLDavis.AIX_3.2.5) id AA25621; Mon, 25 Apr 1994 07:08:41 -0700 Message-Id: <9404251408.AA25621@commanche.ca.boeing.com> To: dns-security@tis.com, big-Internet@munnari.oz.au, sipp@sunroof2.eng.sun.com Cc: paul@vix.com, dee@skidrow.lkg.dec.com, mohta@necom830.cc.titech.ac.jp Subject: Re: SIPP Routing Header & security & Re: DNS security draft In-Reply-To: (Your message of Sun, 24 Apr 94 23:38:09 MST.) <9404250638.AA05035@gw.home.vix.com> Date: Mon, 25 Apr 94 07:08:40 -0800 From: "Terry L. Davis P.E., Boeing Computer Services, Bellevue, WA" I've also been quietly watching these discussions but with the momentum building to adapt RSA so globally I do have to respond. I happen to agree with Paul Vixie that designing a generic key distribution protocol is far superior to building in proprietary ones. I ask that you consider the following thoughts: 1) It was always my impression that standards were implemented to avoid incorporating proprietary technologies so that each implementor could take advantage of his/her best mix of public, proprietary, and licensed solutions. Building in fixed requirements of this type certainly defeats that. 2) To me it is still totally unclear that any corporation could use RSA technology within a their established business or production processes without licensing it. I think several armies of lawyers could be enlisted here without definitive answers. 3) As anyone who has had even a minimal experience with cryptography knows, what often times what seems to be the most totally invulnerable algorithm possible often falls to a trivial solution. Just consider for a moment the impact to the Internet, should a trivial solution for de-crypting RSA algorithms be found in a few years with the entire structure of world-wide communication security resting solely on it. I personally cannot imagine designing security mechanisms for global use that will rely on any single technology; the risks are simply to great. If nothing else, consider the incentives you offer to the dark side of humanity for succeeding in breaking that single technology; un-imagined wealth and power for the taking. Take care | Terry L. Davis,P.E.| Boeing Computer Services, Bellevue, WA | | 206-957-5325 | BOEING EMAIL: tld5032@commanche.ca.boeing.com. | | INTERNET EMAIL: tld5032@atc.boeing.com. | -------------- Monday April 25,1994 07:01 AM PDT ------------- == As always, the above cannot be construed as representing BOEING, == == the thoughts, comments, and ideas contained herein are mine alone! ==   Received: from sol.tis.com by magellan.TIS.COM id aa02718; 25 Apr 94 12:17 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA08608; Mon, 25 Apr 94 12:17:18 EDT Received: by relay.tis.com; id AA25952; Mon, 25 Apr 94 12:18:30 EDT Received: from tsx-11.mit.edu(18.172.1.2) by relay via smap (V1.3mjr) id sma025947; Mon Apr 25 12:18:26 1994 Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA11885; Mon, 25 Apr 94 12:16:34 EDT Date: Mon, 25 Apr 94 12:16:34 EDT From: Theodore Ts'o Message-Id: <9404251616.AA11885@tsx-11.MIT.EDU> To: "Terry L. Davis P.E., Boeing Computer Services, Bellevue, WA" Cc: dns-security@tis.com, big-Internet@munnari.oz.au, sipp@sunroof2.eng.sun.com, paul@vix.com, dee@skidrow.lkg.dec.com, mohta@necom830.cc.titech.ac.jp In-Reply-To: Terry L. Davis P.E., Boeing Computer Services, Bellevue, WA's message of Mon, 25 Apr 94 07:08:40 -0800, <9404251408.AA25621@commanche.ca.boeing.com> Subject: Re: SIPP Routing Header & security & Re: DNS security draft Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Date: Mon, 25 Apr 94 07:08:40 -0800 From: "Terry L. Davis P.E., Boeing Computer Services, Bellevue, WA" I've also been quietly watching these discussions but with the momentum building to adapt RSA so globally I do have to respond. I happen to agree with Paul Vixie that designing a generic key distribution protocol is far superior to building in proprietary ones. Generic protocols also mean "non-interoperable". I would have thought we would have learned to avoid the mistakes of OSI by now. Like it or not, whether or not we have an algorithm identifier field or not, in order for this thing to work, the IETF is going to have to put a stake in the ground and say that everyone is going to use this *one* cryptographic algorithm. It's the same problem as the one that's facing the IPNG decision process. Sometimes, you just have to pick one, and picking anything protocol is better than not picking a protocol at all. 1) It was always my impression that standards were implemented to avoid incorporating proprietary technologies so that each implementor could take advantage of his/her best mix of public, proprietary, and licensed solutions. Building in fixed requirements of this type certainly defeats that. It is certainly desierable to avoid incorporating proprietary technologies whenever possible. However, it is one thing to avoid trying to use propietary protocols; it is another thing to say we can not use a particular concept at all because it has been patented. After all, Ethernet is patented, and yet the fact that it has been patented has not stopped it from being widely deployed all over world, has it not? For all of the people who have been bitching and moaning --- if you don't like the current proposal, then come up with something new! Unfortunately, public key cryptography is a key technology, without which, many things in cryptography and security architecture become much harder. Don't get me wrong --- I think software patents and algorithm patents are particularily evil, and Congress should wake up and ban the Patent Office from issuing any more of them. But I also think we need to wake up and face reality. The Internet needs public key cryptography --- badly; and if making peace with RSADSI is what's required until the patent runs out in a few more years, then we should do what is necessary to do so. - Ted   Received: from sol.tis.com by magellan.TIS.COM id aa03308; 25 Apr 94 13:31 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA14417; Mon, 25 Apr 94 13:31:14 EDT Received: by relay.tis.com; id AA27153; Mon, 25 Apr 94 13:32:25 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma027137; Mon Apr 25 13:31:51 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA12388; Mon, 25 Apr 94 10:13:08 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA13136; Mon, 25 Apr 1994 13:14:53 -0400 Message-Id: <9404251714.AA13136@skidrow.lkg.dec.com> To: "Terry L. Davis P.E., Boeing Computer Services, Bellevue, WA" Cc: dns-security@tis.com, big-Internet@munnari.oz.au, sipp@sunroof2.eng.sun.com Subject: Re: SIPP Routing Header & security & Re: DNS security draft In-Reply-To: Your message of "Mon, 25 Apr 94 07:08:40 -0800." <9404251408.AA25621@commanche.ca.boeing.com> Date: Mon, 25 Apr 94 13:14:53 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Terry, From: "Terry L. Davis P.E., Boeing Computer Services, Bellevue, WA" To: dns-security@tis.com, big-Internet@munnari.oz.au, sipp@sunroof2.eng.sun.com Cc: paul@vix.com, dee, mohta@necom830.cc.titech.ac.jp In-Reply-To: (Your message of Sun, 24 Apr 94 23:38:09 MST.) <9404250638.AA05035@gw.home.vix.com> > >... > >2) To me it is still totally unclear that any corporation could use RSA > technology within a their established business or production processes > without licensing it. I think several armies of lawyers could be > enlisted here without definitive answers. Nonsense. Pick up the telephone. Call RSA Data Systems Inc. in Redwood City, California. (Or have your lawyer call their lawyer.) They will confirm that any company can use RSA internally, use PEM to communicate with other companies, etc., all in a profit making setting. The only thing RSA is still asking for royalties for is people who want to sell software incorporating RSA or sell a service where RSA is an essential part. >3) As anyone who has had even a minimal experience with cryptography > knows, what often times what seems to be the most totally invulnerable > algorithm possible often falls to a trivial solution. Just consider > for a moment the impact to the Internet, should a trivial solution for > de-crypting RSA algorithms be found in a few years with the entire > structure of world-wide communication security resting solely on it. Whatever algoritm is chosen, the people who want to interoperate will all have to speak it. Everyone knows you will need a method to roll over to a new algorithm when / if that is necessary. >I personally cannot imagine designing security mechanisms for global >use that will rely on any single technology; the risks are simply to >great. If nothing else, consider the incentives you offer to the dark >side of humanity for succeeding in breaking that single technology; >un-imagined wealth and power for the taking. So you want multiple algorithms so that those who want to interoperate will have to speak all of them so that if *any* *one* *of* *them* is broken, things will fall apart? Sounds like a great way to weaken network security to me. (Of course there should also be a way for consenting adults to use whatever algorithm they want, not that you could stop them anyway.) >Take care > > | Terry L. Davis,P.E.| Boeing Computer Services, Bellevue, WA | > | 206-957-5325 | BOEING EMAIL: tld5032@commanche.ca.boeing.com. | > | INTERNET EMAIL: tld5032@atc.boeing.com. | > -------------- Monday April 25,1994 07:01 AM PDT ------------- > > == As always, the above cannot be construed as representing BOEING, == > == the thoughts, comments, and ideas contained herein are mine alone! == Donald   Received: from sol.tis.com by magellan.TIS.COM id aa03369; 25 Apr 94 13:52 EDT Received: from happy.tis.com by tis.com (4.1/SUN-5.64) id AA17273; Mon, 25 Apr 94 13:52:32 EDT Message-Id: <9404251752.AA17273@tis.com> To: "Donald E. Eastlake 3rd (Beast)" Cc: dns-security@tis.com, big-Internet@munnari.oz.au, sipp@sunroof2.eng.sun.com Subject: RSA technology [Was: SIPP Routing ... & DNS Security] In-Reply-To: Your message of "Mon, 25 Apr 94 13:14:53 EDT." <9404251714.AA13136@skidrow.lkg.dec.com> Date: Mon, 25 Apr 94 13:52:24 -0400 From: Stephen D Crocker Donald, You wrote: > >2) To me it is still totally unclear that any corporation could use RSA > > technology within a their established business or production processes > > without licensing it. I think several armies of lawyers could be > > enlisted here without definitive answers. > > Nonsense. Pick up the telephone. Call RSA Data Systems Inc. in > Redwood City, California. (Or have your lawyer call their lawyer.) > They will confirm that any company can use RSA internally, use PEM to > communicate with other companies, etc., all in a profit making > setting. The only thing RSA is still asking for royalties for is > people who want to sell software incorporating RSA or sell a service > where RSA is an essential part. I see three distinctions which are not evident in your advice. Here's my understanding, with the usual caveats about legal advice. a) There is RSA technology. If you write your own software and implement the RSA algorithms for key exchange or signature, I believe you're using RSA technology. This is patented technology, and I believe you have to deal with Public Key Partners for permission to make, use, etc. this technology. (Consult your own lawyer for details on fair use or other doctrine; I won't attempt to speak to that sort of thing.) b) RSA Data Security Inc. makes available a general purpose package, RSAREF, which implements the RSA technology. It comes with a specific license governing how it's to be used. Some forms of non-commercial use are permitted. c) There are specific application programs, including RIPEM/SIG from RSADSI and TIS/PEM from TIS, which have broad permission for use in non-sales contexts. These incorporate RSAREF, but may be usable without charge in some contexts not covered by the generic RSAREF license. Steve   Received: from sol.tis.com by magellan.TIS.COM id aa04260; 25 Apr 94 16:01 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA28601; Mon, 25 Apr 94 16:00:41 EDT Received: by relay.tis.com; id AA28882; Mon, 25 Apr 94 16:01:54 EDT Received: from ginger.lcs.mit.edu(18.26.0.82) by relay via smap (V1.3mjr) id sma028875; Mon Apr 25 16:01:10 1994 Received: by ginger.lcs.mit.edu id AA28202; Mon, 25 Apr 94 16:00:11 -0400 Date: Mon, 25 Apr 94 16:00:11 -0400 From: Noel Chiappa Message-Id: <9404252000.AA28202@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, dns-security@tis.com, sipp@sunroof2.eng.sun.com Subject: Re: SIPP Routing Header & security & Re: DNS security draft Cc: jnc@ginger.lcs.mit.edu Generic protocols also mean "non-interoperable". ... Like it or not, whether or not we have an algorithm identifier field or not, in order for this thing to work, the IETF is going to have to put a stake in the ground and say that everyone is going to use this *one* cryptographic algorithm. I have no problem with picking one, as long as the hooks are there to use something else, as you desire. For a number of reasons (not wanting to intrude on patents, algorithmic expense, discovery of holes in algorithms) you might want to use something else. So, let's make sure to keep "algorithm identifier field"! It's the same problem as the one that's facing the IPNG decision process. Not quite. You and I may decide to use some private encryption algorithm, and nobody but us has to know. (I know, key distribution is a trickier case, since you may have to deal with many other sites, but...) The internetwork packet format, on the other hand, is *the* glue that holds it all together. Not just you and I, but all sites in between, have to use the same thing for us to communicate. Noel   Received: from sol.tis.com by magellan.TIS.COM id aa04616; 25 Apr 94 17:06 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA03785; Mon, 25 Apr 94 17:06:26 EDT Received: by relay.tis.com; id AA29624; Mon, 25 Apr 94 17:07:40 EDT Received: from tsx-11.mit.edu(18.172.1.2) by relay via smap (V1.3mjr) id sma029619; Mon Apr 25 17:06:52 1994 Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA15683; Mon, 25 Apr 94 17:04:50 EDT Date: Mon, 25 Apr 94 17:04:50 EDT From: Theodore Ts'o Message-Id: <9404252104.AA15683@tsx-11.MIT.EDU> To: Noel Chiappa Cc: big-internet@munnari.oz.au, dns-security@tis.com, sipp@sunroof2.eng.sun.com, jnc@ginger.lcs.mit.edu In-Reply-To: Noel Chiappa's message of Mon, 25 Apr 94 16:00:11 -0400, <9404252000.AA28202@ginger.lcs.mit.edu> Subject: Re: SIPP Routing Header & security & Re: DNS security draft Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Date: Mon, 25 Apr 94 16:00:11 -0400 From: Noel Chiappa Not quite. You and I may decide to use some private encryption algorithm, and nobody but us has to know. (I know, key distribution is a trickier case, since you may have to deal with many other sites, but...) The internetwork packet format, on the other hand, is *the* glue that holds it all together. Not just you and I, but all sites in between, have to use the same thing for us to communicate. What I am talking about is specifically key distribution, and signatures for the DNS. (The original complaints originally arose out of discussions from the DNS Security working group.) And, specifically within this context, I will claim that we do need to pick one protocol, because like the internetwork packet format, an internet-wide key distribution and certification system is *the* glue to hold any cryptographic security system all together. - Ted   Received: from sol.tis.com by magellan.TIS.COM id aa04705; 25 Apr 94 17:28 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA05740; Mon, 25 Apr 94 17:28:35 EDT Received: by relay.tis.com; id AA29811; Mon, 25 Apr 94 17:29:48 EDT Received: from decvax.zk3.dec.com(16.140.0.3) by relay via smap (V1.3mjr) id sma029806; Mon Apr 25 17:29:17 1994 Received: from abyss.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA13909; Mon, 25 Apr 1994 17:28:34 -0400 Received: by abyss.zk3.dec.com (5.65/DEC-USG-ULTRIX-4.4-03/25/94) id AA23917; Mon, 25 Apr 1994 17:28:32 -0400 Message-Id: <9404252128.AA23917@abyss.zk3.dec.com> To: dns-security@tis.com Cc: kaufman@zk3.dec.com Subject: Re: DNS security draft Date: Mon, 25 Apr 94 17:28:31 -0400 From: kaufman@zk3.dec.com X-Mts: smtp The current proposal for DNS security is tightly tied to a particular set of cryptographic algorithms (RSA and MD5) and a particular way of using them. It is quite likely that someone will at some point want to secure DNS in some different way with some different cryptographic algorithms. (Digital's ULTRIX product, for example, already secures DNS with Kerberos). It would be desireable if the various DNS security schemes developed over time be sufficiently aware of one another that a single resolver could deal with the security mechanisms of different domains and (less likely) a domain could support multiple mechanisms for the benefit of different kinds of resolvers. This will generally be possible if the schemes pay minimal attention to one another or are lucky. (For example, the current proposal was developed without detailed knowledge of the existing ULTRIX implementation, but I believe the two could coexist comfortably). What would it mean to develop an "algorithm-independent" security protocol, as some have proposed? It might mean several things: 1) It could mean we specify cryptographic algorithms in a separate document from the one with elements that might be used with different algorithms (as the PEM standards have done). We could do that, but I believe there would be little benefit and a non-trivial cost in readability unless someone wants to invest in actually specifying a second set of algorithms. 2) It could mean we specify the crypto-algorithm independent aspects of the protocol first and defer design of the algorithm-specific parts. I think this would be a big mistake both because it would delay production of something useful (a complete stack) and in the absence of real-world constraints we could probably do a bad job on the algorithm independent parts. 3) It could mean we specify the crypto-algorithm independent aspects of the protocol only and let individual implementations go there own way on algorithm-specific parts since they (if they use public key cryptography) are proprietary due to patents. I think this would be a waste of time. People can do proprietary solutions without our help; if we can't specify enough to guarantee that compliant solutions interoperate, we might as well all go home. 4) It could mean we leave explicit hooks for future algorithms in the current design. For example, instead of RSA resource records, we could have PUBKEY resource records with an algorithm identifier at the beginning of the field. This would mean that to add - say - DSS keys, one would have to get a new value assigned for the algorithm identifier field instead of getting a new resource record field type assigned. I don't think it makes much difference in practice as to which is more expandable. The currently proposed way saves a few bytes. I will concede that perhaps the SIG record should be renamed the RSASIG record if it isn't going to have such an identifier. Could people who want "algorithm independence" say which of these they want and defend it? (or explain the fifth option I didn't think of). --Charlie (kaufman@zk3.dec.com)   Received: from sol.tis.com by magellan.TIS.COM id aa04746; 25 Apr 94 17:48 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA06394; Mon, 25 Apr 94 17:47:46 EDT Received: by relay.tis.com; id AA00121; Mon, 25 Apr 94 17:48:59 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma000107; Mon Apr 25 17:48:22 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA28600; Mon, 25 Apr 94 14:33:01 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA15352; Mon, 25 Apr 1994 17:34:46 -0400 Message-Id: <9404252134.AA15352@skidrow.lkg.dec.com> To: Matt Crawford Cc: dns-security@tis.com Subject: Re: Authenticated NXDOMAIN response In-Reply-To: Your message of "Mon, 25 Apr 94 08:37:05 CDT." <9404251337.AA18747@munin.fnal.gov> Date: Mon, 25 Apr 94 17:34:46 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: Matt Crawford In-Reply-To: Your message of Sat, 23 Apr 94 15:10:31 +0200. <9404230610.AA22841@necom830.cc.titech. ac.jp> To: Masataka Ohta Cc: dns-security@tis.com Content-Transfer-Encoding: 7BIT >> > > Have the following new RR type: XD (eXisting Domains) >> > > XD ... >> > >> > Why isn't the carried in a separate SIG RR, as for other RRs? >> >> Because it is necessary that: >> covers the data of the record (not all the XD records) >> signed by the zone's key. > >The off-line process that signs a zone could know that XD records >must be signed individually. The Eastlake & Kaufman draft does have >a zone file syntax for showing which RRs are covered by each SIG. >(But it's really ugly!) If you have an idea for a less-ugly syntax, I'd like to see it. At least the zone maintainer should not have to see our proposed syntax much. It would be automatically added by the off-line signing process and would not have to be there in the basic master file. >_________________________________________________________ >Matt Crawford crawdad@fnal.gov Fermilab Donald   Received: from sol.tis.com by magellan.TIS.COM id aa05168; 25 Apr 94 22:47 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13266; Mon, 25 Apr 94 22:47:35 EDT Received: by relay.tis.com; id AA01946; Mon, 25 Apr 94 22:48:49 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma001941; Mon Apr 25 22:48:07 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA14090; Mon, 25 Apr 94 19:35:49 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA17332; Mon, 25 Apr 1994 22:37:32 -0400 Message-Id: <9404260237.AA17332@skidrow.lkg.dec.com> To: Steve Kent Cc: dns-security@tis.com Subject: Algorithms ( was Re: Security AD's assesment re RSAREF licensing ) In-Reply-To: Your message of "Tue, 12 Apr 94 18:55:03 EDT." <9404122258.AA28259@relay.tis.com> Date: Mon, 25 Apr 94 22:37:32 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Steve, From: Steve Kent To: Paul A Vixie Cc: dns-security@tis.com In-Reply-To: Your message of Tue, 12 Apr 94 15:22:30 -0700. <9404122222.AA23689@gw.home.vix.com> >Paul, > > Perhaps to the surprize of many, I agree with the general >thrust of your statement, i.e., that PEM may not be a good precedent >for adopting RSA for the DNS, but for different reasons. > >... > > For exmaple, ElGamal is an alternative signature algorithm >which is not itself patented, but which is embraced by the fundamental >Diffie-Hellman public key patent that expires in 1997 (I believe). >ElGamal is not very efficient, but it is an alternative that has a >shorter duration patent status relative to RSA. Looks to me like ElGamal would produce signatures that were twice as big and took at least a *hundred* and in some cases over a *thousand* times more computation effort to verify than profiled RSA. And it's not like RSA is all that cheap computationally. ElGamal is quite inferior in my mind. > The DSA, a variant of ElGamal, is covered by a much more >recent patent, making it less desirable, but NIST has been claiming >that it will arrange to make the DSA royalty free for everyone (at >least in the U.S.). The DSA is much more efficient than ElGamal, >though it is not very space efficient compared to RSA. Moreover, DSA >signatures are more expensive to verify than to generate (just >backwards for the DNS use), and they are slower than comparable RSA >signatures. However, on an absolute performance basis, DSA software >is getting better and its lower performance might be irrelevant in the >grand scheme of things. Most of the world is outside of the US. Besides its poor performance, would it really make sense to standardize for the Global DNS on something like DSA with patent royalties in much of the rest of the world until 2008+ ? And, as far as I know, there isn't a SchnorrREF letting you practice the Schnorr patent (which DSA allegedly infringes) even for non-commerical use. Doesn't it make more sense to adopt the technically superior algorithm which is completely unrestricted outside the US and will be effectively free for the vast majority of US users? Is saving just that small fraction of US users that will have to pay a small fee for a few years worth going with an obviously inferior algorithm? > The concern I did raise in the DNS Security WG meeting is that >the current proposal is tied unalterablty to RSA. The same is true of >the current PEM spec, but it is being revised to accommodate separate >algorithms for signature vs. encryption key management. To the extent >that folks have argued for this separation of public key functions in >PEM, and thus makeing PEM more algorithm independent, it seems a pity >to adopt a scheme for DNS security that is very much algorithm >dependent, even independent of patent issues. The structure of the current proposal is entirely algorithm independent. There are signature RRs and key RRs. Zones are signed by a zone key, preferably off line. Servers need not be trusted or security aware. There are some header bits so resolvers and servers can tell if the other is security aware and do what is most efficient if both are. What does this have to do with any particular algorithm? Then, if you use RSA, or anything else where you can pull the trick, you can put some data directly inside the signature when it optimizes things. > It is clear from the spec that Donald and George worked hard That's Donald and Charlie. >to deisgn a scheme that minimizes the extra space taken up by >signatures. That probably motivated the use of RSA, the only one of >the algorithms mentioned above that is "reversable" in terms of >signature data. > >... > >Steve Donald PS: Note: this mailing list may shortly be receiving messages from one or more persons who believe that the patent issue is more important than any other. They will advocate using that technology whose patent expires first regardless of technical merit and advcate delaying DNS SEC until it can be implemented entirely with unpatented technology. I believe that DNS SEC is needed strongly enough that it should be implemented with all deliberate speed and that, while patent lifetime is certainly a factor to consider, it is but one factor among many including, but not limited to, space efficiency, computational efficiency, and previous standards decisions.   Received: from sol.tis.com by magellan.TIS.COM id aa05196; 25 Apr 94 23:02 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13574; Mon, 25 Apr 94 23:01:43 EDT Received: by relay.tis.com; id AA02111; Mon, 25 Apr 94 23:02:57 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma002106; Mon Apr 25 23:02:36 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA14674; Mon, 25 Apr 94 19:51:01 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA17463; Mon, 25 Apr 1994 22:52:44 -0400 Message-Id: <9404260252.AA17463@skidrow.lkg.dec.com> To: pkarger@gte.com Cc: dns-security@tis.com Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of "Thu, 21 Apr 94 10:46:22 EDT." <9404211446.AA17525@pkarger.tcc> Date: Mon, 25 Apr 94 22:52:44 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Paul From: "Paul A. Karger" To: "Donald E. Eastlake 3rd (Beast)" Cc: pkarger@gte.com, dns-security@tis.com Phone: +1 (617) 466-3844 Fax: +1 (617) 890-9320 Organization: GTE Laboratories In-Reply-To: Your message of "Wed, 20 Apr 94 00:08:17 EDT." <9404200408.AA23362@skidrow.lkg.dec.com> >I'm sorry that you found my suggestion of supporting multiple >crypto algorithms so controversial or that you thought I was >"pounding on a point". I was only trying to make what I thought was >a mild and non-controversial suggestion that mandating a particular >algorithm is not necessarily the best approach, even for a public >directory service, such as DNS. If my messages came across otherwise, >then I apologize for causing a problem. Sorry I over-reacted. If you want to argue for the support of multiple crypto algorithms, feel free to do so. However, I don't see the point of your arguing that RSA may be broken and I don't see the point of your arguing that the DNS security extensions should have some way of changing to another algorithm if RSA is broken when I explicitly agreed with you on both points and no one was disputing these points and in fact they were also brought up and accepted at the DNS SEC WG meeting in Seattle. These points are a far cry from simultaneous support for multiple algorithms, algorithm negotiation, etc. >... > >I am not an advocate of the current export control laws in the US, >nor of the CLIPPER proposals. However, it is reality that not all >countries will accept the use of the same cryptographic algorithms >either in their own countries or for export to other countries. While >those attitudes are regrettable, they are also reality. Supporting >multiple algorithms can make life under some of these irrational >export and use rules easier. First of all, I'm not aware on any country that restricts the algorithms you can use in the country. You may have to give a copy of your code and keys to the government, but there is no other restriction. When there are export restrictions, they normally restrict all but weak crypto. While I have no problem with weak crypto if that's all you can do and you have appropriate caveats, I can't see any reason for the IETF to standardize on weak crypto for secure DNS. I just can't see any problem in any Internet connected country using strong crypto by writing it or getting it from a country without export restrictions of for free from one of the countries where export restrictions apply only to sales. >Some algorithms are subject to patent and licensing restrictions. >Supporting multiple algorithms can make it possible for selected >communities to choose not to pay license fees if they don't want to. >I don't personally consider this a major problem, but some members >of the Internet community get very upset at the thought of paying >royalties on the RSA patent. Supporting multiple algorithms might >make it easier to adopt RSA as the preferred algorithm, if those >who don't wish to pay royalties have a way to avoid them. The DNS is a global distributed database system. I really can't see all the open servers out there supporting N different signatures on everything. I suppose some compact community might want to use some different algorithm inside a firewall and have all their border DNS systems know both, or something like that. Such set ups tend to have all kinds of problems. And, unless they work with unpaid volunteers, its going to cost them a lot more to set this up and keep things straight in term of labor than anything they are going to save in royalties for the few years they still apply to some limited uses in the US only. > >... > >Cryptographic algorithms (other than one-time pads) do >get broken periodically. Allowing for replacing an algorithm that >proves too weak is a good thing. Here you are assering the same two things yet again. Guess I'll agree with it for the third time. > Allowing for replacing the replacement >algorithm is also a good thing, because the replacement might also >be broken. This implies that a single bit indicating old or new >algorithm is not sufficient. Instead, some kind of algorithm >version number is preferable. If one really thought that the probability was low enough of the algorithm being broken, then one escape bit would be fine. If that bit was ever turned on, then it could indicate the existence of a protocol version field or whatever. But there are enough fee bits to add such a field now, anyway, and I plan to do so. >Finally, negotiating crypto algorithms adds overhead to a communications >protocol. If we believe that the vast majority of users will in fact >use a single algorithm that we don't expect to be broken any time soon, >then algorithm negotiation should be designed to not add extra messages >in the case of the default algorithm. This can be achieved by the >client and server both assuming the default, unless one or the other >sends a special message requesting something else. It turns out to be extremely painful, if it is possible at all, to flag this sort of thing due to the contraints of the DNS protocol and the existing implementations. >... > > - Paul Donald   Received: from sol.tis.com by magellan.TIS.COM id aa05312; 26 Apr 94 0:16 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA14812; Tue, 26 Apr 94 00:16:06 EDT Received: by relay.tis.com; id AA02533; Tue, 26 Apr 94 00:17:16 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma002520; Tue Apr 26 00:15:17 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 26 Apr 94 13:08:34 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404260408.AA03998@necom830.cc.titech.ac.jp> Subject: Re: Authenticated NXDOMAIN response To: Matt Crawford Date: Tue, 26 Apr 94 13:08:32 JST Cc: dns-security@tis.com In-Reply-To: <9404251337.AA18747@munin.fnal.gov>; from "Matt Crawford" at Apr 25, 94 8:37 am X-Mailer: ELM [version 2.3 PL11] > The off-line process that signs a zone could know that XD records > must be signed individually. Yes. > The Eastlake & Kaufman draft does have > a zone file syntax for showing which RRs are covered by each SIG. That's for the authentication of NXRR, not NXDOMAIN. The Eastlake & Kaufman draft suggests to authenticate NXDOMAIN with hosts, not zone, key. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa07829; 26 Apr 94 8:47 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA25479; Tue, 26 Apr 94 08:47:22 EDT Received: by relay.tis.com; id AA06125; Tue, 26 Apr 94 08:48:36 EDT Received: from ginger.lcs.mit.edu(18.26.0.82) by relay via smap (V1.3mjr) id sma006116; Tue Apr 26 08:48:29 1994 Received: by ginger.lcs.mit.edu id AA02870; Tue, 26 Apr 94 08:47:42 -0400 Date: Tue, 26 Apr 94 08:47:42 -0400 From: Noel Chiappa Message-Id: <9404261247.AA02870@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au Subject: Re: SIPP Routing Header & security & Re: DNS security draft Cc: dns-security@tis.com, jnc@ginger.lcs.mit.edu, sipp@sunroof2.eng.sun.com >> Generic protocols also mean "non-interoperable". ... Like it or not, >> ... in order for this thing to work, the IETF is going to have to put a >> stake in the ground and say that everyone is going to use this *one* >> cryptographic algorithm. > I have no problem with picking one, as long as the hooks are there to use > something else ... let's make sure to keep "algorithm identifier field"! > ... You and I may decide to use some private encryption algorithm, and > nobody but us has to know. What I am talking about is specifically key distribution, and signatures for the DNS. ... And, specifically within this context, I will claim that we do need to pick one protocol, because like the internetwork packet format, an internet-wide key distribution and certification system is *the* glue to hold any cryptographic security system all together. Whoa. We just went from "one algorithm" (in your first clip) to "one protocol". I don't believe they are the same; the "algorithm identifier field" (along with key length, etc) would allow use of several signing algorithms within one protocol. Did I miss something? I agree that we need one protocol to do key distribution, and that is a pretty fundamental piece of glue (let's not argue about exactly *how* fundamental). However, I stick with my original claim that we should allow various algorithms. Sure, we should have one (or more, for export/patent/whatever reasons) base algorithm, so that all entries are signed in at least one way which everyone can verify. I don't see any reason not to allow pairwise use of other algorithms, though. If (as seems unlikely, but I admit it's possible) someone discovers a hole in the base algorithm, this would allow a (less painful) incremental, and interoperable, switch to a new algorithm. Noel   Received: from sol.tis.com by magellan.TIS.COM id aa08572; 26 Apr 94 9:40 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA27965; Tue, 26 Apr 94 09:39:52 EDT Received: by relay.tis.com; id AA06750; Tue, 26 Apr 94 09:41:06 EDT Received: from ns.gte.com(132.197.8.9) by relay via smap (V1.3mjr) id sma006742; Tue Apr 26 09:40:43 1994 Received: from bunny.gte.com by ns.gte.com (5.65c/IDA-1.4.4) id AA19694; Tue, 26 Apr 1994 09:34:21 -0400 Received: from pkarger by bunny.gte.com (5.61/GTEL2.19) id AA05506; Tue, 26 Apr 94 09:27:55 -0400 Received: from localhost by pkarger.tcc (4.1/SMI-4.1) id AA28488; Tue, 26 Apr 94 09:31:34 EDT Message-Id: <9404261331.AA28488@pkarger.tcc> To: kaufman@zk3.dec.com Cc: dns-security@tis.com, pak0@gte.com Reply-To: pkarger@gte.com Phone: +1 (617) 466-3844 Fax: +1 (617) 890-9320 Organization: GTE Laboratories Subject: Re: DNS security draft In-Reply-To: Your message of "Mon, 25 Apr 94 17:28:31 EDT." <9404252128.AA23917@abyss.zk3.dec.com> Date: Tue, 26 Apr 94 09:31:33 -0400 From: "Paul A. Karger" Charlie: My primary concern in advocating multiple algorithms is to handle the case when either RSA or MD5 or their successors get broken. There should be a graceful way to quickly and universally communicate the need to switch to a new algorithm and hopefully not affect user application binaries in any way. That is, the system managers should be able to install the new algorithms without asking users to change anything. Since not all system managers will upgrade at the same time, there will need to be some negotiation to continue to support the old algorithms during the changeover. However, since the old algorithms are being replaced due to security problems, there ought to be a way to warn the system managers and users of the need to upgrade. Given the need to support both old and new algorithms, and the need to potentially replace the new algorithms with still newer algorithms (if the replacements get broken), then there is a need to allow clients and servers to negotiate their choice of crypto algorithms. Given the need for negotiation, there is the possibility of supporting multiple algorithms for other reasons. I can think of two reasons (other than an algorithm being broken) that multiple algorithms might be wanted. 1) license restrictions There has certainly been a lot of heat over the choice of RSA, because some people object to paying royalties on the patents. While I don't personally object to paying royalties, support of multiple algorithms could allow those who do object to use something else at the expense of interoperability. 2) doctrinal requirements There are some potential users of DNS who may require use of their own algorithms for doctrinal reasons. For example, the DoD might wish to use NSA-supplied algorithms when classified material is involved. Other countries (eg: France) may have their own special requirements. My personal belief is that the license and doctrinal requirements are secondary to the recovery from a crypto break. If DNS only supported recovery from a crypto break, I would be happy. The others are merely "nice to haves" in my personal opinion. To respond to your specific questions: >What would it mean to develop an "algorithm-independent" security >protocol, as some have proposed? It might mean several things: > >1) It could mean we specify cryptographic algorithms in a separate >document from the one with elements that might be used with different >algorithms (as the PEM standards have done). We could do that, but I >believe there would be little benefit and a non-trivial cost in >readability unless someone wants to invest in actually specifying a >second set of algorithms. I don't see a need to this. RSA and MD5 would be the algorithms of choice. >2) It could mean we specify the crypto-algorithm independent aspects >of the protocol first and defer design of the algorithm-specific >parts. I think this would be a big mistake both because it would >delay production of something useful (a complete stack) and in the >absence of real-world constraints we could probably do a bad job on >the algorithm independent parts. I agree with you that this would be a bad idea, too. >3) It could mean we specify the crypto-algorithm independent aspects >of the protocol only and let individual implementations go there own >way on algorithm-specific parts since they (if they use public key >cryptography) are proprietary due to patents. I think this would be >a waste of time. People can do proprietary solutions without our >help; if we can't specify enough to guarantee that compliant solutions >interoperate, we might as well all go home. This is also a bad idea, as you point out. >4) It could mean we leave explicit hooks for future algorithms in the >current design. For example, instead of RSA resource records, we >could have PUBKEY resource records with an algorithm identifier at the >beginning of the field. This would mean that to add - say - DSS keys, >one would have to get a new value assigned for the algorithm >identifier field instead of getting a new resource record field type >assigned. I don't think it makes much difference in practice as to >which is more expandable. The currently proposed way saves a few >bytes. I will concede that perhaps the SIG record should be renamed >the RSASIG record if it isn't going to have such an identifier. This is precisely what I mean. There need to be explicit hooks for future algorithms. This probably means a registry of algorithms so that they can be assigned numbers and a way to negotiate which one is in use. The negotiation protocol should be implemented on the assumption that the overwhelming majority of uses will use the standard default algorithm, and that the standard default will change infrequently. Ideally, if you are using the standard default algorithm, there should be zero overhead for negotiation. Only if you use a non-standard algorithm, should you pay a performance penalty. The standard default should have a way of changing for the case of an algorithm break, but that should be a VERY rare event. I guess I should add that these are my personal opinions and do not represent the official opinion of GTE Laboratories, Inc.   Received: from sol.tis.com by magellan.TIS.COM id aa05810; 26 Apr 94 4:16 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA18797; Tue, 26 Apr 94 04:16:23 EDT Received: by relay.tis.com; id AA04115; Tue, 26 Apr 94 04:17:37 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma004110; Tue Apr 26 04:16:52 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 26 Apr 94 17:10:45 +0859 From: Masataka Ohta Return-Path: Message-Id: <9404260811.AA05591@necom830.cc.titech.ac.jp> Subject: Re: DNS security draft To: Matt Crawford Date: Tue, 26 Apr 94 17:10:42 JST Cc: dns-security@tis.com, dee@skidrow.lkg.dec.com In-Reply-To: <9404251341.AA18763@munin.fnal.gov>; from "Matt Crawford" at Apr 25, 94 8:41 am X-Mailer: ELM [version 2.3 PL11] > > Named.boot doesn't and won't contain any RRs, of course. > > > > Named.boot does contain raw IP addresses of name servers and will > > contain raw MD5 signature of zone keys. > > Then how do the DNS *clients* securely get that information? You should distinguish name servers and resolvers. Resolvers are tied to other resolvers or name servers, not to specific zones. So, the proper security for resolvers fanatically royal to the existing DNS architecture is authentication of hosts, not zones. It is OK to have zone keys for name servers especially because making NXDOMAIN response authenticated is now possible. Moreover, considering the proposed load balancing mechanism and its possible applicability for other problems, absence of primary server and, thus, its key is rather desirable. But, it is not necessary that resolvers know zone keys. > They > can be told the address of a server they should trust, but without > transaction authentication, that server could be spoofed. Correct. Anyway, if a host running an application is compromised, the application is compromised. Just like it, it is not so bad that if a host running a name server for an application is compromised, the application referring the name server is compromised. System administrators should protect name server or he may run extra name servers on hosts which needs a little more authentication. > I think you need a whole zone key in the resolv.conf file (or the > equivalent of it). Resolv.conf should have whole host keys or their MD5. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa05994; 26 Apr 94 5:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA19349; Tue, 26 Apr 94 05:04:41 EDT Received: by relay.tis.com; id AA04475; Tue, 26 Apr 94 05:05:56 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma004467; Tue Apr 26 05:05:50 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 26 Apr 94 17:57:24 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404260857.AA06015@necom830.cc.titech.ac.jp> Subject: Re: SIPP Routing Header & security & Re: DNS security draft To: Theodore Ts'o Date: Tue, 26 Apr 94 17:57:23 JST Cc: "Terry, L., Davis, P.E., Boeing, Computer, Services, Bellevue, WA"@necom830.cc.titech.ac.jp, tld5032@commanche.ca.boeing.com, dns-security@tis.com, big-Internet@munnari.oz.au, sipp@sunroof2.eng.sun.com, paul@vix.com, dee@skidrow.lkg.dec.com In-Reply-To: <9404251616.AA11885@tsx-11.MIT.EDU>; from "Theodore Ts'o" at Apr 25, 94 12:16 pm X-Mailer: ELM [version 2.3 PL11] > Don't get me wrong --- I think software patents and algorithm patents > are particularily evil, and Congress should wake up and ban the Patent > Office from issuing any more of them. From a purely political point of view, the better approach is to try to bankrupt RSA DSI by not paying to them. > But I also think we need to wake > up and face reality. The Internet needs public key cryptography --- > badly; and if making peace with RSADSI is what's required until the > patent runs out in a few more years, then we should do what is necessary > to do so. What's wrong with ElGamal? > Unfortunately, public key cryptography is a key technology, without > which, many things in cryptography and security architecture become > much harder. Public key makes management issue of secret data much easier. Other things won't be affected by it. Modularized secure DNS which enables both RSA, shared secret and KDC is easy to construct. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa09664; 26 Apr 94 13:37 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13530; Tue, 26 Apr 94 13:37:09 EDT Received: by relay.tis.com; id AA09447; Tue, 26 Apr 94 13:38:23 EDT Received: from gw.home.vix.com(192.5.5.1) by relay via smap (V1.3mjr) id sma009440; Tue Apr 26 13:38:07 1994 Received: by gw.home.vix.com id AA00453; Tue, 26 Apr 94 09:36:11 -0700 Date: Tue, 26 Apr 94 09:36:11 -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: Algorithms ( was Re: Security AD's assesment re RSAREF licensing ) Organization: Vixie Enterprises Message-Id: References: <9404260237.AA17332@skidrow.lkg.dec.com> Nntp-Posting-Host: office.home.vix.com In-Reply-To: dee@skidrow.lkg.dec.com's message of 25 Apr 1994 20:24:00 -0700 just a short followup to donald's message: >Doesn't it make more sense to adopt the technically superior algorithm >which is completely unrestricted outside the US and will be >effectively free for the vast majority of US users? Is saving just >that small fraction of US users that will have to pay a small fee for >a few years worth going with an obviously inferior algorithm? i think RSA's license existing terms are exceptionally generous, and i also think that they deserve to be compensated for their efforts in creating the technology. i also think that the RSA technology is vastly superior to any alternative i know of. so i certainly won't debate you or anyone on any of those points. what concerns me is that when the IAB approves a protocol, it is actually more or less "legislating" its use. legislating the use of patented technology is, no matter how good the technology or how generous the terms, still a pretty dicey business. even if they are only paid a small amount per system sold with RSAREF-linked BIND, and a small amount by each network service provider who uses an RSAREF-linked BIND to sell name service to customers, that's still going to be a fair amount of money going to RSA. even if it were a token amount, we have to think long and hard about essentially _requiring_ that any real-world DNS user in the post-security world pay, directly or indirectly, royalties to some central authority. this is the first instance i know of where we're talking about requiring royalties at this level. and let me be clear as to what i mean by "requiring" the royalties; i'll use ethernet as a comparison. the RFC that describes the format of IP frames when encapsulated in Ethernet frames says _nothing_ about local area networks in general. if someone wanted to use IP on LANs and did not want to pay for Ethernet's royalties, they could choose some other LAN technology and just put their IP frames on _that_. the Ethernet/IP RFC says "if you want to use Ethernet, here's how you do it". the Secure DNS RFC will say "if you want to use Secure DNS, you MUST use RSA, you MUST pay for it, and by the way, here's how you do it." even PEM, which is perhaps a more similar case since it already involves RSA, is merely "if you want to do Secure Mail, ONE WAY TO DO IT is with PEM, which you must pay for, etc." the fact that "the vast majority of IP users" won't have to pay helps but it does not change the fundamental nature of the equation. this isn't deadly, it just requires some extra consideration. i'm on the hook for some action in this area and i should probably be working on _that_ rather than posting here. but i wanted to follow up on donald's point, however briefly. -- Paul Vixie Redwood City, CA decwrl!vixie!paul   Received: from sol.tis.com by magellan.TIS.COM id aa06140; 26 Apr 94 6:12 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA20291; Tue, 26 Apr 94 06:12:08 EDT Received: by relay.tis.com; id AA04853; Tue, 26 Apr 94 06:13:23 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma004848; Tue Apr 26 06:12:44 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 26 Apr 94 19:05:20 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404261005.AA06287@necom830.cc.titech.ac.jp> Subject: Re: Algorithms ( was Re: Security AD's assesment re RSAREF licensing ) To: "Donald E. Eastlake 3rd" Date: Tue, 26 Apr 94 19:05:18 JST Cc: kent@bbn.com, dns-security@tis.com In-Reply-To: <9404260237.AA17332@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Apr 25, 94 10:37 pm X-Mailer: ELM [version 2.3 PL11] > > Perhaps to the surprize of many, I agree with the general > >thrust of your statement, i.e., that PEM may not be a good precedent > >for adopting RSA for the DNS, but for different reasons. > > > >... > > > > For exmaple, ElGamal is an alternative signature algorithm > >which is not itself patented, but which is embraced by the fundamental > >Diffie-Hellman public key patent that expires in 1997 (I believe). > >ElGamal is not very efficient, but it is an alternative that has a > >shorter duration patent status relative to RSA. > > Looks to me like ElGamal would produce signatures that were twice as > big Wrong. Agaist the simple enumeration attack, ElGamal with a 512 bit prime which requires a 1024 bit signature is just as secure as RSA with two 512 bit primes which also requires a 1024 bit signature. So, it is generally believed (actual proof is as difficult as proving both RSA and Elgamal are broken, of course) that, for authentication, where signature on 128 bit MD5 is considered to be enough, ElGamal signature is as compact as that of RSA. The difference is that, to encrypt 512 bit of data, ElGamal needs 1024 bits, while RSA needs 512 bits only. That is, RSA is twice more compact than ElGamal for confidentiality. > and took at least a *hundred* and in some cases over a *thousand* > times more computation effort to verify than profiled RSA. That's true. But, in the security conscious enviroment where secure DNS is required, we need to compute a lot of on-line signature outside of DNS. Generation of RSA signature is almost as slow as generation of signature and verification of ElGamal. So, if ElGamal is unusably slow, RSA is also unusable, isn't it? Fortunately, the working set of the computation is quite small and completely included in on-chip cache. That is, signature computation speed is assured to become faster and faster as CPU speed increases. > > The DSA, a variant of ElGamal, is covered by a much more > Most of the world is outside of the US. Besides its poor performance, > would it really make sense to standardize for the Global DNS on > something like DSA with patent royalties in much of the rest of the > world until 2008+ ? I know nothing about DSA, but are there any reason to use it? It seems to me that ElGamal is good enough. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa14245; 26 Apr 94 16:15 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA27633; Tue, 26 Apr 94 16:14:36 EDT Received: by relay.tis.com; id AA11289; Tue, 26 Apr 94 16:15:49 EDT Received: from tsx-11.mit.edu(18.172.1.2) by relay via smap (V1.3mjr) id sma011280; Tue Apr 26 16:15:15 1994 Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA00717; Tue, 26 Apr 94 16:14:25 EDT Date: Tue, 26 Apr 94 16:14:25 EDT From: Theodore Ts'o Message-Id: <9404262014.AA00717@tsx-11.MIT.EDU> To: Paul A Vixie Cc: dns-security@tis.com In-Reply-To: Paul A Vixie's message of Tue, 26 Apr 94 09:36:11 -0700, Subject: Re: Algorithms ( was Re: Security AD's assesment re RSAREF licensing ) Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Date: Tue, 26 Apr 94 09:36:11 -0700 From: Paul A Vixie not want to pay for Ethernet's royalties, they could choose some other LAN technology and just put their IP frames on _that_. the Ethernet/IP RFC says "if you want to use Ethernet, here's how you do it". the Secure DNS RFC will say "if you want to use Secure DNS, you MUST use RSA, you MUST pay for it, and by the way, here's how you do it." You seem to be making the assumption that everyone will be forced to use Secure DNS. Let's project out 5 years. Clients that don't use secure DNS will still be able to do name resolution, although their requests might not be secure. At some point, it might be the case that authoritative name servers won't be trusted unless they're running Secure DNS. But this is a much smaller problem, since you generally need to be some sort of wizard to run a authoratative name server anyway, and often the network provider runs the authoratative nameserver for most of its smaller sites anyway. And, of course, any site who can pull RSAREF will be able to compile their own Secure DNS server for their authoratative name server. Also, RSA has in the past granted free use of its patent for the purposes of verifying signatures. If we can get a similar deal, then we'd be all set for the workstation market. - Ted   Received: from sol.tis.com by magellan.TIS.COM id aa14286; 26 Apr 94 16:27 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA29894; Tue, 26 Apr 94 16:26:40 EDT Received: by relay.tis.com; id AA11436; Tue, 26 Apr 94 16:27:55 EDT Received: from tsx-11.mit.edu(18.172.1.2) by relay via smap (V1.3mjr) id sma011429; Tue Apr 26 16:27:31 1994 Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA00886; Tue, 26 Apr 94 16:25:38 EDT Date: Tue, 26 Apr 94 16:25:38 EDT From: Theodore Ts'o Message-Id: <9404262025.AA00886@tsx-11.MIT.EDU> To: Masataka Ohta Cc: "Terry, L., Davis, P.E., Boeing, Computer, Services, Bellevue,\ WA"@necom830.cc.titech.ac.jp, tld5032@commanche.ca.boeing.com, dns-security@tis.com, big-Internet@munnari.oz.au, sipp@sunroof2.eng.sun.com, paul@vix.com, dee@skidrow.lkg.dec.com In-Reply-To: Masataka Ohta's message of Tue, 26 Apr 94 17:57:23 JST, <9404260857.AA06015@necom830.cc.titech.ac.jp> Subject: Re: SIPP Routing Header & security & Re: DNS security draft Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 From: Masataka Ohta Date: Tue, 26 Apr 94 17:57:23 JST What's wrong with ElGamal? 1) It doesn't provide support for data hiding. RSA does. While this is not required for DNS per se, having support for encryption would allow us to leverage the DNS key hierarchy for many other things, including IP security. With RSA, the keys that are used for secure DNS can also be used to establish secure data exchange keys for encryption purposes. El Gamal does not provide this capability. 2) El Gamal is also subject to U.S. patents: From the "Answers to FREQUENTLY ASKED QUESTIONS About Today's Cryptography", published by RSA Data Security: In a recent case, for example, PKP brought suit against the TRW Corporation which was using public-key cryptography (the ElGamal system) without a license; TRW claimed it did not need to license. In June 1992 a settlement was reached in which TRW agreed to license to the patents. Either way, vendors will have to fork some amount of money over to RSA DSI. Public key makes management issue of secret data much easier. Other things won't be affected by it. Modularized secure DNS which enables both RSA, shared secret and KDC is easy to construct. It may be easy to construct; a shared secret system (like Kerberos) simply can't be maintained or administered at large scales, however. KDC's are primarily good for a single site, or a few sites. They don't work over the entire Internet, and that's the problem that we're trying to solve. - Ted   Received: from sol.tis.com by magellan.TIS.COM id aa14324; 26 Apr 94 16:50 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02247; Tue, 26 Apr 94 16:49:48 EDT Received: by relay.tis.com; id AA11737; Tue, 26 Apr 94 16:51:03 EDT Received: from gw.home.vix.com(192.5.5.1) by relay via smap (V1.3mjr) id sma011729; Tue Apr 26 16:50:37 1994 Received: by gw.home.vix.com id AA06227; Tue, 26 Apr 94 13:49:54 -0700 Message-Id: <9404262049.AA06227@gw.home.vix.com> X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: dns-security@tis.com, big-Internet@munnari.oz.au, sipp@sunroof2.eng.sun.com Reply-To: paul@vix.com Subject: Re: SIPP Routing Header & security & Re: DNS security draft In-Reply-To: Your message of "Tue, 26 Apr 1994 16:25:38 EDT." <9404262025.AA00886@tsx-11.MIT.EDU> Date: Tue, 26 Apr 1994 13:49:53 -0700 From: Paul A Vixie I have several requests. First, if you reply to a message on the list, edit the reply headers to remove all the individuals who are themselves probably on the list. Wide-area dupli- cate suppression doesn't work, and I don't like getting N+1 copies of each msg which is a distant descendent of some thread I've participated in. Second, please think very carefully about sending any message to more than one list. There is a huge overlap in the memberships, and charters, of SIPP, BigInternet, and dns-security. Sending to one and only one of these lists is probably enough for most topics. I'm making an exception for this message since it's meta-topical rather than topical. Third, well, #3 is topical so I'll make it into a separate message.   Received: from sol.tis.com by magellan.TIS.COM id aa14364; 26 Apr 94 17:09 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA04227; Tue, 26 Apr 94 17:08:56 EDT Received: by relay.tis.com; id AA12053; Tue, 26 Apr 94 17:10:11 EDT Received: from adrastea.lcs.mit.edu(18.26.0.159) by relay via smap (V1.3mjr) id sma012043; Tue Apr 26 17:09:16 1994 Received: by adrastea.lcs.mit.edu; id AA23432; Tue, 26 Apr 1994 17:07:59 -0400 Date: Tue, 26 Apr 1994 17:07:59 -0400 From: Garrett Wollman Message-Id: <9404262107.AA23432@adrastea.lcs.mit.edu> To: dns-security@tis.com, big-Internet@munnari.oz.au, sipp@sunroof2.eng.sun.com Reply-To: wollman@lcs.mit.edu Subject: Re: SIPP Routing Header & security & Re: DNS security draft In-Reply-To: <9404262025.AA00886@tsx-11.MIT.EDU> References: <9404260857.AA06015@necom830.cc.titech.ac.jp> <9404262025.AA00886@tsx-11.MIT.EDU> < Return-Path: Message-Id: <9404270328.AA09765@necom830.cc.titech.ac.jp> Subject: Re: SIPP Routing Header & security & Re: DNS security draft To: dns-security@tis.com, big-internet@munnari.oz.au Date: Wed, 27 Apr 94 12:28:35 JST In-Reply-To: <9404262025.AA00886@tsx-11.MIT.EDU>; from "Theodore Ts'o" at Apr 26, 94 4:25 pm X-Mailer: ELM [version 2.3 PL11] > What's wrong with ElGamal? > > 1) It doesn't provide support for data hiding. It does, though the algorithms for confidentiality and for authentication are different. > With RSA, the keys that are used for secure DNS can also be used to > establish secure data exchange keys for encryption purposes. Wrong. For encryption purposes, you need keys for hosts or users. Secure DNS is now being deeveloped so that a zone, not a host in general, will have a key. > El Gamal does not provide this capability. It does. Two ElGamal algorithms for confidentiality and for authentication share the same public key. > 2) El Gamal is also subject to U.S. patents: I know. But it will expire 1997, much earlier than 2000. > Public key makes management issue of secret data much easier. Other > things won't be affected by it. Modularized secure DNS which enables > both RSA, shared secret and KDC is easy to construct. > > It may be easy to construct; a shared secret system (like Kerberos) > simply can't be maintained or administered at large scales, however. > KDC's are primarily good for a single site, or a few sites. They don't > work over the entire Internet, and that's the problem that we're trying > to solve. I merely pointed out that we can construct modularized secure DNS without technical difficulty. I'm not particulary in favour of the idea to use KDC or something like that till 1997 and ElGamal later. But, when any public key mechanism is proven to be broken, as some of the people are afraid of, KDC with conventional security model or something like that could be a refuge till a new algorithm prevails. If any public key mechanism is proven to be broken, we are valunerable till alternative secure algorithm is developpeed and installed within a name server, which will take a considerable amount of time, much longer than rewriting secure DNS RFC with a new algorithm. So, unless alternate secure algorithm is installed in name servers IN ADVANCE, algorithm independence is not meaningful. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa16163; 27 Apr 94 8:01 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA23637; Wed, 27 Apr 94 08:01:24 EDT Received: by relay.tis.com; id AA17106; Wed, 27 Apr 94 08:02:40 EDT Received: from mitsou.inria.fr(138.96.24.84) by relay via smap (V1.3mjr) id sma017101; Wed Apr 27 08:02:25 1994 Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA07199; Wed, 27 Apr 1994 14:06:07 +0200 Message-Id: <199404271206.AA07199@mitsou.inria.fr> To: Theodore Ts'o Cc: dns-security@tis.com Subject: Re: SIPP Routing Header & security & Re: DNS security draft In-Reply-To: Your message of "Tue, 26 Apr 1994 16:25:38 EDT." <9404262025.AA00886@tsx-11.MIT.EDU> Date: Wed, 27 Apr 1994 14:06:06 +0200 From: Christian Huitema => From: Masataka Ohta => Date: Tue, 26 Apr 94 17:57:23 JST => => What's wrong with ElGamal? => => 1) It doesn't provide support for data hiding. RSA does. While this => is not required for DNS per se, having support for encryption would => allow us to leverage the DNS key hierarchy for many other things, => including IP security. Uh? El Gamal's public key is 1/2 of Diffie Hellmann, does indeed provide for encryption... Christian Huitema   Received: from sol.tis.com by magellan.TIS.COM id aa17099; 27 Apr 94 10:32 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA29631; Wed, 27 Apr 94 10:32:16 EDT Received: by relay.tis.com; id AA18234; Wed, 27 Apr 94 10:33:33 EDT Received: from atc.boeing.com(130.42.28.80) by relay via smap (V1.3mjr) id sma018229; Wed Apr 27 10:32:42 1994 Received: by atc.boeing.com (5.57) id AA05808; Wed, 27 Apr 94 07:33:18 -0700 Received: from commanche.ca.boeing.com by splinter.boeing.com with SMTP (16.6/16.2) id AA07161; Wed, 27 Apr 94 07:33:03 -0700 Received: by commanche.ca.boeing.com (AIX 3.2/UCB 5.64/4.03.TLDavis.AIX_3.2.5) id AA25120; Wed, 27 Apr 1994 07:31:19 -0700 Message-Id: <9404271431.AA25120@commanche.ca.boeing.com> To: tytso@athena.mit.edu Cc: dns-security@tis.com, big-Internet@munnari.oz.au, sipp@sunroof2.eng.sun.com Subject: Re: SIPP Routing Header & security & Re: DNS security draft Date: Wed, 27 Apr 94 07:31:18 -0800 From: "Terry L. Davis P.E., Boeing Computer Services, Bellevue, WA" Ted > .........Like it or > not, whether or not we have an algorithm identifier field or not, in > order for this thing to work, the IETF is going to have to put a stake > in the ground and say that everyone is going to use this *one* > cryptographic algorithm. > I see nothing wrong with a "default" algorithm if we can change it. I cannot see that capability in the draft as it appears to be tightly written around RSA. I think the capability to switch away from a default algorithm is critical. At the same time, this capability would probably also allow those of us who wish to (or are required to) use our own alternates (between consenting adults of course!) to do so. > It's the same problem as the one that's facing the IPNG decision > process. Sometimes, you just have to pick one, and picking anything > protocol is better than not picking a protocol at all. > In any engineering problem, risk assessments must be made; that is are the consequences of failure as weighed against the cost of alternative designs or delays balanced. In this case, I personally think not and certainly do not agree that "anything is better than nothing". Should at some future date the single chosen technology be broken, all you are left with is "false security" which is worse than "no security". > For all of the people who have been bitching and moaning --- if you > don't like the current proposal, then come up with something new! > Unfortunately, public key cryptography is a key technology, without > which, many things in cryptography and security architecture become > much harder. > A lot of us are thinking about alternatives and I don't think any of us want to see the work that Donald and Charles started not be carried to completion. I not so concerned about ease as I am long term durability. > Don't get me wrong --- I think software patents and algorithm patents > are particularily evil, and Congress should wake up and ban the Patent > Office from issuing any more of them. > Evil ??? Needs work, Definitely!!! > - Ted > Take care | Terry L. Davis | Boeing Computer Services, Bellevue, WA | | 206-957-5325 | BOEING EMAIL: tld5032@commanche.ca.boeing.com. | | INTERNET EMAIL: tld5032@atc.boeing.com. | --------------- Wednesday April 27,1994 07:29 AM PDT ------------- == As always, the above cannot be construed as representing BOEING, == == the thoughts, comments, and ideas contained herein are mine alone! ==   Received: from sol.tis.com by magellan.TIS.COM id aa18597; 27 Apr 94 11:36 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02668; Wed, 27 Apr 94 11:35:52 EDT Received: by relay.tis.com; id AA18862; Wed, 27 Apr 94 11:37:08 EDT Received: from atc.boeing.com(130.42.28.80) by relay via smap (V1.3mjr) id sma018852; Wed Apr 27 11:36:38 1994 Received: by atc.boeing.com (5.57) id AA12434; Wed, 27 Apr 94 08:35:59 -0700 Received: from commanche.ca.boeing.com by splinter.boeing.com with SMTP (16.6/16.2) id AA08369; Wed, 27 Apr 94 08:35:44 -0700 Received: by commanche.ca.boeing.com (AIX 3.2/UCB 5.64/4.03.TLDavis.AIX_3.2.5) id AA22093; Wed, 27 Apr 1994 08:34:01 -0700 Message-Id: <9404271534.AA22093@commanche.ca.boeing.com> To: dee@skidrow.lkg.dec.com Cc: dns-security@tis.com, big-Internet@munnari.oz.au, sipp@sunroof2.eng.sun.com Subject: Re: SIPP Routing Header & security & Re: DNS security draft In-Reply-To: (Your message of Mon, 25 Apr 94 13:14:53 D.) <9404251714.AA13136@skidrow.lkg.dec.com> Date: Wed, 27 Apr 94 08:34:01 -0800 From: "Terry L. Davis P.E., Boeing Computer Services, Bellevue, WA" Donald > Nonsense. Pick up the telephone. Call RSA Data Systems Inc. in > Redwood City, California. (Or have your lawyer call their lawyer.) > They will confirm that any company can use RSA internally, use PEM to > communicate with other companies, etc., all in a profit making > setting. The only thing RSA is still asking for royalties for is > people who want to sell software incorporating RSA or sell a service > where RSA is an essential part. > Given the option to discuss issues with lawyers (most of whom I can almost never understand) or to design in a way that I may be able to leave them out, I always opt to try to leave them out. Whether I'm selling aircraft, video services, or personal information devices, in the near future all will rely on incorporation of DNS into their core systems. You're saying that they won't want any royalties from my airplane, my home entertain system, or my home computer, all of which would utilize their technology via DNS? That's not quite how I understood their statements. > Whatever algoritm is chosen, the people who want to interoperate will > all have to speak it. Everyone knows you will need a method to roll > over to a new algorithm when / if that is necessary. > As I responded to "Ted Ts'o", I have no problem with a "default algorithm", but I see no way to incorporate any alternative algorithm into DNS or to "roll over to a new algorithm" as the draft is currently written. > So you want multiple algorithms so that those who want to interoperate > will have to speak all of them so that if *any* *one* *of* *them* > is broken, things will fall apart? Sounds like a great way to weaken > network security to me. > Point well taken! But in some cases, groups even countries may be required to NOT use the chosen technology but something else more "politically" acceptable. Governments (and large corporations, especially if they're into money) tend to be paranoid about crytography. I'm fairly sure that not all the world governments would allow comm systems utilizing this crytographic technology to be deployed within their borders. Remember our own country requires anyone selling good crytography to be hold a federal "armaments manufacturers" license and places their exports under even tighter restrictions than just selling missles or bombs. > (Of course there should also be a way for consenting adults to use > whatever algorithm they want, not that you could stop them anyway.) > That's what I am looking. I think it would also solve the "roll over" problem. > Donald > Take care | Terry L. Davis | Boeing Computer Services, Bellevue, WA | | 206-957-5325 | BOEING EMAIL: tld5032@commanche.ca.boeing.com. | | INTERNET EMAIL: tld5032@atc.boeing.com. | --------------- Wednesday April 27,1994 08:31 AM PDT ------------- == As always, the above cannot be construed as representing BOEING, == == the thoughts, comments, and ideas contained herein are mine alone! ==   Received: from sol.tis.com by magellan.TIS.COM id aa21417; 27 Apr 94 14:38 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA15146; Wed, 27 Apr 94 14:38:22 EDT Received: by relay.tis.com; id AA20402; Wed, 27 Apr 94 14:39:39 EDT Received: from ginger.lcs.mit.edu(18.26.0.82) by relay via smap (V1.3mjr) id sma020395; Wed Apr 27 14:39:09 1994 Received: by ginger.lcs.mit.edu id AA13825; Wed, 27 Apr 94 14:38:13 -0400 Date: Wed, 27 Apr 94 14:38:13 -0400 From: Noel Chiappa Message-Id: <9404271838.AA13825@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, dns-security@tis.com Subject: Re: SIPP Routing Header & security & Re: DNS security draft Cc: jnc@ginger.lcs.mit.edu I see nothing wrong with a "default" algorithm if we can change it. I cannot see that capability in the draft as it appears to be tightly written around RSA. ... Should at some future date the single chosen technology be broken, all you are left with is "false security" which is worse than "no security". For what it's worth, the paper today reports that group of researchers have factored a 129-digit number (of the kind used by RSA). 25 years down the line, when we all have 1M-CPU connection machines in our PDA's, we might want something better.... Noel   Received: from sol.tis.com by magellan.TIS.COM id aa21969; 27 Apr 94 16:24 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA25845; Wed, 27 Apr 94 16:24:16 EDT Received: by relay.tis.com; id AA21341; Wed, 27 Apr 94 16:25:32 EDT Received: from tipper.oit.unc.edu(152.2.22.85) by relay via smap (V1.3mjr) id sma021336; Wed Apr 27 16:25:20 1994 Received: from localhost.oit.unc.edu by tipper.oit.unc.edu (SMI4.1/FvK 1.02) id AA19960; Wed, 27 Apr 94 16:24:00 EDT Message-Id: <9404272024.AA19960@tipper.oit.unc.edu> To: Noel Chiappa Cc: big-internet@munnari.oz.au, dns-security@tis.com Subject: Re: SIPP Routing Header & security & Re: DNS security draft In-Reply-To: Your message of "Wed, 27 Apr 94 14:38:13 EDT." <9404271838.AA13825@ginger.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 27 Apr 94 16:23:59 -0400 From: Simon E Spero Even with the new techniques, factorisation still gets exponentially harder as you add more digits. 129 digits is only 429 bits, so 512 bit keys are still pretty safe. By the way, it's interesting to note that the folks who did the factorisation donated the $100 prize money to the FSF. Maybe we can apply that to the problem of address space wasterels. If we set up a tax for every IP address allocated to an organisation that isn't pingable from (say) venera.isi.edu, and give all the proceeds to the FSF, we'd get a bunch of addresses back, a reduction in the number of firewalls, and a whole bunch of new free software which is one of the main wins of the net anyway.   Received: from sol.tis.com by magellan.TIS.COM id aa22429; 27 Apr 94 17:21 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA01561; Wed, 27 Apr 94 17:20:47 EDT Received: by relay.tis.com; id AA21910; Wed, 27 Apr 94 17:22:03 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma021902; Wed Apr 27 17:21:11 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA14319; Wed, 27 Apr 94 14:13:35 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA04728; Wed, 27 Apr 1994 17:15:20 -0400 Message-Id: <9404272115.AA04728@skidrow.lkg.dec.com> To: "Terry L. Davis P.E., Boeing Computer Services, Bellevue, WA" Cc: dns-security@tis.com Subject: Re: SIPP Routing Header & security & Re: DNS security draft In-Reply-To: Your message of "Wed, 27 Apr 94 08:34:01 -0800." <9404271534.AA22093@commanche.ca.boeing.com> Date: Wed, 27 Apr 94 17:15:20 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: "Terry L. Davis P.E., Boeing Computer Services, Bellevue, WA" To: dee Cc: dns-security@tis.com, big-Internet@munnari.oz.au, sipp@sunroof2.eng.sun.com In-Reply-To: (Your message of Mon, 25 Apr 94 13:14:53 D.) <9404251714.AA13136@skidrow.lkg. dec.com> > >Donald > >> Nonsense. Pick up the telephone. Call RSA Data Systems Inc. in >> Redwood City, California. (Or have your lawyer call their lawyer.) >> They will confirm that any company can use RSA internally, use PEM to >> communicate with other companies, etc., all in a profit making >> setting. The only thing RSA is still asking for royalties for is >> people who want to sell software incorporating RSA or sell a service >> where RSA is an essential part. >> >Given the option to discuss issues with lawyers (most of whom I can >almost never understand) or to design in a way that I may be able to >leave them out, I always opt to try to leave them out. Whether I'm >selling aircraft, video services, or personal information devices, >in the near future all will rely on incorporation of DNS into their >core systems. You're saying that they won't want any royalties from >my airplane, my home entertain system, or my home computer, all of >which would utilize their technology via DNS? That's not quite how I >understood their statements. If you simply call RSA and ask for Kurt Stammberger you get a perfectly reasonable human being who doesn't sound like a lawyer although, for all I know, he may be one. Currently PKP says that all public key technologies are covered by patent in the United States so there is no technique you can use that is completely clear of encumberances. Yes, I'm saying that if you use RSAREF and you are not selling software incorporating it and not selling a service that requires it, RSA won't want any royalties. Most uses seem to fit this category. Even if you were an Internet service provider and offered DNS service for your customers, I don't think the current RSA policy would require any royalties unless you required them to sign up for your DNS service or assessed a separate charge for the DNS service. Certainly if you are a company, educational institution, non-profit org, etc., and just run you own DNS domain in the normal fashion but use secure DNS based on RSAREF, then you clearly don't owe any royalties. >> Whatever algoritm is chosen, the people who want to interoperate will >> all have to speak it. Everyone knows you will need a method to roll >> over to a new algorithm when / if that is necessary. >> >As I responded to "Ted Ts'o", I have no problem with a "default >algorithm", but I see no way to incorporate any alternative algorithm >into DNS or to "roll over to a new algorithm" as the draft is currently >written. I'll fix that. >> So you want multiple algorithms so that those who want to interoperate >> will have to speak all of them so that if *any* *one* *of* *them* >> is broken, things will fall apart? Sounds like a great way to weaken >> network security to me. >> >Point well taken! But in some cases, groups even countries may be >required to NOT use the chosen technology but something else more >"politically" acceptable. Governments (and large corporations, >especially if they're into money) tend to be paranoid about crytography. >I'm fairly sure that not all the world governments would allow comm >systems utilizing this crytographic technology to be deployed within >their borders. Remember our own country requires anyone selling good >crytography to be hold a federal "armaments manufacturers" license >and places their exports under even tighter restrictions than just >selling missles or bombs. I'm not aware of any country that would restrict the algorithms used privately. You may have to give copies of your hardware/software/keys to the government but after you do that, they don't care. >... >> Donald > | Terry L. Davis | Boeing Computer Services, Bellevue, WA | > | 206-957-5325 | BOEING EMAIL: tld5032@commanche.ca.boeing.com. | > | INTERNET EMAIL: tld5032@atc.boeing.com. | > --------------- Wednesday April 27,1994 08:31 AM PDT ------------- >== As always, the above cannot be construed as representing BOEING, == >== the thoughts, comments, and ideas contained herein are mine alone! == Donald   Received: from sol.tis.com by magellan.TIS.COM id aa22460; 27 Apr 94 17:28 EDT Received: from happy.tis.com by tis.com (4.1/SUN-5.64) id AA01753; Wed, 27 Apr 94 17:28:25 EDT Message-Id: <9404272128.AA01753@tis.com> To: Noel Chiappa Cc: big-internet@munnari.oz.au, dns-security@tis.com Subject: Re: SIPP Routing Header & security & Re: DNS security draft In-Reply-To: Your message of "Wed, 27 Apr 94 14:38:13 EDT." <9404271838.AA13825@ginger.lcs.mit.edu> Date: Wed, 27 Apr 94 17:28:19 -0400 From: Stephen D Crocker > From: Noel Chiappa > To: big-internet@munnari.oz.au, dns-security@tis.com > cc: jnc@ginger.lcs.mit.edu > Date: Wed, 27 Apr 94 14:38:13 -0400 > Subject: Re: SIPP Routing Header & security & Re: DNS security draft > ... > For what it's worth, the paper today reports that group of > researchers have factored a 129-digit number (of the kind used by > RSA). 25 years down the line, when we all have 1M-CPU connection > machines in our PDA's, we might want something better.... > > Noel > This has been known for a few weeks. There's nothing worrisome, if that's the implicit question. 129 digits is 430 bits. Don't use RSA keys that short. 512 is the least anyone would use. 640, 768 and 1024 are more conservative key sizes that are in increasingly common use. These are all *much* harder to crack (factor) than 430 bits. Except for special exercises like the one reported, or organizations with exceptional resources like NSA, even cracking 430 bits is not within ordinary reach. On the other side of the coin, 512 is exportable, so that's considered unacceptable if you really want security. (Exportable for encryption. Any length is exportable for signature.) Steve   Received: from sol.tis.com by magellan.TIS.COM id aa28197; 28 Apr 94 14:32 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA00213; Thu, 28 Apr 94 14:31:57 EDT Received: by relay.tis.com; id AA01639; Thu, 28 Apr 94 14:33:14 EDT Received: from netmail.microsoft.com(131.107.1.3) by relay via smap (V1.3mjr) id sma001627; Thu Apr 28 14:32:30 1994 Received: by netmail.microsoft.com (5.65/25-eef) id AA14150; Thu, 28 Apr 94 11:31:07 -0700 Message-Id: <9404281831.AA14150@netmail.microsoft.com> Received: by netmail using fxenixd 1.0 Thu, 28 Apr 94 11:31:06 PDT X-Msmail-Message-Id: B714071C X-Msmail-Conversation-Id: B714071C From: Paul Leach To: dee@skidrow.lkg.dec.com, sipp-request@sunroof2.eng.sun.com Date: Thu, 28 Apr 94 09:24:24 TZ Subject: Re: SIPP Routing Header & security & Re: DNS security draft Cc: big-Internet@munnari.oz.au, dns-security@tis.com, sipp@sunroof2.eng.sun.com ---------- | From: "Terry L. Davis P.E., Boeing Computer Services, | Bellevue, WA" | To: | Cc: ; ; | | Subject: Re: SIPP Routing Header & security & Re: DNS security draft | Date: Wednesday, April 27, 1994 8:34AM | | > Whatever algoritm is chosen, the people who want to interoperate will | > all have to speak it. Everyone knows you will need a method to roll | > over to a new algorithm when / if that is necessary. | > | As I responded to "Ted Ts'o", I have no problem with a "default | algorithm", but I see no way to incorporate any alternative algorithm | into DNS or to "roll over to a new algorithm" as the draft is currently | written. | | > So you want multiple algorithms so that those who want to interoperate | > will have to speak all of them so that if *any* *one* *of* *them* | > is broken, things will fall apart? Sounds like a great way to weaken | > network security to me. This is true, but overlooks some context. If there are several algorithms, but if for any party with whom I might want to communicate there is exactly one that I must use, then breaking one algorithm only exposes the parties that use that algorithm. So, for example, the paranoid company referred to below might use one (allegedly stronger than the default) algorithm internally, but another with outside parties. The same principle applies to using differnet algorithms for different purposes. Thus, all EFT/EDIF mail could use one algorithm, and mail discussing acquisition of another company a second. Etc. | > | Point well taken! But in some cases, groups even countries may be | required to NOT use the chosen technology but something else more | "politically" acceptable. Governments (and large corporations, | especially if they're into money) tend to be paranoid about crytography. | I'm fairly sure that not all the world governments would allow comm | systems utilizing this crytographic technology to be deployed within | their borders. Remember our own country requires anyone selling good | crytography to be hold a federal "armaments manufacturers" license | and places their exports under even tighter restrictions than just | selling missles or bombs. Paul   Received: from sol.tis.com by magellan.TIS.COM id aa22932; 27 Apr 94 23:37 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA10663; Wed, 27 Apr 94 23:37:08 EDT Received: by relay.tis.com; id AA24636; Wed, 27 Apr 94 23:38:26 EDT Received: from ginger.lcs.mit.edu(18.26.0.82) by relay via smap (V1.3mjr) id sma024631; Wed Apr 27 23:38:04 1994 Received: by ginger.lcs.mit.edu id AA16374; Wed, 27 Apr 94 23:36:30 -0400 Date: Wed, 27 Apr 94 23:36:30 -0400 From: Noel Chiappa Message-Id: <9404280336.AA16374@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, dns-security@tis.com Subject: Re: SIPP Routing Header & security & Re: DNS security draft Cc: jnc@ginger.lcs.mit.edu > ...a group of researchers have factored a 129-digit number (of the kind > used by RSA). 25 years down the line, when we all have 1M-CPU connection > machines in our PDA's, we might want something better... There's nothing worrisome, if that's the implicit question. 129 digits is 430 bits. Don't use RSA keys that short. 512 is the least anyone would use. 640, 768 and 1024 are more conservative key sizes that are in increasingly common use. These are all *much* harder to crack (factor) than 430 bits. I am somewhat familiar with longer key-lengths and what that does to computationally intensive attacks. What I found illuminating (and failed to post, sorry) was that when the problem was first posed, when RSA was discovered in the late 70's, it was thought that it wouldn't be solved until "well into the next century". I think there might be a lesson there. I'm not saying I expect someone to find a magic fast factoring algorithm any time soon, or that anyone's likely to find a hole in RSA anytime soon. However, to do designs based on the assumption that RSA (even the longer key lengths you mention) will be good for all time is a bit unwise of us, (or perhaps even arrogant, as writers on technology disasters from the Titanic onward point out), don't you think? On the other side of the coin, 512 is exportable, so that's considered unacceptable if you really want security. (Exportable for encryption. Any length is exportable for signature.) Facinating. Let me make sure I get this straight. RSA for privacy with key lengths of less than 512 is OK'd for export, but not DES? Noel   Received: from sol.tis.com by magellan.TIS.COM id aa23554; 28 Apr 94 8:32 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA21932; Thu, 28 Apr 94 08:31:40 EDT Received: by relay.tis.com; id AA27585; Thu, 28 Apr 94 08:32:58 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma027580; Thu Apr 28 08:32:21 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA05104; Thu, 28 Apr 94 05:28:30 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA08820; Thu, 28 Apr 1994 08:30:18 -0400 Message-Id: <9404281230.AA08820@skidrow.lkg.dec.com> To: Noel Chiappa Cc: dns-security@tis.com Subject: Re: SIPP Routing Header & security & Re: DNS security draft In-Reply-To: Your message of "Wed, 27 Apr 94 23:36:30 EDT." <9404280336.AA16374@ginger.lcs.mit.edu> Date: Thu, 28 Apr 94 08:30:17 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: Noel Chiappa To: big-internet@munnari.oz.au, dns-security@tis.com > >... > On the other side of the coin, 512 is exportable, so that's considered > unacceptable if you really want security. (Exportable for encryption. > Any length is exportable for signature.) > >Facinating. Let me make sure I get this straight. RSA for privacy with key >lengths of less than 512 is OK'd for export, but not DES? Gives you some idea how hard NSA expects it to be to factor 512 bit numbers in the medium future, doesn't it. > Noel Donald   Received: from sol.tis.com by magellan.TIS.COM id aa26878; 28 Apr 94 11:45 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA09029; Thu, 28 Apr 94 11:45:18 EDT Received: by relay.tis.com; id AA29530; Thu, 28 Apr 94 11:46:35 EDT Received: from unknown(137.65.4.1) by relay via smap (V1.3mjr) id sma029524; Thu Apr 28 11:46:33 1994 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA04833; Thu, 28 Apr 94 09:51:00 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB14056; Thu, 28 Apr 94 08:44:27 PDT Date: Thu, 28 Apr 94 08:44:27 PDT Message-Id: <9404281544.AB14056@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Masataka Ohta From: Greg Minshall Subject: Re: SIPP Routing Header & security & Re: DNS security draft Cc: dns-security@tis.com Masataka, >Secure DNS is now being deeveloped so that a zone, not a host in general, >will have a key. The Eastlake/Kaufmann scheme allows zones, hosts, even users, to have (public) keys. >I know. But it will expire 1997, much earlier than 2000. Three years == (approximately) three days, in my humble opinion, in this area. (Words of the form likely to come back and haunt one...) Greg   Received: from sol.tis.com by magellan.TIS.COM id aa27159; 28 Apr 94 12:15 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13236; Thu, 28 Apr 94 12:14:36 EDT Received: by relay.tis.com; id AA29930; Thu, 28 Apr 94 12:15:53 EDT Received: from tsx-11.mit.edu(18.172.1.2) by relay via smap (V1.3mjr) id sma029920; Thu Apr 28 12:15:27 1994 Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA10972; Thu, 28 Apr 94 12:06:08 EDT Date: Thu, 28 Apr 94 12:06:08 EDT From: Theodore Ts'o Message-Id: <9404281606.AA10972@tsx-11.MIT.EDU> To: Masataka Ohta Cc: dns-security@tis.com, big-internet@munnari.oz.au In-Reply-To: Masataka Ohta's message of Wed, 27 Apr 94 12:28:35 JST, <9404270328.AA09765@necom830.cc.titech.ac.jp> Subject: Re: SIPP Routing Header & security & Re: DNS security draft Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 From: Masataka Ohta Date: Wed, 27 Apr 94 12:28:35 JST > What's wrong with ElGamal? > > 1) It doesn't provide support for data hiding. It does, though the algorithms for confidentiality and for authentication are different. You're right. I was confused; most of my knowledge of El Gamal comes from the DSS. > With RSA, the keys that are used for secure DNS can also be used to > establish secure data exchange keys for encryption purposes. Wrong. For encryption purposes, you need keys for hosts or users. Secure DNS is now being deeveloped so that a zone, not a host in general, will have a key. We can use the same RR for distributing the key for a zone to distribute the key for a host in general; that DNS information can be signed by zone key, which gives you the public key certification which you need. - Ted