Received: from sol.tis.com by magellan.TIS.COM id aa11921; 1 Apr 94 2:21 EST Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA04193; Fri, 1 Apr 94 02:21:15 EST Received: by relay.tis.com; id AA09657; Fri, 1 Apr 94 02:21:51 EST Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma009654; Fri Apr 1 02:21:48 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA25032; Thu, 31 Mar 94 23:18:02 -0800 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA21005; Fri, 1 Apr 1994 02:19:18 -0500 Message-Id: <9404010719.AA21005@skidrow.lkg.dec.com> To: Internet Assigned Number Authority Cc: dns-security@tis.com, dee@skidrow.lkg.dec.com Subject: SIG & RSA RRs Date: Fri, 01 Apr 94 02:19:17 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Jon, As we discussed, implementations of draft-ietf-dnssec-secext-01.txt will be starting shortly. Thus two DNS RR type numbers need to be assigned, one for the SIG (signture) RR type and one for the RSA (key) RR type. Thanks, 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 aa11929; 1 Apr 94 2:22 EST Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA04211; Fri, 1 Apr 94 02:22:14 EST Received: by relay.tis.com; id AA09663; Fri, 1 Apr 94 02:22:51 EST Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma009660; Fri Apr 1 02:22:24 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA25066; Thu, 31 Mar 94 23:19:01 -0800 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA21032; Fri, 1 Apr 1994 02:20:27 -0500 Message-Id: <9404010720.AA21032@skidrow.lkg.dec.com> To: dns-security@tis.com Cc: Paul Mockapetris , dee@skidrow.lkg.dec.com Subject: SIG RR location in responses Date: Fri, 01 Apr 94 02:20:27 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp I talked to Paul Mockapetris and he has no objection to the scheme proposed in the current dnssec draft on the placing of SIG in a response when the query did not specify SIGs. (It calls for putting the SIG in the answer section if it signs anything in the answer section, putting it in the authority section if it signs something in the authority section and nothing in the answer section, and putting it in the additional information section if it signs nothing in either the answer or authority sections.) 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 aa15537; 2 Apr 94 13:40 EST Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA25005; Sat, 2 Apr 94 13:40:41 EST Received: by relay.tis.com; id AA17938; Sat, 2 Apr 94 13:41:20 EST Received: from quark.isi.edu(128.9.208.208) by relay via smap (V1.3mjr) id sma017935; Sat Apr 2 13:40:43 1994 Received: from [128.9.32.193] (ppp3.isi.edu) by quark.isi.edu (5.65c/5.61+local-16) id ; Sat, 2 Apr 1994 10:37:44 -0800 Date: Sat, 2 Apr 1994 10:37:44 -0800 Message-Id: <199404021837.AA06041@quark.isi.edu> X-Sender: pvm@quark.isi.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Donald E. Eastlake 3rd (Beast)" , dns-security@tis.com From: pvm@isi.edu Subject: Re: SIG RR location in responses Cc: Paul Mockapetris , dee@skidrow.lkg.dec.com At 2:20 AM 4/1/94 -0500, Donald E. Eastlake 3rd (Beast) wrote: >I talked to Paul Mockapetris and he has no objection to the scheme >proposed in the current dnssec draft on the placing of SIG in a >response when the query did not specify SIGs. (It calls for putting >the SIG in the answer section if it signs anything in the answer >section, putting it in the authority section if it signs something in >the authority section and nothing in the answer section, and putting >it in the additional information section if it signs nothing in either >the answer or authority sections.) > >Donald > Don, I belive I said I had no objection to adding things to the additional section, in general, and other sections as appropriate. This isn't a blanket good idea; the effects of truncation and backward compatibility must be considered. paul paul USC/Information Sciences Institute 4676 Admiralty Way, Marina del Rey, CA 90292 310-822-1511 x285   Received: from sol.tis.com by magellan.TIS.COM id aa15805; 2 Apr 94 16:56 EST Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA27553; Sat, 2 Apr 94 16:55:57 EST Received: by relay.tis.com; id AA18478; Sat, 2 Apr 94 16:56:36 EST Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma018475; Sat Apr 2 16:55:54 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA08502; Sat, 2 Apr 94 13:52:18 -0800 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA23373; Sat, 2 Apr 1994 16:53:45 -0500 Message-Id: <9404022153.AA23373@skidrow.lkg.dec.com> To: pvm@isi.edu Cc: dns-security@tis.com Subject: Re: SIG RR location in responses In-Reply-To: Your message of "Sat, 02 Apr 94 10:37:44 PST." <199404021837.AA06041@quark.isi.edu> Date: Sat, 02 Apr 94 16:53:45 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Paul, From: pvm@isi.edu To: "Donald E. Eastlake 3rd (Beast)" , dns-security@tis.com >At 2:20 AM 4/1/94 -0500, Donald E. Eastlake 3rd (Beast) wrote: >>I talked to Paul Mockapetris and he has no objection to the scheme >>proposed in the current dnssec draft on the placing of SIG in a >>response when the query did not specify SIGs. (It calls for putting >>the SIG in the answer section if it signs anything in the answer >>section, putting it in the authority section if it signs something in >>the authority section and nothing in the answer section, and putting >>it in the additional information section if it signs nothing in either >>the answer or authority sections.) >>Donald >Don, I belive I said I had no objection to adding things to the additional >section, in general, and other sections as appropriate. This isn't a >blanket good idea; the effects of truncation and backward compatibility >must be considered. Sorry if I misrepresented you at all. I designed the current proposal as described above for a couple of reasons listed below. I don't see backward compatibility as an issues as a resolver will never see SIG RRs unless it explicitly asks for them or it is a security aware resolver talking to a security aware server and turns on the security desired bit in its query. The reasons for the current design were (1) I believe that in most cases all the RRs being exlicitly retrieved will fix inside the SIG. So when a security aware resolver and server are talking, the normal case will be that all of the explicity requested RRs will be surpressed and the "answer" will just consist of a SIG (or, in some cases, an RSA and a SIG). This being the case, it seems reasonable to put this SIG RR in the answer section. (2) Regardless of point 1, when operating in a secured mode, RRs are essentially useless unless they are signed. Thus the SIG that goes with any RRs in the answer setion is just as valuable as they are and intrisicly more valuable than anthing in the additional information section. Thus it should appear in the answer section to minimize any chance it would be truncated. >paul > >USC/Information Sciences Institute >4676 Admiralty Way, Marina del Rey, CA >90292 310-822-1511 x285 Donald   Received: from sol.tis.com by magellan.TIS.COM id aa17521; 3 Apr 94 14:15 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA07856; Sun, 3 Apr 94 14:15:28 EDT Received: by relay.tis.com; id AA21270; Sun, 3 Apr 94 14:16:08 EDT Received: from gw.home.vix.com(192.5.5.1) by relay via smap (V1.3mjr) id sma021267; Sun Apr 3 14:15:29 1994 Received: by gw.home.vix.com id AA19257; Sun, 3 Apr 94 11:15:23 -0700 Date: Sun, 3 Apr 94 11:15:23 -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: SIG RR location in responses Organization: Vixie Enterprises Message-Id: References: <9404031202.AA09476@necom830.cc.titech.ac.jp> Nntp-Posting-Host: office.home.vix.com In-Reply-To: mohta@necom830.cc.titech.ac.jp's message of 3 Apr 1994 06:02:06 -0700 >Moreover, aren't the current name servers copying the unused bits >of query packets? yes. >SIGs are less valuable than glue As because they can be asked with a separate >query. agreed. -- Paul Vixie Redwood City, CA decwrl!vixie!paul   Received: from sol.tis.com by magellan.TIS.COM id aa17002; 3 Apr 94 8:17 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA07053; Sun, 3 Apr 94 08:17:02 EDT Received: by relay.tis.com; id AA20332; Sun, 3 Apr 94 08:17:42 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma020326; Sun Apr 3 08:16:42 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sun, 3 Apr 94 21:02:35 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404031202.AA09476@necom830.cc.titech.ac.jp> Subject: Re: SIG RR location in responses To: "Donald E. Eastlake 3rd" Date: Sun, 3 Apr 94 21:02:33 JST Cc: pvm@isi.edu, dns-security@tis.com In-Reply-To: <9404022153.AA23373@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Apr 2, 94 4:53 pm X-Mailer: ELM [version 2.3 PL11] > I don't see > backward compatibility as an issues as a resolver will never see SIG > RRs unless it explicitly asks for them or it is a security aware > resolver talking to a security aware server and turns on the security > desired bit in its query. The older resolver will see (partial) SIG RRs with query type of ANY. Moreover, aren't the current name servers copying the unused bits of query packets? > The reasons for the current design were > (1) I believe that in most cases all the RRs being exlicitly retrieved > will fix inside the SIG. If you are assuming that the total size of RRs is small, you don't have to eliminate that RRs. For example, RRs for A records are only 14 byte long (excluding NAME). Is it really meaningfull to remove one or two 14 byte record when you are using 128 byte (1024) SIG RR(s)? It should be noted that as no compression mechanism is assumed in the draft, raw data in signets could be quite lengthy. Note, for example, that my host name , "necom830.cc.titech.ac.jp.", already exceeds 20 characters and much longer than MD5 signature. BTW, considering that 128 byte SIG can contain 8 MD5 signatures, isn't it reasonable to forget about partial SIG RRs and allow only one SIG RR for a given domain. It is rare that a domain have data for more than 8 RR types. > (2) Regardless of point 1, when operating in a secured mode, RRs are > essentially useless unless they are signed. Regardless of point 2, when DNS operates, NS RRs of authority section for names within the domain are essentially useless unless they are accompanied by glue A records. > Thus the SIG that goes > with any RRs in the answer setion is just as valuable as they are and > intrisicly more valuable than anthing in the additional information > section. Thus it should appear in the answer section to minimize any > chance it would be truncated. SIGs are less valuable than glue As because they can be asked with a separate query. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa01006; 4 Apr 94 17:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA21150; Mon, 4 Apr 94 16:53:11 EDT Received: by relay.tis.com; id AA27572; Mon, 4 Apr 94 16:53:53 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma027569; Mon Apr 4 16:53:09 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA10112; Mon, 4 Apr 94 13:45:37 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA28553; Mon, 4 Apr 1994 16:47:04 -0400 Message-Id: <9404042047.AA28553@skidrow.lkg.dec.com> To: Masataka Ohta Cc: dns-security@tis.com Subject: Re: SIG RR location in responses In-Reply-To: Your message of "Sun, 03 Apr 94 21:02:33 +0200." <9404031202.AA09476@necom830.cc.titech.ac.jp> Date: Mon, 04 Apr 94 16:47:04 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Ohta-san, From: Masataka Ohta In-Reply-To: <9404022153.AA23373@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Apr 2, 94 4:53 pm >> I don't see >> backward compatibility as an issues as a resolver will never see SIG >> RRs unless it explicitly asks for them or it is a security aware >> resolver talking to a security aware server and turns on the security >> desired bit in its query. > >The older resolver will see (partial) SIG RRs with query type of ANY. Yes, you are correct that older resolvers (in fact, resolvers of any age) doing a query of type ANY will see SIG RRs. (I'm not sure why you said "(partial)"...) But anyone doing an ANY type request should expect to see strange RRs come back that it does not know about. New RRs get defined periodically. This is not anything new with just the SIG RR. In any case, I thought were talking about the location in a response of SIGs that were automatically added by security aware servers when they recieve queries with the Security Desired (SD) bit set. This sort of automatically included RR is exactly the sort of thing that has in the past been included in the "additional information section". I gave the reasons why I thought SIGs were different in this regard and should frequently be in the answer or authority section. >Moreover, aren't the current name servers copying the unused bits >of query packets? I don't see what that has to do with the location of spontaneously included SIG RRs on queries from security aware resolvers to security aware servers, which is what I was discussing. If a security aware resolver makes a query with the (SD) bit on in the header to a non-security aware server, it will probably be copied into the response, but so what? A non-security aware server will not set the Security Available (SA) bit in the response and will not spontaneously add SIG RRs to the response. >> The reasons for the current design were >> (1) I believe that in most cases all the RRs being exlicitly retrieved >> will fix inside the SIG. >If you are assuming that the total size of RRs is small, you don't >have to eliminate that RRs. >For example, RRs for A records are only 14 byte long (excluding NAME). >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 and only broad bounds on the size of the zone key modulus. The draft is designed to work as well as it can with all sizes of individual and total RRs. While I think the retrieved and additional RRs will commonly fit into one SIG at this time, this will, for example, not be true if it becomes common to have a host key (RSA) RR present unless the modulus is constrained to be significantly smaller than the zone key modulus. (The proposal calls for the inclusion of the host RSA RR, if any, as additional info on a type A retrieval on the assumption that with widespread IPsec, you would want to know the host key.) Eliminating an RR when it is incorporated inside the SIG is optional under the current draft. 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. As tentatively decided at the DNSSEC WG meeting in Seattle, I would wait for implementation experience to indicate the need before changing this aspect of the draft. >It should be noted that as no compression mechanism is assumed in >the draft, raw data in signets could be quite lengthy. Note, for example, >that my host name , "necom830.cc.titech.ac.jp.", already exceeds 20 >characters and much longer than MD5 signature. I'm not sure of your point. Long RR's can be represented as hashes inside the SIG. All RR's in excess of 127 bytes (or the SIG modulus size less overhead if that is smaller) after abbreviating out the owner name, class, and TTL, must be included as hashes. For medium length RRs, the implenetor is premitted to go either way. For short RRs, you can represent them as a hash if you want, even if that is longer. I thought people considered the draft complicated enough as it is. I 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, the first thing I would do would be to allow name compression inside the signets as if they were immediately preceeded by the SIG RR owner name followed by the SIG RR signer name... This may not be such a bad idea although it would not help in cases like a PTR RR with a completely unrelated name... >BTW, considering that 128 byte SIG can contain 8 MD5 signatures, isn't >it reasonable to forget about partial SIG RRs and allow only one SIG RR >for a given domain. It is rare that a domain have data for more than >8 RR types. I think you are talking about two things: elimination of multiple SIG RRs so that only one was allowed for a particular name and class; and elimination of the "direct" signets so that only hashed signets would be allowed in a SIG. I still think you would need prefix octets to distinguish types (hashed, hashed glue, hashed message, ...) so your signets would all be 19 bytes (prefix + type + 16 byte MD5), or longer for glue RRs, so its more like 6 signets fitting and then only if people use a key as big as your are assuming which is well above the minimum allowed in the current draft. Even assuming you can get things to fit in 512 byte UDP datagrams with your simplifications, which is not clear to me, and even if it is "rare" for for there to be more than 6 RR types for a given owner name and class, I find it totally unacceptable to only secure common cases in the DNS. I believe that a DNS security proposal must cover all but the most preverse cases. >> (2) Regardless of point 1, when operating in a secured mode, RRs are >> essentially useless unless they are signed. > >Regardless of point 2, when DNS operates, NS RRs of authority section >for names within the domain are essentially useless unless they are >accompanied by glue A records. I don't see why that is true. You can always get the A record by resolving the name from root if need be. With a security ignorant server, you can always do what you want with additional retrievals. When you are trying to use one or more NS RRs for a zone you need the RSA record for the zone pointed to so you know its key and if security is mandatory for that zone and you need one or more A records for one or more of the servers for that zone and you want all of this stuff signed (although I guess it makes less difference if the A record is signed as with dnssec you can't get spoofed talking to the wrong server if the zone is secured and you can securely resolve the server name(s) separatly if you want). >> Thus the SIG that goes >> with any RRs in the answer setion is just as valuable as they are and >> intrisicly more valuable than anthing in the additional information >> section. Thus it should appear in the answer section to minimize any >> chance it would be truncated. > >SIGs are less valuable than glue As because they can be asked with a separate >query. Why can't you ask for the glue A's in a separate query? > Masataka Ohta I suggest that the best way to resolve this is that you should write the off line application that signs a zone using your suggestions and run it on variousl real zones (including RSA RRs) with various sizes of key and post the results. These can then be compared with the results using a policy closer to that recommended in the draft. Donald   Received: from sol.tis.com by magellan.TIS.COM id aa01043; 4 Apr 94 17:27 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA23040; Mon, 4 Apr 94 17:27:17 EDT Received: by relay.tis.com; id AA27871; Mon, 4 Apr 94 17:27:58 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma027864; Mon Apr 4 17:27:24 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA11876; Mon, 4 Apr 94 14:20:28 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA29270; Mon, 4 Apr 1994 17:21:57 -0400 Message-Id: <9404042121.AA29270@skidrow.lkg.dec.com> To: dns-security@tis.com Subject: dnssec draft Date: Mon, 04 Apr 94 17:21:57 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp I'd be the first to admit that the current draft is not particularly well written. However, I think that even more than improvement and some reorganization of the technical documentation, there is a drastic need for an "overview". This would have no bit fields or binary/hex numbers in it but would try to give a thorough overview of the proposal. It might incorporate some of the introductory and overview material in the current draft but substantially augmented and rewritten. What do other people think? Donald PS: I have gone through and replaced the secure hash standard with MD5 everywhere in the draft as well as fixing many of the typos and am in the process of de-emphasizing NTP, all as discussed in Seattle. I plan to post this revised draft in a few days so people with complaints about typos might want to wait to see if I've caught them... --------------------------------------------------------------------------- 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 aa02088; 5 Apr 94 4:54 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA01778; Tue, 5 Apr 94 04:54:36 EDT Received: by relay.tis.com; id AA00820; Tue, 5 Apr 94 04:55:18 EDT Received: from gw.home.vix.com(192.5.5.1) by relay via smap (V1.3mjr) id sma000817; Tue Apr 5 04:55:08 1994 Received: by gw.home.vix.com id AA05484; Tue, 5 Apr 94 01:54:51 -0700 Date: Tue, 5 Apr 94 01:54:51 -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: SIG RR location in responses Organization: Vixie Enterprises Message-Id: References: <9404042047.AA28553@skidrow.lkg.dec.com> Nntp-Posting-Host: office.home.vix.com In-Reply-To: dee@skidrow.lkg.dec.com's message of 4 Apr 1994 15:02:02 -0700 Am I the only person reading all this who is concerned about using RSA, a patented and licensed technology, for DNS security? If RSA has put their algorythm into the public domain recently, I'll withdraw my objection. But I don't think they've done that, and I am very reluctant to put into BIND any technology which would require vendors to pay a royalty to RSA before they could ship it with their systems. (I'm not saying I won't do it, but I'm definitely reluctant.) -- Paul Vixie Redwood City, CA decwrl!vixie!paul   Received: from sol.tis.com by magellan.TIS.COM id aa02349; 5 Apr 94 6:14 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02181; Tue, 5 Apr 94 06:14:43 EDT Received: by relay.tis.com; id AA01134; Tue, 5 Apr 94 06:15:26 EDT Received: from mitsou.inria.fr(138.96.24.84) by relay via smap (V1.3mjr) id sma001127; Tue Apr 5 06:14:43 1994 Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA22518; Tue, 5 Apr 1994 12:18:21 +0200 Message-Id: <199404051018.AA22518@mitsou.inria.fr> To: Paul A Vixie Cc: dns-security@tis.com Subject: Re: SIG RR location in responses In-Reply-To: Your message of "Tue, 05 Apr 1994 01:54:51 PDT." Date: Tue, 05 Apr 1994 12:18:20 +0200 From: Christian Huitema Paul, Do you seriously believe there is any alternative to RSA? The only one I could think of would be using another non patented PK technology, or using a symmetric key system. While symmetric systems could be used for an Internet wide key distribution mechanism, I don't really see how you would secure the DNS records with them (i.e. if you really belive that, show us how). The PK alternative would be ElGamal - which is still covered by the Diffie-Helmann patent until 1997, and also mandates some very large signatures and certificates (at least twice larger than RSA) + computer intensive checks. The general catch phrase is "fair patenting". In my mind, this should imply free usage in public domain implementations + easy procedures for commercial software. If you do not believe that RSA meets these conditions, please explain us why, and what should be changed. Christian Huitema   Received: from sol.tis.com by magellan.TIS.COM id aa04264; 5 Apr 94 11:31 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA22014; Tue, 5 Apr 94 11:31:22 EDT Received: by relay.tis.com; id AA02816; Tue, 5 Apr 94 11:32:04 EDT Received: from uucp6.netcom.com(163.179.3.6) by relay via smap (V1.3mjr) id sma002811; Tue Apr 5 11:31:34 1994 Received: from localhost by netcomsv.netcom.com with UUCP (8.6.4/SMI-4.1) id IAA10328; Tue, 5 Apr 1994 08:26:49 -0700 Received: from cc:Mail UUCPLINK 2.0 by metrico.metricom.com id 9403057655.AA765554826 Tue, 05 Apr 94 07:07:06 Date: Tue, 05 Apr 94 07:07:06 From: Greg_Campbell@metrico.metricom.com Message-Id: <9403057655.AA765554826@metrico.metricom.com> To: James M Galvin To: Paul A Vixie Cc: dns-security@tis.com Subject: Re: SIG RR location in responses Subject: cc:Mail UUCPLINK 2.0 Undeliverable Message User metrico!rfox@metricom.com is not defined Original text follows ----------------------------------------- Received: by ccmail Received: from netcomsv by metricom.com (UUPC/extended 1.11) with UUCP; Tue, 05 Apr 1994 07:05:40 PDT Received: from relay.tis.com by netcomsv.netcom.com with SMTP (8.6.4/SMI-4.1) id IAA07540; Tue, 5 Apr 1994 08:08:55 -0700 Received: by relay.tis.com; id AA02469; Tue, 5 Apr 94 10:46:58 EDT Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr) id smaa02455; Tue Apr 5 10:45:59 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa03805; 5 Apr 94 10:39 EDT Received: from sol.tis.com by magellan.TIS.COM id aa03801; 5 Apr 94 10:38 EDT Received: from magellan.TIS.COM by tis.com (4.1/SUN-5.64) id AA16375; Tue, 5 Apr 94 10:38:04 EDT Received: from localhost.tis.com by magellan.TIS.COM id aa03631; 5 Apr 94 10:30 EDT Reply-To: James M Galvin To: Paul A Vixie Cc: dns-security@tis.com Subject: Re: SIG RR location in responses In-Reply-To: Paul A Vixie's message of Tue, 05 Apr 1994 01:54:51 PDT. Date: Tue, 05 Apr 1994 10:29:53 -0400 From: James M Galvin X-ccAdmin: metricom@netcomsv Message-Id: <9404051030.aa03631@magellan.TIS.COM> Am I the only person reading all this who is concerned about using RSA, a patented and licensed technology, for DNS security? I am very reluctant to put into BIND any technology which would require vendors to pay a royalty to RSA before they could ship it with their systems. Two bits of information to keep in mind. First, RSADSI has made RSAREF available for non-commercial use. However, I realize this does not solve the "vendors packaging a product." For that, may I direct your attention to the latest issue of Connexions, March 1984, in which commandment number 1 of "The Ten Commandments of Domain Name Service" is, "Thou shalt not run thy vendor's DNS software." During the IETF last week, in a private conversation, it was suggested that the DNS may be one of those applications (e-mail is another) for which the vendor release cycle is just slow enough to make waiting for updated versions from vendors at least irresponsible. I, too, believe this to be true. Christian already commented on the business side of things so I won't say any more about that. Jim   Received: from sol.tis.com by magellan.TIS.COM id aa03801; 5 Apr 94 10:38 EDT Received: from magellan.TIS.COM by tis.com (4.1/SUN-5.64) id AA16375; Tue, 5 Apr 94 10:38:04 EDT Received: from localhost.tis.com by magellan.TIS.COM id aa03631; 5 Apr 94 10:30 EDT Reply-To: James M Galvin To: Paul A Vixie Cc: dns-security@tis.com Subject: Re: SIG RR location in responses In-Reply-To: Paul A Vixie's message of Tue, 05 Apr 1994 01:54:51 PDT. Date: Tue, 05 Apr 1994 10:29:53 -0400 From: James M Galvin Message-Id: <9404051030.aa03631@magellan.TIS.COM> Am I the only person reading all this who is concerned about using RSA, a patented and licensed technology, for DNS security? I am very reluctant to put into BIND any technology which would require vendors to pay a royalty to RSA before they could ship it with their systems. Two bits of information to keep in mind. First, RSADSI has made RSAREF available for non-commercial use. However, I realize this does not solve the "vendors packaging a product." For that, may I direct your attention to the latest issue of Connexions, March 1984, in which commandment number 1 of "The Ten Commandments of Domain Name Service" is, "Thou shalt not run thy vendor's DNS software." During the IETF last week, in a private conversation, it was suggested that the DNS may be one of those applications (e-mail is another) for which the vendor release cycle is just slow enough to make waiting for updated versions from vendors at least irresponsible. I, too, believe this to be true. Christian already commented on the business side of things so I won't say any more about that. Jim   Received: from sol.tis.com by magellan.TIS.COM id aa04770; 5 Apr 94 12:39 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA25071; Tue, 5 Apr 94 12:39:33 EDT Received: by relay.tis.com; id AA03282; Tue, 5 Apr 94 12:40:16 EDT Received: from gw1.att.com(192.20.239.133) by relay via smap (V1.3mjr) id sma003270; Tue Apr 5 12:40:02 1994 Date: Tue, 5 Apr 94 12:30 EDT Content-Length: 1991 Content-Type: text Message-Id: From: WJCarpenter To: galvin@tis.com Cc: dns-security@tis.com In-Reply-To: James M Galvin's note of 10:29:53, 5 Apr 1994 Reference: <9404051030.aa03631@magellan.TIS.COM> Subject: RE: SIG RR location in responses vixie> Am I the only person reading all this who is concerned about vixie> using RSA, a patented and licensed technology, for DNS vixie> security? I am very reluctant to put into BIND any technology vixie> which would require vendors to pay a royalty to RSA before they vixie> could ship it with their systems. galvin> Two bits of information to keep in mind. First, RSADSI has galvin> made RSAREF available for non-commercial use. However, I galvin> realize this does not solve the "vendors packaging a product." galvin> For that, may I direct your attention to the latest issue of galvin> Connexions, March 1984, in which commandment number 1 of "The galvin> Ten Commandments of Domain Name Service" is, "Thou shalt not galvin> run thy vendor's DNS software." That's fine for commercial products (ie, selling software) since it is unlikely that there would be much of a market for commercial replacements of BIND anyhow (hard to beat the price :-). I think the issue is not just having RSAREF in the software, it's having it in the protocol that's the sticky point. What about a commercial service? It's not clear to me that if I ran a for-profit service bureau that ran DNS servers for folks whether that would be commercial use w/r/t RSAREF or not. Probably yes, even if I were using non-commercial BIND software. Don't like that because you think that's a marginal case? What if I run an Internet-based business where claiming to use the reliability of the signed DNS records is part of the reassurance that I give to my customers. Whether it is just hype or actual value, it would conceivably be part of value perceived by the customer. Hence, it is contributing to my getting more business. Is that commercial use, even if I'm just using non-commercial BIND software? -- Bill@attmail.com billc@pegasus.ATT.COM or +1 908 576 2932, Fax x6406 William_J_Carpenter@ATT.COM AT&T Bell Labs / AT&T EasyLink Services LZ 3C-207   Received: from sol.tis.com by magellan.TIS.COM id aa05108; 5 Apr 94 13:40 EDT Received: from magellan.tis.com by tis.com (4.1/SUN-5.64) id AA29889; Tue, 5 Apr 94 13:40:02 EDT Message-Id: <9404051740.AA29889@tis.com> Reply-To: James M Galvin To: dns-security@tis.com Subject: DRAFT Minutes of DNS Security March 1994 (Seattle) Meeting Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-Id: <5096.765567591.0@tis.com> Date: Tue, 05 Apr 1994 13:40:10 -0400 From: James M Galvin ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5096.765567591.1@tis.com> Enclosed below is my record of the meeting held during the last IETF meeting. Corrections from those who attended the meeting are hereby solicited. In particular, there is one issue that I had regarded on the slides for which I can not remember either the context or the resolution. I'd appreciate if someone could remind me. I will submit the revised minutes for the record on Monday, April 11 (or these if I get no comments). Thanks, Jim ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5096.765567591.2@tis.com> Content-Description: Meeting Minutes DNS Security WG Meeting Minutes March 1994 Seattle Recorded by Jim Galvin, Chair The DNS Security Working Group met on Tuesday morning for a 2.5 hour meeting. Charlie Kaufman and Donald Eastlake had previously submitted a proposal (as an internet draft) for enhancing the DNS to support a digital signature security service. This meeting was dedicated to a review of that proposal. The meeting began with a review of the desired requirements identified at the BOF meeting held at the November 1993 Houston meeting. Charlie and Donald then led a presentation and discussion of their proposal. The following issues were discussed and resolved as indicated. o choice of algorithm The proposal currently specifies the SHA and RSA algorithms. It was agreed to replace SHA with MD5, the current Internet preference. o revisit DNS architecture The addition of SIG RRs increases the probability that the maximum UDP payload per packet may be exceeded. The requirement that we remain backward compatible with the existing installed base and the lack of empirical data to support the premise caused us to agree to leave the DNS architecture alone. o where do SIG RRs go in the reply A question was raised as to whether which section of the reply the SIG RRs should be placed. This is an issue because it was noted that, if necessary, implementations may ignore (and truncate) the additional records portion of a reply. It was agreed to query Paul Mockapetris in particular and to followup on the mailing list. o key per zone or key per server The proposal currently specifies that a public/private key pair is assigned to a zone, which is responsible for signing its data. In this way the data may be distributed by any server and, in fact, the actual signing of the data may (and should) occur as an off-line function. In addition, a specification is included for servers to optionally sign responses to queries. At this time it was agreed to leave the optional alternative in the document. We will revisit this issue after we have some implementation experience. o split the document It was suggested that the document may be better organized as several related documents. It was agreed Donald and/or Charlie would initiate a discussion of this issue on the mailing list. o use of the NTP time service The proposal currently emphasizes (if not requires) the use of a reliable time service, in particular NTP. It was agreed that DNS should not depend on synchronized clocks. The authors agreed to rework this aspect of the proposal to not depend on synchronized clocks. o partial and/or hash records (** HELP HERE **) I have this item recorded on the slides but I don't recall the issue or the resolution. Can someone provide some context, please? o key management It was observed that an integral part of the proposal is the specification of a key management protocol. As the new security area director was present at the meeting he was asked if the security area believed it was appropriate to specify another key management protocol, observing that both PEM and SNMP Security have also specified key management protocols. The response was that this key management protocol was sufficiently different from the other two that it was valuable in its own right and should remain part of the proposal. The meeting concluded with Jim Galvin noting that TIS would be implementing the proposal using the bind implementation of the DNS as a baseline. This software would be openly available to the Internet community. This group expects to meet in Toronto. ------- =_aaaaaaaaaa0--   Received: from sol.tis.com by magellan.TIS.COM id aa05649; 5 Apr 94 15:35 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA10666; Tue, 5 Apr 94 15:34:57 EDT Received: by relay.tis.com; id AA04579; Tue, 5 Apr 94 15:35:39 EDT Received: from relay.hp.com(15.255.152.2) by relay via smap (V1.3mjr) id sma004568; Tue Apr 5 15:35:05 1994 Received: from hpindbg.cup.hp.com by relay.hp.com with SMTP (1.37.109.8/15.5+ECS 3.3) id AA24360; Tue, 5 Apr 1994 12:34:31 -0700 Received: by hpindsh.cup.hp.com (1.37.109.9Q/15.5+IOS 3.20+cup+OMrelay) id AA1865448453; Tue, 5 Apr 1994 12:34:29 -0700 From: Art Harkin Message-Id: <9404051234.ZM18652@hpindbg.cup.hp.com> Date: Tue, 5 Apr 1994 12:34:28 -0700 In-Reply-To: Greg_Campbell@metrico.metricom.com "Re: SIG RR location in responses, cc:Mail UUCPLINK 2.0 Undeliverable Message" (Apr 5, 7:07am) References: <9403057655.AA765554826@metrico.metricom.com> X-Mailer: Z-Mail (2.1.5 20sep93) To: Greg_Campbell@metrico.metricom.com, James M Galvin , Paul A Vixie Subject: Re: SIG RR location in responses, cc:Mail UUCPLINK 2.0 Undeliverable Message Cc: dns-security@tis.com On Apr 5, 7:07am, Greg_Campbell@metrico.metricom.com wrote: > Am I the only person reading all this who is concerned about > using RSA, a patented and licensed technology, for DNS security? > I am very reluctant to put into BIND any technology which would > require vendors to pay a royalty to RSA before they could ship > it with their systems. > > Two bits of information to keep in mind. First, RSADSI has made RSAREF > available for non-commercial use. However, I realize this does not > solve the "vendors packaging a product." For that, may I direct your > attention to the latest issue of Connexions, March 1984, in which > commandment number 1 of "The Ten Commandments of Domain Name Service" > is, "Thou shalt not run thy vendor's DNS software." > > During the IETF last week, in a private conversation, it was suggested > that the DNS may be one of those applications (e-mail is another) for > which the vendor release cycle is just slow enough to make waiting for > updated versions from vendors at least irresponsible. I, too, believe > this to be true. > I plead some ignorance on RSA royalty issues, in the past, I have not discovered such limitations with MD5's use within xntp. If someone is able to enlighten me via e-mail on what is actually subject to royalties, and what usage of public domain software will require such a license, I would appreciate it. Making a possibly ignorant stab at what I see to be a potentially dangerous viewpoint with DNS, even though it was one of Bryan Beecher's 10 DNS commandments. I think Bryan's point is well taken, vendors generally have lag times and there is a delay getting out new functionality (however, this part isn't set in stone tablets, there are ways of getting software out prior to the scheduled releases, if the changes merit it). Where I feel the danger lies is how this 'problem' has been intepreted into a rule that vendor software is to be discarded. This might be a simplistic view, there are many network admins unwilling to delve into the issues of running unsupported software. Not recognizing this can cause problems later. I feel a better approach is to encourage rapid deployment of new features in both commercial and non-commercial arenas. If the vendors can't be convinced, then the customers/users/admins should be convinced and they can apply pressure, if they can't be convinced, then maybe the technology is not addressing a generally needed concern on the Internet. The requirements, needs and timetables of vendors shouldn't delay an IETF technology's release on to the Internet, however the technology shouldn't at the same time cripple future vendor integration. Hopefully the IETF rough consensus is not building to a point where it is agreeable to ignore issues that may stall commercial use of technology. In particular for the dnssec WG, the glossing over the issues of RSA royalties with out determining the impact can be as bad a judgment as a poorly considered protocol change. If RSA royalties interfered with commercial use of BIND, than what would happen if vendors did not implement BIND past 4.9.2, because of a significant royalty cost? If something like this was to occur, I suspect we will be revisiting these issues again at a later date. -art -- ------------------------------------------------------------------------------ A r t H a r k i n Hewlett-Packard Company E-mail: ash@cup.hp.com Information Networks Division 19420 Homestead Road MS 43LN, Cupertino, CA 95014 Education should be as gradual as the moonrise, perceptible not in progress, but in result. ------------------------------------------------------------------------------   Received: from sol.tis.com by magellan.TIS.COM id aa06112; 5 Apr 94 16:44 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA16238; Tue, 5 Apr 94 16:44:12 EDT Received: by relay.tis.com; id AA05274; Tue, 5 Apr 94 16:44:54 EDT Received: from decvax.zk3.dec.com(16.140.0.3) by relay via smap (V1.3mjr) id sma005262; Tue Apr 5 16:44:12 1994 Received: from abyss.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA22668; Tue, 5 Apr 1994 16:43:40 -0400 Received: by abyss.zk3.dec.com (5.65/DEC-USG-ULTRIX-4.4-03/25/94) id AA25266; Tue, 5 Apr 1994 16:43:38 -0400 Message-Id: <9404052043.AA25266@abyss.zk3.dec.com> To: galvin@tis.com Cc: dns-security@tis.com Subject: Re: DRAFT Minutes of DNS Security March 1994 (Seattle) Meeting Date: Tue, 05 Apr 94 16:43:38 -0400 From: kaufman@zk3.dec.com X-Mts: smtp >o partial and/or hash records > > (** HELP HERE **) > > I have this item recorded on the slides but I don't recall the issue > or the resolution. Can someone provide some context, please? The issue was around the Partial RR Set Flag Signet - in particular whether this functionality is needed. If there are a large number of small resource records all of the same type, the current specification allows two different ways of signing them. They can all be concatenated and a single hash included in a Hashed Resource Record(s) Signet *or* they can be encoded in a series of Direct Resource Record Signets. If the second encoding is chosen and there are too many RRs to fit inside a single signature, the Partial RR Set Flag Signet is needed to assure the reader that it has seen all of them. The proposal from the floor was that the second encoding be disallowed in the case where the RRs didn't fit in a single signature, thus eliminating the need for the complexity of allowing the additional signet type. Don and I agreed that this was plausible thought that there might be cases where the second encoding would permit substantial efficiencies. I'm not sure what the resolution was (if any). I suspect we agreed to think about it. --Charlie   Received: from sol.tis.com by magellan.TIS.COM id aa06147; 5 Apr 94 16:54 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA17267; Tue, 5 Apr 94 16:54:14 EDT Received: by relay.tis.com; id AA05429; Tue, 5 Apr 94 16:54:55 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma005422; Tue Apr 5 16:54:02 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA07101; Tue, 5 Apr 94 13:48:06 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA21749; Tue, 5 Apr 1994 16:49:36 -0400 Message-Id: <9404052049.AA21749@skidrow.lkg.dec.com> To: James M Galvin Cc: dns-security@tis.com Subject: Re: DRAFT Minutes of DNS Security March 1994 (Seattle) Meeting In-Reply-To: Your message of "Tue, 05 Apr 94 13:40:10 EDT." <9404051740.AA29889@tis.com> Date: Tue, 05 Apr 94 16:49:35 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Jim, From: James M Galvin To: dns-security@tis.com > > DNS Security WG Meeting Minutes > March 1994 Seattle > > >Recorded by Jim Galvin, Chair > >... > >o use of the NTP time service > > The proposal currently emphasizes (if not requires) the use of a > reliable time service, in particular NTP. It was agreed that DNS > should not depend on synchronized clocks. The authors agreed to > rework this aspect of the proposal to not depend on synchronized > clocks. My understand was that the desire was to have to draft say that the resolver and server need only have approximately synchronized clocks (typically on the order of synchronized within a few hours) but to not mention NTP or any other particular way of achieving sychronization. >o partial and/or hash records > > (** HELP HERE **) > > I have this item recorded on the slides but I don't recall the issue > or the resolution. Can someone provide some context, please? I believe the point was raised that the ability to directly include RRs of a particular type in more than one SIG record was overly complicated in that it caused the need for the "partial RR" signet to be sure you had all the relevant SIGs. The suggestion was that if all the RRs of a particular type did not fit directly into one SIG, the use of a hashed signet be required which would in turn require the RRs to be present in plain text outside the SIG. The resolution at the meeting was to wait for implementation experience to see if this simplification to the proposal made sense. > >... > Donald   Received: from sol.tis.com by magellan.TIS.COM id aa06624; 5 Apr 94 19:50 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA24522; Tue, 5 Apr 94 19:50:33 EDT Received: by relay.tis.com; id AA06444; Tue, 5 Apr 94 19:51:16 EDT Received: from zephyr.isi.edu(128.9.160.160) by relay via smap (V1.3mjr) id sma006440; Tue Apr 5 19:50:28 1994 Received: from aloha.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16) id ; Tue, 5 Apr 1994 16:49:00 -0700 Message-Id: <199404052349.AA06461@zephyr.isi.edu> To: Paul A Vixie Cc: dns-security@tis.com, namedroppers@nic.ddn.mil Reply-To: pvm@isi.edu Subject: Re: SIG RR location in responses In-Reply-To: Your message of Tue, 05 Apr 1994 01:54:51 -0700. Date: Tue, 05 Apr 94 16:47:20 PDT From: Paul Mockapetris > Am I the only person reading all this who is concerned about using RSA, > a patented and licensed technology, for DNS security? If RSA has put > their algorythm into the public domain recently, I'll withdraw my > objection. But I don't think they've done that, and I am very reluctant > to put into BIND any technology which would require vendors to pay a > royalty to RSA before they could ship it with their systems. (I'm not > saying I won't do it, but I'm definitely reluctant.) > -- > Paul Vixie > Redwood City, CA > decwrl!vixie!paul > No. I objected to starting down this track without a reasonable agreement in hand at the Houston IETF. (Other opinions differed) I said the same thing in Seattle. Steve Crocker told me he was going to work with PKP/RSA to create an agreement. With a reasonable aagreement, I see no reason to object, but until then... I also think namedroppers and bind mailing lists should be kept informed of architectural implications of the proposed changes. Suggest you keep the heat up on IETF leadership on this one, say the security area directorate. paul USC/Information Sciences Institute phone: 310-822-1511 x285 4676 Admiralty Way, Marina del Rey, CA fax: 310-823-6714 90292   Received: from sol.tis.com by magellan.TIS.COM id aa06868; 5 Apr 94 22:10 EDT Received: from happy.tis.com by tis.com (4.1/SUN-5.64) id AA25974; Tue, 5 Apr 94 22:10:37 EDT Message-Id: <9404060210.AA25974@tis.com> To: dns-security@tis.com, namedroppers@nic.ddn.mil, crocker@tis.com Subject: Possible use of public key technology in DNS authentication Date: Tue, 05 Apr 94 22:10:33 -0400 From: Stephen D Crocker In a message attached in whole below, Paul Mockapetris wrote: > Steve Crocker told me he was going to work with PKP/RSA to create an > agreement. With a reasonable agreement, I see no reason to object, > but until then... Paul describes a brief hallway conversation, and some amplification and clarification is in order. Concern is expressed about the availability of public key technology for use in the DNS environment. I expressed -- ar at least intended to express -- confidence that the technology would be available. Let me make it clear that I do not speak for either Public Key Partners ("PKP") nor RSA Data Security Inc ("RSA"), so the opinions I expressed are my own. During the conversation, I expressed the opinion that it should be possible to work out something reasonable with RSA, and that I would undertake some discussions. I have not done so yet, and nothing I said then or in this note should be construed as reflecting the position of either RSA or PKP. Similarly, I cannot -- and did not intend to -- speak authoritatively for the ISOC, IETF, IESG or IAB. I can, however, attempt to discuss these matters in good faith and bring proposals to the table for review by all parties. With those caveats established, it's useful to note some of the indicators that suggest the technology is likely to be accessible for our purposes. Two packages are available from RSA free of charge for non-commercial use. ("Non-commercial" means somewhat different things in different contexts, so it's important to read the specific definition in any particular situation. However, the details are not important for this note.) One package is RSAREF, a source code collection of the various cryptographic routines. The other, just recently released, is RIPEM/SIG, an object-code, signature-only version of RIPEM. RIPEM is approximately "PEM-lite". RSA encourages the use of these packages for the development of new applications. Without having worked out the specific details, it seems probable that the capabilities needed for DNS authentication are within the capabilities included in RSAREF. Further, since only authentication is needed, it is likely that object code versions of the code can be granted mass market export licenses, as has been done for RIPEM/SIG. (Licensing from RSA and/or PKP is only one of two traditional bogeymen haunting public key technology; the other is export control. Both have to be addressed when planning wide spread deployment of this technology.) RSA also sells its software, and it has a number of license agreements in place with companies large and small. To the best of my knowledge, including the direct negotiations I have had with RSA for our own licenses, licensing terms should not stand in the way of whatever approach we will find useful for securing DNS. We now come to a chicken and egg problem. RSA and PKP usually license their software or technology to companies, not standards bodies. Similarly, the IETF has not heretofore contracted with patent holders for specific terms. Yet the tone of the notes from Paul Mockapetris and Paul Vixie suggest we should not design a public-key based solution to DNS authentication without a specific license arrangement in place. While it may be possible to clear away much of the uncertainty ahead of time, the only acid test will come after the design is complete and individual implementors conduct specific discussions with RSA and/or PKP. I agree that all other things being equal, royalty-free technology is preferable to royalty-bearing technology, but I also believe that it's poor practice to avoid the best technology just because it's patented. The Ethernet was patented, and the Internet probably wouldn't exist without it. This is not the first time we've dealt with this issue. The use of patented technology in Internet standards has been addressed by the IAB and IESG in both RFC 1310 and RFC 1602. The latter was issued in March 1994 and applies to specifications adopted on or after April 1, 1994 (no fooling). The relevant section is: 5.4.2. Standards Track Documents (A) ISOC will not propose, adopt, or continue to maintain any standards, including but not limited to standards labelled Proposed, Draft or Internet Standards, which can only be practiced using technology or works that are subject to known copyrights, patents or patent applications, or other rights, except with the prior written assurance of the owner of rights that: l. ISOC may, without cost, freely implement and use the technology or works in its standards work; 2. upon adoption and during maintenance of an Internet Standard, any party will be able to obtain the right to implement and use the technology or works under specified, reasonable, non-discriminatory terms; and 3. the party giving the assurance has the right and power to grant the licenses and knows of no other copyrights, patents, patent applications, or other rights that may prevent ISOC and members of the Internet community from implementing and operating under the standard. With respect to the use of public key technology, the assurances required under 5.4.2(A)2 have already been provided and are documented in RFC 1170. This documentation was required prior to the advancement of the PEM specifications to Proposed Standard status, and the official IESG notice requesting advancement of those specifications to Proposed Standard status cited RFC 1170 and discussed the issues. It is useful to note that RFC 1170 is not specific to PEM and applies to all use of public key technology. In the event that public key technology is used in the design of DNS authentication or any other Internet specification that is put on the standards track, it is perfectly appropriate to revisit the agreements and assurances. With RFC 1170 already in hand, the results should be similar. My belief is we should design the best authentication scheme we can for DNS. If this means using public key technology -- and I believe it does -- then so be it. Steve +-------------------------------------+-------------------------------+ | Steve Crocker | Voice: 301-854-6889 | | Trusted Information Systems | FAX: 301-854-5363 | | 3060 Washington Road (Route 97) |-------------------------------| | Glenwood, MD 21738 | Internet: crocker@tis.com | +-------------------------------------+-------------------------------+ > Reply-To: pvm@isi.edu > Sender: majordomo@internic.net > From: Paul Mockapetris > To: Paul A Vixie > cc: dns-security@tis.com, namedroppers@nic.ddn.mil > Date: Tue, 05 Apr 94 16:47:20 PDT > Subject: Re: SIG RR location in responses > > > Am I the only person reading all this who is concerned about using RSA, > > a patented and licensed technology, for DNS security? If RSA has put > > their algorithm into the public domain recently, I'll withdraw my > > objection. But I don't think they've done that, and I am very reluctant > > to put into BIND any technology which would require vendors to pay a > > royalty to RSA before they could ship it with their systems. (I'm not > > saying I won't do it, but I'm definitely reluctant.) > > -- > > Paul Vixie > > Redwood City, CA > > decwrl!vixie!paul > > > > No. > > I objected to starting down this track without a reasonable agreement > in hand at the Houston IETF. (Other opinions differed) I said the > same thing in Seattle. Steve Crocker told me he was going to work > with PKP/RSA to create an agreement. With a reasonable agreement, I > see no reason to object, but until then... > > I also think namedroppers and bind mailing lists should be > kept informed of architectural implications of the proposed changes. > > Suggest you keep the heat up on IETF leadership on this one, say the > security area directorate. > > paul > > USC/Information Sciences Institute phone: 310-822-1511 x285 > 4676 Admiralty Way, Marina del Rey, CA fax: 310-823-6714 > 90292   Received: from sol.tis.com by magellan.TIS.COM id aa07120; 6 Apr 94 1:01 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA27375; Wed, 6 Apr 94 01:01:02 EDT Received: by relay.tis.com; id AA07655; Wed, 6 Apr 94 01:01:46 EDT Received: from optima.cs.arizona.edu(192.12.69.5) by relay via smap (V1.3mjr) id sma007652; Wed Apr 6 01:01:14 1994 Received: from baskerville.CS.Arizona.EDU by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA03312; Tue, 5 Apr 1994 22:01:00 MST Received: (from ho@localhost) by baskerville.cs.arizona.edu (8.6.7/8.6.6) id WAA04399; Tue, 5 Apr 1994 22:00:58 -0700 Date: Tue, 5 Apr 1994 22:00:58 -0700 From: Hilarie Orman Message-Id: <199404060500.WAA04399@baskerville.cs.arizona.edu> To: crocker@tis.com Cc: namedroppers@nic.ddn.mil, dns-security@tis.com In-Reply-To: Your message <9404060210.AA25974@tis.com> Subject: Re: Possible use of public key technology in DNS authentication Is this to say that the assurances required under 5.4.2(A)1 and 3 have not been provided? If this is correct, will someone be talking to RSA about getting the assurances? Another question: are implementors free to implement RSA patented algorithms for non-commercial use? Or are they only free to use RSAREF?   Received: from sol.tis.com by magellan.TIS.COM id aa10990; 6 Apr 94 8:45 EDT Received: from happy.tis.com by tis.com (4.1/SUN-5.64) id AA12855; Wed, 6 Apr 94 08:45:12 EDT Message-Id: <9404061245.AA12855@tis.com> To: Hilarie Orman Cc: crocker@tis.com Cc: namedroppers@nic.ddn.mil, dns-security@tis.com Subject: Re: Possible use of public key technology in DNS authentication In-Reply-To: Your message of "Tue, 05 Apr 94 22:00:58 PDT." <199404060500.WAA04399@baskerville.cs.arizona.edu> Date: Wed, 06 Apr 94 08:45:09 -0400 From: Stephen D Crocker Hilarie, I focused on 5.4.2(a)2 because it pertained to implementation. So far as I can tell, the full assurances required under 5.4.2(A)1, 5.4.2(A)2 and 5.4.2(A)3 were obtained previously, as documented in RFC 1170. As I said before, it's entirely reasonable to revisit and redocument the details, but my strong belief is that this is not a showstopper and should not affect our design choices. With respect to your second question, are you asking the generic question about patent law, i.e. (a) "are implementors free to implement for non-commercial use?", or are you asking (b) whether RSA has provided general permission for free implementation of their technology for non-commercial use? As neither a lawyer nor an RSA representative, I can give only my general understanding, which is (a) I believe patents cover all use, commercial or not, and (b) I don't think RSA has given blanket permission for non-commercial implementations other than through RSAREF, but I strongly recommend you take this up with them. Steve > From: Hilarie Orman > To: crocker@tis.com > cc: namedroppers@nic.ddn.mil, dns-security@tis.com > Date: Tue, 5 Apr 1994 22:00:58 -0700 > Subject: Re: Possible use of public key technology in DNS authentication > > Is this to say that the assurances required under 5.4.2(A)1 and 3 have > not been provided? If this is correct, will someone be talking to RSA > about getting the assurances? > > Another question: are implementors free to implement RSA patented > algorithms for non-commercial use? Or are they only free to use > RSAREF?   Received: from sol.tis.com by magellan.TIS.COM id aa07383; 6 Apr 94 3:45 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA28828; Wed, 6 Apr 94 03:45:15 EDT Received: by relay.tis.com; id AA08113; Wed, 6 Apr 94 03:45:58 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma008109; Wed Apr 6 03:45:12 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 6 Apr 94 16:37:18 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404060737.AA26241@necom830.cc.titech.ac.jp> Subject: Re: SIG RR location in responses To: "Donald E. Eastlake 3rd" Date: Wed, 6 Apr 94 16:37:16 JST Cc: dns-security@tis.com In-Reply-To: <9404042047.AA28553@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Apr 4, 94 4:47 pm X-Mailer: ELM [version 2.3 PL11] > >SIGs are less valuable than glue As because they can be asked with a separate > >query. > > Why can't you ask for the glue A's in a separate query? Sigh... To make the query, you must know A's. Read the section 4.2.1 of RFC1034, if you can't understand it. The point here is that truncation is a real issue only for glue records. So, you don't have to think truncation of SIG or RSA records in additional section so seriously. In general, you are trying to do: 1) Make DNS secure 2) Make DNS reply short In doing 2), your proposal includes several modificatiton to the architecture of DNS. But as the truncation is not a so severe issue, I don't think its worthwhile to do so. So, I suggest not to pursue 2) so much and simplify the proposal. 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 > >Moreover, aren't the current name servers copying the unused bits > >of query packets? > > I don't see what that has to do with the location of spontaneously > included SIG RRs on queries from security aware resolvers to security > aware servers, which is what I was discussing. If a security aware > resolver makes a query with the (SD) bit on in the header to a > non-security aware server, it will probably be copied into the > response, but so what? SD copied by security unaware forwarders will cause a lot of problems. > >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. > 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. > 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? > As > tentatively decided at the DNSSEC WG meeting in Seattle, I would wait > for implementation experience to indicate the need before changing > this aspect of the draft. If it is option, what will be implemented? > 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? > 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. > Even assuming you can get things to fit in 512 byte UDP datagrams with > your simplifications, which is not clear to me, and even if it is > "rare" for for there to be more than 6 RR types for a given owner name > and class, I find it totally unacceptable to only secure common cases > in the DNS. I believe that a DNS security proposal must cover all but > the most preverse cases. What I suggested was to use block authentication to cover larger number of signets. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa07523; 6 Apr 94 4:09 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA28964; Wed, 6 Apr 94 04:09:17 EDT Received: by relay.tis.com; id AA08339; Wed, 6 Apr 94 04:10:01 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma008328; Wed Apr 6 04:09:13 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 6 Apr 94 16:58:51 +0859 From: Masataka Ohta Return-Path: Message-Id: <9404060759.AA26399@necom830.cc.titech.ac.jp> Subject: Real truncation problem To: "Donald E. Eastlake 3rd" Date: Wed, 6 Apr 94 16:58:48 JST Cc: dns-security@tis.com In-Reply-To: <9404042047.AA28553@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Apr 4, 94 4:47 pm X-Mailer: ELM [version 2.3 PL11] I found the current proposal unnecessarily contains real truncation problem. As the largest modulus is 2048 bits, usual key size will be about 1000 bits or 130 bytes. If such a large key is chosen by administrators (as the cost to choose the longer key is not so large, most of the security conscious administrators (that is, all those who use secure DNS) will use the largest possible, I think), a DNS packet containing 4 keys will be truncated. As having 2 keys for a single purpose is usually enough, it should not be an issue. But the current proposal assign only a single RSA RR name to 3 different purposes: authentication of a zone, a host and a user. So, real truncation may occur. Moreover, it will make additional section processing difficult causing a lot of truncations. So, we should have 3 different RR names for 3 different purposes: ZRSA for zones, HRSA for hosts, and MRSA for mails. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa16312; 6 Apr 94 16:27 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13594; Wed, 6 Apr 94 16:27:11 EDT Received: by relay.tis.com; id AA13264; Wed, 6 Apr 94 16:27:56 EDT Received: from gw.home.vix.com(192.5.5.1) by relay via smap (V1.3mjr) id sma013255; Wed Apr 6 16:27:08 1994 Received: by gw.home.vix.com id AA15278; Wed, 6 Apr 94 13:26:57 -0700 Date: Wed, 6 Apr 94 13:26:57 -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: Possible use of public key technology in DNS authentication Organization: Vixie Enterprises Message-Id: References: <9404061245.AA12855@tis.com> Nntp-Posting-Host: office.home.vix.com In-Reply-To: crocker@tis.com's message of 6 Apr 1994 06:29:08 -0700 The question I'd like to see someone take up with RSA (and I suppose that someone could be me if there's no designated RSA delegate from the WG) is: IF a DNS Security protocol is approved by the IAB, AND that protocol specifies the use of a PK system AND the PK system specified is one patented by RSA THEN (1) will i be in trouble if i publish a version of BIND that includes full source code to the implementation of the above (2) will i have to alter my existing BSD-derived copyright in any way (it currently specifies unlimited use and unlimited redistribution) (3) will vendors who include such a BIND in their operating systems be at risk from lawsuits from RSA if they don't pay license fees to RSA? Steve Crocker mentioned Ethernet as an example of a previous patented technology whose licensing restrictions didn't seem to impede Ethernet's tremendous usefulness or the Internet's growth. I almost bought it. But then I realized that any *particular* user of the Internet could avoid paying, either directly or indirectly, any licenses fees or royalties to the Digital/Intel/Xerox Ethernet consortium, through the simple expedient of not buying any Ethernet hardware. RSA in DNS would have much a broader effect: within a few years after Secure DNS is implemented, *noone* will be able to use the Internet without using the RSA technology. If the only people who are allowed to *use* the RSA technology are those who are either not doing commerce on the Internet or who pick up BIND on their own because their vendor doesn't want to pay RSA's license fees or doesn't include BIND at all, then I believe we'll have done a very bad thing. The overwhelming majority of new Internet hosts use system software straight from their vendors. What this looks like from here is a coup attempt by RSA. I'm still not ready to say that BIND won't ever include licensed technology that vendors won't be able to incorporate into their products without paying patent royalties. We're a ways off from having to make that decision, anyway. But I think it behooves the IETF, as supposedly representing the interests of the Internet community, to think VERY CAREFULLY about the implications of giving a company like RSA this kind of monopolistic cash cow. Now, who can answer my Big Question (see above)? If noone here is willing to contact RSA to ask it, then who at RSA should I talk to? I don't think this ought to be my job, since I'm more concerned as an implementor and as an citizen Internet than as a pseudo-member of the WG. This issue falls, in my opinion, squarely in the province of the area directorate or perhaps the IAB's industry liason (if there even is such a thing). But since I generally loathe people who say ``that's not my job,'' I **will** make the calls and get an official answer out of RSA if noone else thinks that it's *their* job to do that. Steve, I don't want you to take this personally. But as a bear of very little brain, I can't follow the mumbo jumbo in 5.4.2(A)1 et al. I need a simple answer to what I hope is a very simple question. I happen to think that the rest of the WG ought to want to hear the answer just as badly as I do, but that's something I'll address at a later date. -- Paul Vixie Redwood City, CA decwrl!vixie!paul   Received: from sol.tis.com by magellan.TIS.COM id aa16618; 6 Apr 94 18:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA19189; Wed, 6 Apr 94 17:44:24 EDT Received: by relay.tis.com; id AA13955; Wed, 6 Apr 94 17:45:08 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma013950; Wed Apr 6 17:44:18 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA04842; Wed, 6 Apr 94 14:33:41 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA10640; Wed, 6 Apr 1994 17:35:09 -0400 Message-Id: <9404062135.AA10640@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 "Wed, 06 Apr 94 16:37:16 +0200." <9404060737.AA26241@necom830.cc.titech.ac.jp> Date: Wed, 06 Apr 94 17:35:09 -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: <9404042047.AA28553@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Apr 4, 94 4:47 pm >> >SIGs are less valuable than glue As because they can be asked with a separate >> >query. >> >> Why can't you ask for the glue A's in a separate query? > >Sigh... To make the query, you must know A's. Read the section 4.2.1 >of RFC1034, if you can't understand it. 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? >The point here is that truncation is a real issue only for >glue records. So, you don't have to think truncation of >SIG or RSA records in additional section so seriously. 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. So I guess if you want it changed to give A records higher priority, I don't see that it hurts any. >In general, you are trying to do: > 1) Make DNS secure > 2) Make DNS reply short > >In doing 2), your proposal includes several modificatiton to the >architecture of DNS. But as the truncation is not a so severe >issue, I don't think its worthwhile to do so. > >So, I suggest not to pursue 2) so much and simplify the proposal. > >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. 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. >> >Moreover, aren't the current name servers copying the unused bits >> >of query packets? >> >> I don't see what that has to do with the location of spontaneously >> included SIG RRs on queries from security aware resolvers to security >> aware servers, which is what I was discussing. If a security aware >> resolver makes a query with the (SD) bit on in the header to a >> non-security aware server, it will probably be copied into the >> response, but so what? > >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. 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. >> >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. 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. >> 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. 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. >> 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. >> As >> tentatively decided at the DNSSEC WG meeting in Seattle, I would wait >> for implementation experience to indicate the need before changing >> this aspect of the draft. > >If it is option, what will be implemented? One would guess that if something is an implementation option and there are enough different implemenations, it would be implemented both ways, although the draft clearly recommends surpressing RRs incorprated in a SIG (but only when a security aware server is composing a reply to a security aware resolver) so maybe everyone would implement it that way. Maybe the draft should be changed to say the supression is mandatory... >> 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. >> 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. >> Even assuming you can get things to fit in 512 byte UDP datagrams with >> your simplifications, which is not clear to me, and even if it is >> "rare" for for there to be more than 6 RR types for a given owner name >> and class, I find it totally unacceptable to only secure common cases >> in the DNS. I believe that a DNS security proposal must cover all but >> the most preverse cases. > >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. > Masataka Ohta To: Masataka Ohta cc: "Donald E. Eastlake 3rd" , dns-security@tis.com In-reply-to: Your message of "Wed, 06 Apr 94 16:58:48 +0200." <9404060759.AA26399@necom830.cc.titech.ac.jp> -------- From: Masataka Ohta To: "Donald E. Eastlake 3rd" Cc: dns-security@tis.com In-Reply-To: <9404042047.AA28553@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Apr 4, 94 4:47 pm >I found the current proposal unnecessarily contains real truncation >problem. > >As the largest modulus is 2048 bits, usual key size will be about 1000 >bits or 130 bytes. The largest modulus allowed in the present proposal is 2040 bits and it claims to impose a floor of 641 bits but there is no enforecment mechanism proposed for this minimum. (At one point I was considering enforcing this by having the modulus length of the key be the modulus length byte as an unsigned integer plus 64. This would really impose a 512 bit floor and allow moduluses up to 2552 bits.) >If such a large key is chosen by administrators (as the cost to choose >the longer key is not so large, most of the security conscious >administrators (that is, all those who use secure DNS) will use the >largest possible, I think), a DNS packet containing 4 keys will be >truncated. ? The largest key modulus is 2040 bits so I don't understand why you say administrators who will use the largest possible will use 1000 bits. I should think DNS administrators will try to pick what works best. We can recommend things in the standard. I think a lot of people will use keys around 800 or 900 bits which is quite safe for now. The draft allows up to over 2000 bits for possible use later when computers and factoring algorithms have gotten better. Probably by then some way to great around the 512 byte DNS UDP limit will be in effect also. >As having 2 keys for a single purpose is usually enough, it should not >be an issue. > >But the current proposal assign only a single RSA RR name to 3 >different purposes: authentication of a zone, a host and a user. >So, real truncation may occur. > >Moreover, it will make additional section processing difficult causing >a lot of truncations. > >So, we should have 3 different RR names for 3 different purposes: >ZRSA for zones, HRSA for hosts, and MRSA for mails. Although I think it will be extremely rare for the same name to be a zone, a host, and a user, this is an interesting proposal. It is the case that the different types of RSA RR were going to have to be additional info for different types of queries. For exmple, the Zone RSA if you get NS, the Host RSA if you get A, and the User RSA if you get some of the more obsure M* RRs (but not MX which is a host). I would assume that all the additional section processing in current implementations uses type and would prefer not to delve into the RDATA area as would be required in the current proposal. You would still need the flags byte for the mandatory and authority bits. It does use up more RR type numbers but overall I think it is a good idea. What do other people think about it? > Masataka Ohta Donald   Received: from sol.tis.com by magellan.TIS.COM id aa17030; 6 Apr 94 23:15 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA28908; Wed, 6 Apr 94 23:15:09 EDT Received: by relay.tis.com; id AA15740; Wed, 6 Apr 94 23:15:54 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma015712; Wed Apr 6 23:14:57 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 7 Apr 94 12:04:19 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404070304.AA00261@necom830.cc.titech.ac.jp> Subject: Re: SIG RR location in responses & Re: Real truncation problem To: "Donald E. Eastlake 3rd" Date: Thu, 7 Apr 94 12:04:18 JST Cc: dns-security@tis.com In-Reply-To: <9404062135.AA10640@skidrow.lkg.dec.com>; from "Donald E. Eastlake 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. What do you think "truncation problem" means, at all? > 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 > >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. > 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. > >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. > 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. > >> >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. > >> 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. > 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. 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. > >> 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. > >> 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. > >> 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. > >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. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa27610; 7 Apr 94 17:25 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02805; Thu, 7 Apr 94 17:25:20 EDT Received: by relay.tis.com; id AA20789; Thu, 7 Apr 94 17:26:05 EDT Received: from ns.novell.com(137.65.1.1) by relay via smap (V1.3mjr) id sma020781; Thu Apr 7 17:25:34 1994 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA04899; Thu, 7 Apr 94 15:30:18 MDT Received: from [130.57.64.147] by WC.Novell.COM (4.1/SMI-4.1) id AA25281; Thu, 7 Apr 94 14:24:54 PDT Date: Thu, 7 Apr 94 14:24:53 PDT Message-Id: <9404072124.AA25281@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: dns-security@tis.com From: Greg Minshall Subject: DNS security draft Some thoughts on the DNS security draft: 4. Could at least the SA (security available) bit be carried in some other form rather than one of the reserved bits in the header? Inferred, say, from the presence of an unsolicited SIG? Or, some other unsolicited record in the reply? 5.1. Can a *request* be authenticated? 5.1.3.1. What if a resolver doesn't grok an IN A direct encoding (but DOES grok vanilla IN A records)? I.e., how can a resolver ask for a vanilla encoding (with a hashed signet)? Greg Minshall   Received: from sol.tis.com by magellan.TIS.COM id aa28700; 7 Apr 94 23:23 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA09852; Thu, 7 Apr 94 23:22:54 EDT Received: by relay.tis.com; id AA22174; Thu, 7 Apr 94 23:23:41 EDT Received: from tsx-11.mit.edu(18.172.1.2) by relay via smap (V1.3mjr) id sma022171; Thu Apr 7 23:22:47 1994 Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA07286; Thu, 7 Apr 94 23:21:26 EDT Date: Thu, 7 Apr 94 23:21:26 EDT From: Theodore Ts'o Message-Id: <9404080321.AA07286@tsx-11.MIT.EDU> To: Paul A Vixie Cc: dns-security@tis.com In-Reply-To: Paul A Vixie's message of Wed, 6 Apr 94 13:26:57 -0700, Subject: Re: Possible use of public key technology in DNS authentication Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Date: Wed, 6 Apr 94 13:26:57 -0700 From: Paul A Vixie IF a DNS Security protocol is approved by the IAB, AND that protocol specifies the use of a PK system AND the PK system specified is one patented by RSA THEN (1) will i be in trouble if i publish a version of BIND that includes full source code to the implementation of the above If you publish a version of BIND that references routines used in the RSAREF library, you're fine. The RSAREF library has been released by RSADSI, and includes a free, personal, non-commercial use license to use the routines in that library, which include RSA and a routine to do Diffie-Helman key exchange. Recently that license has been expanded to include use by commercial companies so long as the use of RSAREF does not directly contribute to their commercial dealings. Since DNS is basically a infrastructure service, this would mean that any company would be able to get and compile RSAREF and use it for their own internal use without any problems. (2) will i have to alter my existing BSD-derived copyright in any way (it currently specifies unlimited use and unlimited redistribution) The copyright on your code can remain the same; this doesn't affect the copyright on the RSAREF code, though. (3) will vendors who include such a BIND in their operating systems be at risk from lawsuits from RSA if they don't pay license fees to RSA? If vendors include such in the operating system, they will indeed need to get a license from RSA before they can distribute it. RSA in DNS would have much a broader effect: within a few years after Secure DNS is implemented, *noone* will be able to use the Internet without using the RSA technology. If the only people who are allowed to *use* the RSA technology are those who are either not doing commerce on the Internet or who pick up BIND on their own because their vendor doesn't want to pay RSA's license fees or doesn't include BIND at all, then I believe we'll have done a very bad thing. The overwhelming majority of new Internet hosts use system software straight from their vendors. I don't buy that. DNS resolvers will be able to use the internet without using RSA --- they just won't be able to verify the veracity of the nameserver records just like today. As for people who run name servers for their domains, they can either let their regional network run it, or they can grab your freely available source code and a copy of RSAREF, and compile their own. Actually, I expect that in a few years, hopefully the vendors will also be supplying a Secure DNS. Keep in mind that the IP Security working group is currently talking about using Diffie-Helman to secure IP connections --- and the patent for Diffie-Helman is also controlled by RSADSI. Like it or not, most of the good schemes for doing wide-area cryptography (RSA, Diffie-Helman, etc.) are controlled by RSADSI. At some level, though, while these issues are important, I don't think this is the best place to be addressing them, since they apply to more than one working group. Perhaps we should just concentrate on getting the technical issues right, and let the IESG debate the patent issues? I am quite certain that if we let ourselves get tied up in the patent nonsense, we won't make any progress. - Ted   Received: from sol.tis.com by magellan.TIS.COM id aa01796; 8 Apr 94 11:39 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA29204; Fri, 8 Apr 94 11:39:02 EDT Received: by relay.tis.com; id AA25776; Fri, 8 Apr 94 11:39:42 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma025771; Fri Apr 8 11:38:47 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA12607; Fri, 8 Apr 94 08:00:27 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA14418; Fri, 8 Apr 1994 11:01:59 -0400 Message-Id: <9404081501.AA14418@skidrow.lkg.dec.com> To: dns-security@tis.com Subject: RR Type assignments Date: Fri, 08 Apr 94 11:01:58 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp IANA has assignged type number 24 for the proposed SIG (signature) RR and type number 25 for the proposed RSA (key) RR. I'm edited these into the draft. 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 aa02251; 8 Apr 94 13:02 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02538; Fri, 8 Apr 94 13:02:25 EDT Received: by relay.tis.com; id AA26488; Fri, 8 Apr 94 13:03:12 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma026484; Fri Apr 8 13:02:26 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA20908; Fri, 8 Apr 94 09:58:27 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA16062; Fri, 8 Apr 1994 12:59:53 -0400 Message-Id: <9404081659.AA16062@skidrow.lkg.dec.com> To: Stephen D Crocker Cc: Hilarie Orman , namedroppers@nic.ddn.mil, dns-security@tis.com Subject: Re: Possible use of public key technology in DNS authentication In-Reply-To: Your message of "Wed, 06 Apr 94 08:45:09 EDT." <9404061245.AA12855@tis.com> Date: Fri, 08 Apr 94 12:59:53 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp My interpretation of the current RSAREF license is that "non-commercial" use would include offering a service where RSA was needed for an essential part of the service. I don't think there would be any problem where RSA was part of something incidental such as normal DNS use. On the "free implementation" aspect, the general RSAREF license restricts you to using the defined interfaces although you can change the inards as much as you want, presumably even to completely replacing them. Also, as far as I am aware, no one who has ever asked to get a variance to use different interfaces for some stated purpose has ever been turned down. As a reality check, I think people should note that (1) RSA is still only patented in the United States of America and (2) most UNIX vendors have already licensed RSA. So if RSA is used in secure DNS, as far as I can till it will not affect people outside the US, people who want to use it non-commercially in the US will have no problem, and, at worst, people who want to use it commerically inside the US will simply have to buy their initial DNS software with an RSA sub-license from HP or SUN or DEC or any of the other zillions of companies that already have a general RSA license. It would be nice if once could wave a magic wand and avoid all the political/export/patent problems of cryptographic security but I don't see how to do that. Donald (not a lawyer) From: Stephen D Crocker To: Hilarie Orman Cc: crocker@tis.com Cc: namedroppers@nic.ddn.mil, dns-security@tis.com In-Reply-To: Your message of "Tue, 05 Apr 94 22:00:58 PDT." <199404060500.WAA04399@baskerville.cs.arizona.edu> >Hilarie, > >I focused on 5.4.2(a)2 because it pertained to implementation. So far >as I can tell, the full assurances required under 5.4.2(A)1, 5.4.2(A)2 >and 5.4.2(A)3 were obtained previously, as documented in RFC 1170. As >I said before, it's entirely reasonable to revisit and redocument the >details, but my strong belief is that this is not a showstopper and >should not affect our design choices. > >With respect to your second question, are you asking the generic >question about patent law, i.e. (a) "are implementors free to implement > for non-commercial use?", or are you asking (b) whether >RSA has provided general permission for free implementation of their >technology for non-commercial use? As neither a lawyer nor an RSA >representative, I can give only my general understanding, which is (a) >I believe patents cover all use, commercial or not, and (b) I don't >think RSA has given blanket permission for non-commercial >implementations other than through RSAREF, but I strongly recommend >you take this up with them. > >Steve > >> From: Hilarie Orman >> To: crocker@tis.com >> cc: namedroppers@nic.ddn.mil, dns-security@tis.com >> Date: Tue, 5 Apr 1994 22:00:58 -0700 >> Subject: Re: Possible use of public key technology in DNS authentication >> >> Is this to say that the assurances required under 5.4.2(A)1 and 3 have >> not been provided? If this is correct, will someone be talking to RSA >> about getting the assurances? >> >> Another question: are implementors free to implement RSA patented >> algorithms for non-commercial use? Or are they only free to use >> RSAREF?   Received: from sol.tis.com by magellan.TIS.COM id aa02375; 8 Apr 94 13:21 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA03270; Fri, 8 Apr 94 13:21:32 EDT Received: by relay.tis.com; id AA26623; Fri, 8 Apr 94 13:22:19 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma026618; Fri Apr 8 13:21:48 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA22314; Fri, 8 Apr 94 10:18:36 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA16274; Fri, 8 Apr 1994 13:20:07 -0400 Message-Id: <9404081720.AA16274@skidrow.lkg.dec.com> To: Greg Minshall Cc: dns-security@tis.com Subject: Re: DNS security draft In-Reply-To: Your message of "Thu, 07 Apr 94 14:24:53 PDT." <9404072124.AA25281@WC.Novell.COM> Date: Fri, 08 Apr 94 13:20:07 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Greg, From: Greg Minshall To: dns-security@tis.com >Some thoughts on the DNS security draft: >4. Could at least the SA (security available) bit be carried in some other >form rather than one of the reserved bits in the header? Inferred, say, >from the presence of an unsolicited SIG? Or, some other unsolicited record >in the reply? Yes, this could be carried in another way. A normal unsolicited SIG or RSA just added as additional information might not fit or might cause trunction. However, we could make up a very short (one byte of RDATA) RR (probably an RSA with a special bit set in its RDATA flag byte) that could be returned as additional information to substitute for the SA header bit and something similar that could be provided as additional data as part of the query to substitute for the SD header bit. Since current BIND tends to ignore queries with a non-zero additional information count, you would have to be careful not send this "SD" indication RR unless you have had gotten the "SA" indication. I think there are some loose ends here like not getting faked out if you see the "SA" flag just because you did an ANY retreival from some caching server, etc., but it could probably be made to work. >5.1. Can a *request* be authenticated? Well, one of the principles of DNS is supposed to be that it gives everyone the same answer. So we deliberately left out an explicit request authentication mechanism. However, you could certainly tack a SIG with just a hashed query message signet in the additional information section of a query. The server then could, if it wanted to, use this to authenticate the query. The proposal could be changed to require servers to at least ignore such a SIG. Currently it does not even mention their possibility. You have to be careful, however, as many current implementations will ignore queries where the additional info count is non-zero. So you could only do this when you know the server is security aware. Do people think request authentication should be required/optional? >5.1.3.1. What if a resolver doesn't grok an IN A direct encoding (but DOES >grok vanilla IN A records)? I.e., how can a resolver ask for a vanilla >encoding (with a hashed signet)? Such a resolver would not be conformant to the current proposal. And, to be able to answer a query two ways, the server would probably have to pre-calculate two different sets of SIGs and be careful to only send the right one. (Note, although you don't mention the possibility, you could also provide the vanilla A RR and a direct signet inside the SIG.) Since there is concern over the complexity of the current proposal, adding yet more options to queries seems like a bad idea. Either only hashed signets should be used, as Masataka Ohta suggests and you are asking for as a query option, or the current proposal allowing both direct and hashed signets should be followed. Some statistical studies on real zones with reasonable projections of added RSA RRs, key modulus sizes, etc., seems to me like the only way to get data that can be used to answer this. >Greg Minshall Donald   Received: from sol.tis.com by magellan.TIS.COM id aa03421; 8 Apr 94 16:20 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA12033; Fri, 8 Apr 94 16:20:30 EDT Received: by relay.tis.com; id AA28095; Fri, 8 Apr 94 16:21:18 EDT Received: from decvax.zk3.dec.com(16.140.0.3) by relay via smap (V1.3mjr) id sma028090; Fri Apr 8 16:20:38 1994 Received: from abyss.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA05129; Fri, 8 Apr 1994 16:20:22 -0400 Received: by abyss.zk3.dec.com (5.65/DEC-USG-ULTRIX-4.4-03/25/94) id AA19120; Fri, 8 Apr 1994 16:20:21 -0400 Message-Id: <9404082020.AA19120@abyss.zk3.dec.com> To: Greg_Minshall@novell.com Cc: dns-security@tis.com Subject: Re: DNS security draft Date: Fri, 08 Apr 94 16:20:20 -0400 From: kaufman@zk3.dec.com X-Mts: smtp I agree with Don's responses, but would append a suspicious "why do you ask?". >4. Could at least the SA (security available) bit be carried in some other >form rather than one of the reserved bits in the header? Inferred, say, >from the presence of an unsolicited SIG? Or, some other unsolicited record >in the reply? Are you concerned about interoperability, trying to preserve a bit for some future use, or just trying to simplify the protocol? A resolver needs to know whether a server supports the protocol so that - if not - it can explicitly request SIG records. There are clever ways it could figure that out without a bit in the formats, but it wouldn't simplify the protocol in practice. >5.1. Can a *request* be authenticated? I suppose, but why would you want to? What would DNS do with this information? Did you have access control in mind? An earlier draft proposal included this functionality, but we took it out because it seemed what users really wanted was to know that a given response was the response to its actual query (and not some modified version). That protection is included. >5.1.3.1. What if a resolver doesn't grok an IN A direct encoding (but DOES >grok vanilla IN A records)? I.e., how can a resolver ask for a vanilla >encoding (with a hashed signet)? When might this happen? Do you have in mind a partially implemented resolver that understands hashed signets but not direct encodings? I can't think of why anyone would implement such a thing. You certainly have to be able to request a vanilla encoding and no signature for backwards compatibility with non-security aware resolvers. I guess I can imagine a case where a security aware resolver lacks the particular public key needed to decrypt some SIG. Is this the case you're worried about? --Charlie (kaufman@zk3.dec.com)   Received: from sol.tis.com by magellan.TIS.COM id aa05296; 9 Apr 94 14:46 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA03611; Sat, 9 Apr 94 14:45:58 EDT Received: by relay.tis.com; id AA03823; Sat, 9 Apr 94 14:46:47 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma003819; Sat Apr 9 14:46:00 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA25331; Sat, 9 Apr 94 11:43:36 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA28629; Sat, 9 Apr 1994 14:45:09 -0400 Message-Id: <9404091845.AA28629@skidrow.lkg.dec.com> To: dns-security@tis.com Subject: Security AD's assesment re RSAREF licensing Date: Sat, 09 Apr 94 14:45:09 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Forwarded with permission. ------- Forwarded Message Donald From: Jeffrey I. Schiller To: dee > My reading of the current RSAREF license, which I assume are their > general terms, is that you would have to pay if you had something > using RSA as an essential part of providing a service (ie, some secure > network service dependent on dns security even if you were using > freeware BIND) as well as if you incorporated RSA into a product you > sold (ie, a vendor version of BIND). Do you think RSA would be > willing to be more liberal than this? > >Obviously I cannot speak for RSADSI, but I can venture my vision of what >I believe they will and will not be willing to do (so to speak!). They >will certainly want any vendor selling a commercial version of BIND >(either stand alone or as part of an operating system product) to pay a >royalty. However many of the existing computer vendors (DEC, Sun, etc.) >are already licensees so this isn't a problem. Note: Customers of these >companies will probably be able to use the enhanced BIND that comes with >their operating system for any purpose that they want, commercial or >otherwise. In essence the vendor incorporates the license in the >version of bind shipped with the system. For example Lotus Notes uses >the RSA system internally (users in fact have a key pair) and commercial >organizations may purchase Notes and use it for whatever they want. The >fact that the RSA system is patented is already taken care of in the >license that Lotus has with RSADSI. > >A "freeware" version of bind may be developed and distributed on the >Internet via anonymous FTP according to the terms of the RSAREF >license. Anyone can copy and make use of such a freeware version, >including commercial entities as long as they do not directly use the >secure DNS as a fundamental portion of a service that they offer for >pay. > >Example: > >o If I am a commercial organization and I use secure DNS in order to > authenticate hosts on the network I am probably just fine. > >o On the otherhand if I am a commercial organization and I sell > information over the network, but only to hosts that I can authenticate > with the secure DNS, then I probably have to pay a royalty *to use the > freeware version*. If I base my system on a commercial product that is > "fully" licensed, I shouldn't need to worry. > >Jim Bidzos told me that he is actively working on figuring out how to >offer "hassle free" commercial licenses where people can make commercial >use of things like RSAREF and pay RSADSI a (small) royalty without >having to negotiate a complex license. Jim appears to have realized that >the network may present him with a customer base larger then his current >organization is capable of physically dealing with unless they come up >with some for of electronic "auto licensing" etc. > >Btw. It probably makes sense to implement secure DNS in such a fashion >that the RSA operations are abstracted into a separate module which >contains the appropriate #ifdef's to handle either RSAREF (for the >freeware version) or BSAFE (for the commercial companies that probably >already have a BSAFE license arrangement). > > -Jeff ------- End of Forwarded Message   Received: from sol.tis.com by magellan.TIS.COM id aa09221; 11 Apr 94 10:32 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA14823; Mon, 11 Apr 94 10:32:18 EDT Received: by relay.tis.com; id AA13515; Mon, 11 Apr 94 10:33:09 EDT Message-Id: <9404111433.AA13515@relay.tis.com> Received: from ninet.research.att.com(192.20.225.3) by relay via smap (V1.3mjr) id sma013507; Mon Apr 11 10:32:59 1994 From: smb@research.att.com Received: by gryphon; Mon Apr 11 10:27:43 EDT 1994 To: Masataka Ohta Cc: "Donald E. Eastlake 3rd" , crocker@tis.com, ho@cs.arizona.edu, namedroppers@nic.ddn.mil, dns-security@tis.com Subject: Re: Possible use of public key technology in DNS authentication Date: Mon, 11 Apr 94 10:27:42 EDT > As a reality check, I think people should note that (1) RSA is still > only patented in the United States of America and I know patent system in US is broken. Anyway... Does someone know when the patent will expire? September 19, 2000. > My interpretation of the current RSAREF license As copyright lasts much longer than patent, it's better not to depend on licenced code. After the patent expires, we should be absolutely free. > On the "free implementation" aspect, the general RSAREF license > restricts you to using the defined interfaces although you can chang e > the inards as much as you want, presumably even to completely > replacing them. Is RSA Inc. trying to protect the interface specification with copyright? If so, I don't think it appropriate to use it as Internet Standard. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa08649; 11 Apr 94 6:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA04460; Mon, 11 Apr 94 04:56:18 EDT Received: by relay.tis.com; id AA11621; Mon, 11 Apr 94 04:57:09 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma011616; Mon Apr 11 04:56:44 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 11 Apr 94 17:48:08 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404110848.AA21154@necom830.cc.titech.ac.jp> Subject: Re: Possible use of public key technology in DNS authentication To: "Donald E. Eastlake 3rd" Date: Mon, 11 Apr 94 17:48:07 JST Cc: crocker@tis.com, ho@cs.arizona.edu, namedroppers@nic.ddn.mil, dns-security@tis.com In-Reply-To: <9404081659.AA16062@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Apr 8, 94 12:59 pm X-Mailer: ELM [version 2.3 PL11] > As a reality check, I think people should note that (1) RSA is still > only patented in the United States of America and I know patent system in US is broken. Anyway... Does someone know when the patent will expire? > My interpretation of the current RSAREF license As copyright lasts much longer than patent, it's better not to depend on licenced code. After the patent expires, we should be absolutely free. > On the "free implementation" aspect, the general RSAREF license > restricts you to using the defined interfaces although you can change > the inards as much as you want, presumably even to completely > replacing them. Is RSA Inc. trying to protect the interface specification with copyright? If so, I don't think it appropriate to use it as Internet Standard. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa13091; 11 Apr 94 12:54 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA21568; Mon, 11 Apr 94 12:54:05 EDT Received: by relay.tis.com; id AA15008; Mon, 11 Apr 94 12:54:55 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma015000; Mon Apr 11 12:54:40 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA11574; Mon, 11 Apr 94 09:48:59 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA15440; Mon, 11 Apr 1994 12:50:27 -0400 Message-Id: <9404111650.AA15440@skidrow.lkg.dec.com> To: Masataka Ohta Cc: dns-security@tis.com Subject: Re: DNS security draft In-Reply-To: Your message of "Mon, 11 Apr 94 20:27:59 +0200." <9404111128.AA22598@necom830.cc.titech.ac.jp> Date: Mon, 11 Apr 94 12:50:27 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: Masataka Ohta In-Reply-To: <9404082020.AA19120@abyss.zk3.dec.com>; from "kaufman@zk3.dec.com" at Apr 8, 94 4:20 pm >> I agree with Don's responses, but would append a suspicious "why do you ask?". >> >> >4. Could at least the SA (security available) bit be carried in some other >> >form rather than one of the reserved bits in the header? Inferred, say, >> >from the presence of an unsolicited SIG? Or, some other unsolicited record >> >in the reply? >> >> Are you concerned about interoperability, trying to preserve a bit >> for some future use, or just trying to simplify the protocol? A resolver >> needs to know whether a server supports the protocol so that - if not - it >> can explicitly request SIG records. There are clever ways it could figure >> that out without a bit in the formats, but it wouldn't simplify the >> protocol in practice. > >While SD is useful to affect additional section processing, SA is >useless. If you believe that the SA (Security Available) bit is useless, do you also believe that the recursion available bit in the DNS message header is useless? >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. If they show a zone as having no key, then it would assume there are no SIGs. If they show a zone as having a key with the mandatory bit off, it might have SIGs or it might not. If they show a zone with a key with the mandatory bit on, then it has to have SIGs. 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. >> >5.1.3.1. What if a resolver doesn't grok an IN A direct encoding (but DOES >> >grok vanilla IN A records)? I.e., how can a resolver ask for a vanilla >> >encoding (with a hashed signet)? >> >> When might this happen? > >It can't happen, which is why I think the current proposal is too much >complex. > > Masataka Ohta Donald   Received: from sol.tis.com by magellan.TIS.COM id aa13140; 11 Apr 94 13:04 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA21984; Mon, 11 Apr 94 13:04:07 EDT Received: by relay.tis.com; id AA15084; Mon, 11 Apr 94 13:04:58 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma015076; Mon Apr 11 13:04:51 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA11981; Mon, 11 Apr 94 09:55:02 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA15535; Mon, 11 Apr 1994 12:56:34 -0400 Message-Id: <9404111656.AA15535@skidrow.lkg.dec.com> To: Masataka Ohta Cc: dns-security@tis.com Subject: Re: Possible use of public key technology in DNS authentication In-Reply-To: Your message of "Mon, 11 Apr 94 17:48:07 +0200." <9404110848.AA21154@necom830.cc.titech.ac.jp> Date: Mon, 11 Apr 94 12:56:34 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: Masataka Ohta To: dee (Donald E. Eastlake 3rd) Cc: crocker@tis.com, ho@cs.arizona.edu, namedroppers@nic.ddn.mil, dns-security@tis.com In-Reply-To: <9404081659.AA16062@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Apr 8, 94 12:5 9 pm X-Mailer: ELM [version 2.3 PL11] >> My interpretation of the current RSAREF license > >As copyright lasts much longer than patent, it's better not to depend >on licenced code. Although there are some references to copyright, I believe the RSAREF license is primarily a patent right license. >After the patent expires, we should be absolutely free. > >> On the "free implementation" aspect, the general RSAREF license >> restricts you to using the defined interfaces although you can change >> the inards as much as you want, presumably even to completely >> replacing them. > >Is RSA Inc. trying to protect the interface specification with >copyright? If so, I don't think it appropriate to use it as >Internet Standard. No, I think they are just using granting permission under their patent(s) limited in this case by the RSAREF interface spec. > Masataka Ohta Donald   Received: from sol.tis.com by magellan.TIS.COM id aa09014; 11 Apr 94 9:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA06574; Mon, 11 Apr 94 07:13:40 EDT Received: by relay.tis.com; id AA12289; Mon, 11 Apr 94 07:14:31 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma012285; Mon Apr 11 07:13:44 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 11 Apr 94 20:07:47 +0859 From: Masataka Ohta Return-Path: Message-Id: <9404111108.AA22390@necom830.cc.titech.ac.jp> Subject: Re: Security AD's assesment re RSAREF licensing To: "Donald E. Eastlake 3rd" Date: Mon, 11 Apr 94 20:07:46 JST Cc: dns-security@tis.com In-Reply-To: <9404091845.AA28629@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Apr 9, 94 2:45 pm X-Mailer: ELM [version 2.3 PL11] > Forwarded with permission. > From: Jeffrey I. Schiller > >A "freeware" version of bind may be developed and distributed on the > >Internet via anonymous FTP according to the terms of the RSAREF > >license. Why the "freeware" version is restricted by the license? As far as I know, non-commercial use of patent is free from licensing. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa08802; 11 Apr 94 7:36 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA07093; Mon, 11 Apr 94 07:35:44 EDT Received: by relay.tis.com; id AA12393; Mon, 11 Apr 94 07:36:35 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma012389; Mon Apr 11 07:36:14 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 11 Apr 94 20:28:01 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404111128.AA22598@necom830.cc.titech.ac.jp> Subject: Re: DNS security draft To: kaufman@zk3.dec.com Date: Mon, 11 Apr 94 20:27:59 JST Cc: Greg_Minshall@novell.com, dns-security@tis.com In-Reply-To: <9404082020.AA19120@abyss.zk3.dec.com>; from "kaufman@zk3.dec.com" at Apr 8, 94 4:20 pm X-Mailer: ELM [version 2.3 PL11] > I agree with Don's responses, but would append a suspicious "why do you ask?". > > >4. Could at least the SA (security available) bit be carried in some other > >form rather than one of the reserved bits in the header? Inferred, say, > >from the presence of an unsolicited SIG? Or, some other unsolicited record > >in the reply? > > Are you concerned about interoperability, trying to preserve a bit > for some future use, or just trying to simplify the protocol? A resolver > needs to know whether a server supports the protocol so that - if not - it > can explicitly request SIG records. There are clever ways it could figure > that out without a bit in the formats, but it wouldn't simplify the > protocol in practice. While SD is useful to affect additional section processing, SA is useless. A resolver must be able to securely know whether SIG RRs are available or not for which purpose SA is nothing. > >5.1.3.1. What if a resolver doesn't grok an IN A direct encoding (but DOES > >grok vanilla IN A records)? I.e., how can a resolver ask for a vanilla > >encoding (with a hashed signet)? > > When might this happen? It can't happen, which is why I think the current proposal is too much complex. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa18246; 11 Apr 94 18:43 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA06690; Mon, 11 Apr 94 18:43:39 EDT Received: by relay.tis.com; id AA17550; Mon, 11 Apr 94 18:44:31 EDT Received: from gw.home.vix.com(192.5.5.1) by relay via smap (V1.3mjr) id sma017546; Mon Apr 11 18:44:26 1994 Received: by gw.home.vix.com id AA25306; Mon, 11 Apr 94 15:44:06 -0700 Date: Mon, 11 Apr 94 15:44:06 -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: Security AD's assesment re RSAREF licensing Organization: Vixie Enterprises Message-Id: References: <9404111108.AA22390@necom830.cc.titech.ac.jp> Nntp-Posting-Host: office.home.vix.com In-Reply-To: mohta@necom830.cc.titech.ac.jp's message of 11 Apr 1994 07:00:58 -0700 >>>A "freeware" version of bind may be developed and distributed on the >>>Internet via anonymous FTP according to the terms of the RSAREF >>>license. >Why the "freeware" version is restricted by the license? > >As far as I know, non-commercial use of patent is free from licensing. If a BIND distribution includes only hooks for RSAREF without including RSAREF itself, then no change needs to be made to the BIND license. If, however, BIND includes portions of RSAREF, then those portions will still be covered by the RSA license. Noncommercial users won't be affected by the RSA license, since the terms of the RSA license that affect non- commercial users are substantially equal to the existing terms of the BSD and DEC copyrights that BIND is already subject to. However, none of BIND's current module copyrights restricts commercial use or redistribution (other than that the copyrights themselves must not be removed or altered, and other reasonable, "free" things). I am still pondering at least two issues: should the IETF or IAB specify a packet encoding which commercial users _cannot_use_ without paying a license fee or patent royalty to RSA? And: if that happens in spite of my protests, should BIND even include RSAREF, or just hooks and patches for it so that someone who wants it can pull it from RSA's ftp server and easily integrate it? Various politicking is still going on privately, but as far as I know, the author of the current RSA-based IP/DNS Security proposal has summarily written off my concerns. -- Paul Vixie Redwood City, CA decwrl!vixie!paul   Received: from sol.tis.com by magellan.TIS.COM id aa25028; 12 Apr 94 19:24 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA11918; Tue, 12 Apr 94 19:24:22 EDT Received: by relay.tis.com; id AA28489; Tue, 12 Apr 94 19:25:15 EDT Received: from dell1.us.dell.com(143.166.224.203) by relay via smap (V1.3mjr) id sma028481; Tue Apr 12 19:24:57 1994 Received: from upurbmw.us.dell.com by dell1.us.dell.com (4.1/DELL-GATEWAY-SENDMAIL-5.67) id AA06963; Tue, 12 Apr 94 18:24:24 CDT Received: by upurbmw.us.dell.com (931110.SGI/930416.SGI) for @dell1.us.dell.com:dns-security@tis.com id AA01446; Mon, 11 Apr 94 18:26:35 -0500 From: "Steven C. Blair" Message-Id: <9404111826.ZM1444@upurbmw.us.dell.com> Date: Mon, 11 Apr 1994 18:26:35 -0500 In-Reply-To: James M Galvin "Re: SIG RR location in responses" (Apr 5, 10:29am) References: <9404051030.aa03631@magellan.TIS.COM> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: James M Galvin , Paul A Vixie Subject: Re: SIG RR location in responses..several comments. Cc: dns-security@tis.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Pardon me for melting three messages into one, but after reading a week of this subject, I feel that three good points, and apologize for my tardiness in replying. vixie: ------ Am I the only person reading all this who is concerned about using RSA, a patented and licensed technology, for DNS security? I am very reluctant to put into BIND any technology which would require vendors to pay a royalty to RSA before they could ship it with their systems. I for one am still thinking about what the overseas folks will do Paul. May I remind all about Austin Code Works and the current legal issue just surrounding PgP? Vendors are having a hard enough time keeping up with things as fast as they change. Not all companies have mechinisms in place that can support the audit trails well enough to be defeneded in court when RSA, etc. al., decides that they may not be getting their fair share of $$'s from the licensing issues. There are no clear winners, the vendor, the customers, loose, and the lawyers win. That is not the direction I'd like to see BIND/dnssec go. galvin: -------- Two bits of information to keep in mind. First, RSADSI has made RSAREF available for non-commercial use. However, I realize this does not solve the "vendors packaging a product." For that, may I direct your attention to the latest issue of Connexions, March 1984, in which commandment number 1 of "The Ten Commandments of Domain Name Service" is, "Thou shalt not run thy vendor's DNS software." That statement is personally disappointing James. It is a far cry from reality then if you consider that almost 50%(IMHO) of customers DO RUN the vendor shipped code. At least until it bites them in the arse. We have to keep in mind with anything that we consider publishing that customers may/may not have the smarts to run it, and not everyone has time to port every single "steenking piece of code" to get the latest-and-greatest widget. I feel that Art Harkin was right on the point: -------------------------------------------------- Where I feel the danger lies is how this 'problem' has been intepreted into a rule that vendor software is to be discarded. This might be a simplistic view, there are many network admins unwilling to delve into the issues of running unsupported software. Not recognizing this can cause problems later. I feel a better approach is to encourage rapid deployment of new features in both commercial and non-commercial arenas. Crocker: --------- As neither a lawyer nor an RSA representative, I can give only my general understanding, which is (a) I believe patents cover all use, commercial or not, and (b) I don't think RSA has given blanket permission for non-commercial implementations other than through RSAREF, but I strongly recommend you take this up with them. > I think we all better have a talk with RSA before this continues < > much further. Admins who can barely runa site now will be totally < > screwed if they can't understand what we implement. If the RSA < > folks are on this list, now is the time to speak up folks. < -- Steven C. Blair dell computer corp "Professionals are predictable, it's the amateurs that are dangerous"   Received: from sol.tis.com by magellan.TIS.COM id aa19061; 12 Apr 94 2:20 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA17038; Tue, 12 Apr 94 02:20:12 EDT Received: by relay.tis.com; id AA19855; Tue, 12 Apr 94 02:21:03 EDT Received: from gw.home.vix.com(192.5.5.1) by relay via smap (V1.3mjr) id sma019849; Tue Apr 12 02:20:09 1994 Received: by gw.home.vix.com id AA03819; Mon, 11 Apr 94 23:19:22 -0700 Message-Id: <9404120619.AA03819@gw.home.vix.com> X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: Masataka Ohta Cc: dns-security@tis.com Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of "Tue, 12 Apr 1994 12:54:21 +0200." <9404120354.AA26666@necom830.cc.titech.ac.jp> Date: Mon, 11 Apr 1994 23:19:21 -0700 From: Paul A Vixie > 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. > I think you should protest against bread-dead patent policy of your country. "never try to teach a pig to sing. it wastes your time, and it annoys the pig." -- lazarus long > > If a BIND distribution includes only hooks for RSAREF without including > > RSAREF itself, then no change needs to be made to the BIND license. > > I don't think so. As far as the patent protection, which is a protection > over idea, concerns, BIND is binded till the year 2000. > > That is, if your program use the "idea" of the patent, the idea on public > and private keys, it can't be used commercially without proper licensing. i've pretty much convinced myself that if the RSA specification goes through, BIND will have to support it somehow. however, i will never include any code in the release which has a restricted distribution other than the usual limits of the BSD copyrights (which require mainly that the copyright and attributions not be altered or removed). this means that a BIND kit that "works with" RSA- licensed software will require a BIND user to acquire their own copy of RSA's software and "link it into" BIND. > > However, none of > > BIND's current module copyrights restricts commercial use or redistribution > > (other than that the copyrights themselves must not be removed or altered, > > and other reasonable, "free" things). > > The copyright issue can be easily avoidable, unless the copyright > holder claims that "interface specification" is copyrightable. if RSA attempts to require something like the following code segment, written by me, to be covered by their license, then BIND will simply never (officially) use RSAREF, and there will be other versions of BIND that do include RSAREF but lag substantially in the area of other features: #ifdef USE_RSAREF if (rsaref_getkey(from_addr.sin_addr, buf) == -1) { syslog(LOG_ERROR, "getkey(%s): %m", inet_addr(from_addr.sin_addr)); return (NULL); } #endif /*USE_RSAREF*/ (that's assuming a lot about RSAREF -- i've never seen it and i am only wildly guessing that it might include a function called "rsaref_getkey()" with that implied function signature. but i think you get the idea and now know what i mean by "hooks to use RSAREF".) even if PKP's legal status gives RSA the right to restrict instantiations of the above "interface", i do not think that RSA or any company which valued its public image in even the smallest way would ever try to "protect" those rights. i could be wrong; i'm certainly not a lawyer. it's also devilishly possible that in order to prove due diligence for other patents and other cases, RSA would be _forced_ to bring suit against anyone who published code like the above. it's a funny world sometimes.   Received: from sol.tis.com by magellan.TIS.COM id aa18770; 11 Apr 94 23:39 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA14364; Mon, 11 Apr 94 23:39:35 EDT Received: by relay.tis.com; id AA19103; Mon, 11 Apr 94 23:40:27 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma019099; Mon Apr 11 23:39:32 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 12 Apr 94 12:33:38 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404120333.AA26523@necom830.cc.titech.ac.jp> Subject: Re: Possible use of public key technology in DNS authentication To: "Donald E. Eastlake 3rd" Date: Tue, 12 Apr 94 12:33:37 JST Cc: dns-security@tis.com In-Reply-To: <9404111656.AA15535@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Apr 11, 94 12:56 pm X-Mailer: ELM [version 2.3 PL11] > >> My interpretation of the current RSAREF license > > > >As copyright lasts much longer than patent, it's better not to depend > >on licenced code. > > Although there are some references to copyright, I believe the RSAREF > license is primarily a patent right license. RSAREF in US is protectable both by copyright and patent. They both work for proection. Saying patent protection is "primary" is not meaningful. Copyright protection is, in some sense, stronger because it lasts much longer than patent. So, unless copyright is actively abandoned, we shouldn't use RSAREF. Instead we should replicate it by something with the equal functionality and interface, before formal release. We may do it by ourselves or expect FSF do the job if we think GPL is not so restrictive (I'm somewhat negative to FSF). Then, after the year 2000, all the commercial use of secure BIND will be absolutely free. > >Is RSA Inc. trying to protect the interface specification with > >copyright? If so, I don't think it appropriate to use it as > >Internet Standard. > > No, I think they are just using granting permission under their > patent(s) limited in this case by the RSAREF interface spec. That's fine. But we should make it sure. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa18850; 12 Apr 94 0:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA14670; Mon, 11 Apr 94 23:59:40 EDT Received: by relay.tis.com; id AA19236; Tue, 12 Apr 94 00:00:32 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma019229; Tue Apr 12 00:00:13 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 12 Apr 94 12:54:23 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404120354.AA26666@necom830.cc.titech.ac.jp> Subject: Re: Security AD's assesment re RSAREF licensing To: Paul A Vixie Date: Tue, 12 Apr 94 12:54:21 JST Cc: dns-security@tis.com In-Reply-To: ; from "Paul A Vixie" at Apr 11, 94 3:44 pm X-Mailer: ELM [version 2.3 PL11] > I am still pondering at least two issues: should the IETF or IAB specify a > packet encoding which commercial users _cannot_use_ without paying a license > fee or patent royalty to RSA? Your problem is US domestic. I can use secure RSA-BIND commercially without paying royalities in Japan. Does someone know what happens if my RSA-BIND interact with RSA-BIND in US? > And: if that happens in spite of my protests, I think you should protest against bread-dead patent policy of your country. > >Why the "freeware" version is restricted by the license? > > > >As far as I know, non-commercial use of patent is free from licensing. > > If a BIND distribution includes only hooks for RSAREF without including > RSAREF itself, then no change needs to be made to the BIND license. I don't think so. As far as the patent protection, which is a protection over idea, concerns, BIND is binded till the year 2000. That is, if your program use the "idea" of the patent, the idea on public and private keys, it can't be used commercially without proper licensing. > However, none of > BIND's current module copyrights restricts commercial use or redistribution > (other than that the copyrights themselves must not be removed or altered, > and other reasonable, "free" things). The copyright issue can be easily avoidable, unless the copyright holder claims that "interface specification" is copyrightable. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa24258; 12 Apr 94 15:33 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA26266; Tue, 12 Apr 94 15:33:20 EDT Received: by relay.tis.com; id AA26252; Tue, 12 Apr 94 15:34:13 EDT Received: from decvax.zk3.dec.com(16.140.0.3) by relay via smap (V1.3mjr) id sma026247; Tue Apr 12 15:33:53 1994 Received: from [16.140.64.3] by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA17431; Tue, 12 Apr 1994 10:49:30 -0400 Received: by abyss.zk3.dec.com (5.65/DEC-USG-ULTRIX-4.4-03/25/94) id AA08661; Tue, 12 Apr 1994 10:41:51 -0400 Message-Id: <9404121441.AA08661@abyss.zk3.dec.com> To: paul@vix.com Cc: dns-security@tis.com, kaufman@zk3.dec.com Subject: Re: Security AD's assesment re RSAREF licensing Date: Tue, 12 Apr 94 10:41:44 -0400 From: kaufman@zk3.dec.com X-Mts: smtp >I am still pondering at least two issues: should the IETF or IAB specify a >packet encoding which commercial users _cannot_use_ without paying a license >fee or patent royalty to RSA? And: if that happens in spite of my protests, >should BIND even include RSAREF, or just hooks and patches for it so that >someone who wants it can pull it from RSA's ftp server and easily integrate >it? > >Various politicking is still going on privately, but as far as I know, the >author of the current RSA-based IP/DNS Security proposal has summarily written >off my concerns. I wouldn't say written off so much as resigned. Basically, the sort of security we would like to see in DNS requires public key cryptography and there is no way to use any form of public key cryptography in the U.S. without dealing with RSADSI or PK Partners on whatever terms they dictate. The IETF and the IAB could be hardnosed and say "if it's not free, we won't standardize it". Such a stance might cause some people to abandon their patents, but it's not likely to work with RSADSI. More likely it would simply delay standardization of security. They have already decided to permit standardization of PEM; I don't see why DNS should be any different. It is certainly the case that deployment of both PEM and secure DNS will be delayed by licensing requirements and neither is likely to become ubiquitous (at least until September 19, 2000). RSADSI has made RSAREF available on what some would call generous terms and what some would label a shameless ploy to maximize their profits by getting the IETF and other "freeware" communities to standardize something that they can then force commercial enterprises to pay for. Both descriptions are accurate. There are some terms we should be careful about when it comes to deployment. We should make sure that RSADSI does not claim copyright on the interfaces to RSAREF, so that modules incorporating conditionally compiled calls remain freely distributable. I'm fairly certain they have done so, since any other claim would undermine their distribution strategy. [btw... in response to the first question, BIND should only incorporate calls to RSAREF and not RSAREF itself for many reasons including redistribution policy and export control rules. There is reason for concern about export control rules for even having the calls in place, but I suspect "don't ask; don't tell" is the right policy here]. But these are issues around implementation and deployment and not around the architecture. The only architectural issue is whether we should be trying to secure DNS with public key cryptography at all and if so whether we should limit the design to something that can be implemented with the existing RSAREF interfaces. The current design does not because it does some tricky manipulations for better performance. We expect RSADSI will grant a waiver for use of internal interfaces of RSAREF; if they don't, the design should be rethought. I have not personally participated in any discussions, but I've heard there have been some and initial indications are positive. --Charlie (kaufman@zk3.dec.com)   Received: from sol.tis.com by magellan.TIS.COM id aa23939; 12 Apr 94 14:54 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA22355; Tue, 12 Apr 94 14:53:50 EDT Received: by relay.tis.com; id AA25685; Tue, 12 Apr 94 14:54:40 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma025677; Tue Apr 12 14:54:16 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA16500; Tue, 12 Apr 94 11:40:09 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA05194; Tue, 12 Apr 1994 14:41:40 -0400 Message-Id: <9404121841.AA05194@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 "Mon, 11 Apr 94 15:44:06 PDT." Date: Tue, 12 Apr 94 14:41:40 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Paul, From: Paul A Vixie X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: dns-security@tis.com Organization: Vixie Enterprises References: <9404111108.AA22390@necom830.cc.titech.ac.jp> In-Reply-To: mohta@necom830.cc.titech.ac.jp's message of 11 Apr 1994 07:00:58 -0700 >>>>A "freeware" version of bind may be developed and distributed on the >>>>Internet via anonymous FTP according to the terms of the RSAREF >>>>license. >>Why the "freeware" version is restricted by the license? >> >>As far as I know, non-commercial use of patent is free from licensing. >If a BIND distribution includes only hooks for RSAREF without including >RSAREF itself, then no change needs to be made to the BIND license. If, >however, BIND includes portions of RSAREF, then those portions will still >be covered by the RSA license. Noncommercial users won't be affected by >the RSA license, since the terms of the RSA license that affect non- >commercial users are substantially equal to the existing terms of the >BSD and DEC copyrights that BIND is already subject to. However, none of >BIND's current module copyrights restricts commercial use or redistribution >(other than that the copyrights themselves must not be removed or altered, >and other reasonable, "free" things). I would think that no matter what scheme is used, all the cryptographic stuff would want to be in a separate module with its own notices. There are other implementations of RSA besides RSAREF. In fact, RSA sells BSAFE, a commercial version. >I am still pondering at least two issues: should the IETF or IAB specify a >packet encoding which commercial users _cannot_use_ without paying a license >fee or patent royalty to RSA? Of course the IETF should try to avoid this. But how can that be the only factor? Surely there are also technical considerations, on which basis I believe that RSA is superior, and other standards considerations such as the fact that RSA has already been adopted in other IETF standards and in international standards, and probably other dimensions I have left out. Wouldn't it make a difference if the patent had 18 years or 18 months or 18 days left to run? Doesn't it make a difference that RSA is patented only in the US while some other public key systems are patented world wide? I would think that the job of the IETF/IESG is to try to take all these factors into account. > And: if that happens in spite of my protests, >should BIND even include RSAREF, or just hooks and patches for it so that >someone who wants it can pull it from RSA's ftp server and easily integrate >it? I would think the second alternative would be prefered. There will probably be higher quality or at least alternative implementations of RSA available, especially outside the US where none of this patent stuff applies. >Various politicking is still going on privately, but as far as I know, the >author of the current RSA-based IP/DNS Security proposal has summarily written >off my concerns. I can't speak for Charlie Kaufman, it's just that I'm not willing to go to a lot of extra work so as to avoid a window of a few years during which people in the United States only who fall into the following two categories would probably have to pay a reasonable license fee: they want to (1) sell secure DNS software and don't already have a license or they want to (2) sell a service for which secure DNS is an essential part and don't want to buy secure DNS software (which would come with a license, at least if its from a US vendor). (I realize that to many people no software patent license fee can be "reasonable"...) >-- >Paul Vixie >Redwood City, CA >decwrl!vixie!paul > Donald   Received: from sol.tis.com by magellan.TIS.COM id aa24868; 12 Apr 94 18:23 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA08966; Tue, 12 Apr 94 18:22:58 EDT Received: by relay.tis.com; id AA27979; Tue, 12 Apr 94 18:23:51 EDT Received: from gw.home.vix.com(192.5.5.1) by relay via smap (V1.3mjr) id sma027971; Tue Apr 12 18:22:51 1994 Received: by gw.home.vix.com id AA23689; Tue, 12 Apr 94 15:22:30 -0700 Message-Id: <9404122222.AA23689@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: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of "Tue, 12 Apr 1994 14:41:40 EDT." <9404121841.AA05194@skidrow.lkg.dec.com> Date: Tue, 12 Apr 1994 15:22:30 -0700 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? My answer comes in several parts. First and foremost, the PEM agreements were wrong-headed and politically motivated, in my view. DNS could 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. 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. 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; 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. 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. Paul Vixie Redwood City, CA decwrl!vixie!paul   Received: from sol.tis.com by magellan.TIS.COM id aa24947; 12 Apr 94 18:57 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA09797; Tue, 12 Apr 94 18:57:10 EDT Received: by relay.tis.com; id AA28259; Tue, 12 Apr 94 18:58:04 EDT Message-Id: <9404122258.AA28259@relay.tis.com> Received: from labs-n.bbn.com(128.89.0.100) by relay via smap (V1.3mjr) id sma028254; Tue Apr 12 18:57:16 1994 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 -0700. <9404122222.AA23689@gw.home.vix.com> Date: Tue, 12 Apr 94 18:55:03 -0400 From: Steve Kent 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. When we initially developed PEM, we were quite concerned about the issue of using technology that was patented in the US. The first version of PEM contained only symmetric (DES) crypto key management in large part because of that concern. We convinced ourselves that public key signatures and key management were essential for deployment of large scale email security, and we worked with RSADSI to reach an agreement that we felt would make deployment of the technology viable in the US portion of the Internet. I think most of us involved in that decision have been very pleased with the extent to which RSADSI has made software available, e.g., RSAREF, to facilitate implementation of PEM. However, we selected RSA at a time when we felt there were no viable public key alternatives, irrespective of patent status. Since that time, there has been more work in the area and there are other algorithm choices. None is as attractive as RSA for providing both signature and encryption key managent. However, in a signature only context, there are other candidates and the DNS is a signature only application. To that extent, I agree with your observation that PEM is not a perfect precedent on which to base adoption of RSA for the DNS. 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. 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. 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. It is clear from the spec that Donald and George worked hard 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. In principle, I'd feel more comfortable with an algorithm independent design, but I realse there is a concern about overflowing DNS UDP responses. I'd like to see lots of statictics about current DNS use so that we could say, with confidence, that the design constraints addressed here are the right ones and that this design will, in fact, be successful in this regard. Even without implementation experience, we could predict overflow situations with adequate data on current usage patterns. Steve   Received: from sol.tis.com by magellan.TIS.COM id aa25256; 12 Apr 94 21:00 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13704; Tue, 12 Apr 94 21:00:00 EDT Received: by relay.tis.com; id AA29164; Tue, 12 Apr 94 21:00:53 EDT Received: from sacmgr.mp.usbr.gov(140.214.12.4) by relay via smap (V1.3mjr) id sma029153; Tue Apr 12 20:59:52 1994 Received: by sacto.mp.usbr.gov (MX V3.3 VAX) id 2174; Tue, 12 Apr 1994 17:59:12 PDT Date: Tue, 12 Apr 1994 17:59:00 PDT From: "Henry W. Miller" To: sblair@upurbmw.us.dell.com Cc: dns-security@magellan.TIS.COM, henrym@sacto.mp.usbr.gov Message-Id: <0097CDB6.15533168.2174@sacto.mp.usbr.gov> Subject: Re: SIG RR location in responses..several comments. > From: MX%"sblair@upurbmw.us.dell.com" 12-APR-1994 17:15:21.95 > Subj: Re: SIG RR location in responses..several comments. > Pardon me for melting three messages into one, but after reading a week of this > subject, I feel that three good points, and apologize for my tardiness in > replying. > > > vixie: > ------ > Am I the only person reading all this who is concerned about > using RSA, a patented and licensed technology, for DNS security? > I am very reluctant to put into BIND any technology which would > require vendors to pay a royalty to RSA before they could ship > it with their systems. > > > I for one am still thinking about what the overseas folks will do Paul. > > May I remind all about Austin Code Works and the current legal issue just > surrounding PgP? Vendors are having a hard enough time keeping up with things > as fast as they change. Not all companies have mechinisms in place that can > support the audit trails well enough to be defeneded in court when RSA, etc. > al., decides that they may not be getting their fair share of $$'s from the > licensing issues. There are no clear winners, the vendor, the customers, loose, > and the lawyers win. That is not the direction I'd like to see BIND/dnssec go. > > This is probably an 11th hour suggestion, but I wonder if it might be better to develop an en/decryption technique explictly for use for DNS, and perhaps other Internet services? One that would not suffer from copyright and export restrictions? > galvin: > -------- > > Two bits of information to keep in mind. First, RSADSI has made RSAREF > available for non-commercial use. However, I realize this does not > solve the "vendors packaging a product." For that, may I direct your > attention to the latest issue of Connexions, March 1984, in which > commandment number 1 of "The Ten Commandments of Domain Name Service" > is, "Thou shalt not run thy vendor's DNS software." > > That statement is personally disappointing James. It is a far cry from reality > then if you consider that almost 50%(IMHO) of customers DO RUN the vendor > shipped code. At least until it bites them in the arse. We have to keep in mind > with anything that we consider publishing that customers may/may not have the > smarts to run it, and not everyone has time to port every single "steenking > piece of code" to get the latest-and-greatest widget. > I submit that those who run the stock software (of some vendors) and are connected to the Internet are damned fools? Remember the Internet worm, and how it exploited a WELL KNOWN set of bugs? To their credit, Sun has been pretty good recently about supplying patched versions of some utilities; other vendors have not. If a site cannot provide a systems programmer of sufficient apptitude to keep up with the changes (and the dangers) then they should hire a network consultant who can perform the task in a short time. There is no shortage of such consultants. There's no sense in bitching about the horse escaping if you leave the barn door and gate open! > I feel that Art Harkin was right on the point: > -------------------------------------------------- > > Where I feel the danger lies is how this 'problem' has been intepreted into a > rule that vendor software is to be discarded. This might be a simplistic view, > there are many network admins unwilling to delve into the issues of running > unsupported software. Not recognizing this can cause problems later. I feel a > better approach is to encourage rapid deployment of new features in both > commercial and non-commercial arenas. > I agree with the latter, but until the former becomes true, responsible system managers have to protect their systems. > Crocker: > --------- > As neither a lawyer nor an RSA representative, I can give only my general > understanding, which is (a) I believe patents cover all use, commercial or not, > and (b) I don't think RSA has given blanket permission for non-commercial > implementations other than through RSAREF, but I strongly recommend > you take this up with them. > > > I think we all better have a talk with RSA before this continues < > > much further. Admins who can barely runa site now will be totally < > > screwed if they can't understand what we implement. If the RSA < > > folks are on this list, now is the time to speak up folks. < > > -- > Steven C. Blair > dell computer corp > "Professionals are predictable, it's the amateurs that are dangerous" > -HWM ---------- Henry W. Miller Assistant Systems and Network Manager U.S. Bureau of Reclamation, Mid Pacific Region 2800 Cottage Way MP1130 Sacramento, CA 95825 (916) 978-5108 Inet: "henrym@sacto.mp.usbr.gov" "I've fallen, and I can't get up!"   Received: from sol.tis.com by magellan.TIS.COM id aa27527; 13 Apr 94 9:04 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA28914; Wed, 13 Apr 94 09:03:36 EDT Received: by relay.tis.com; id AA03510; Wed, 13 Apr 94 09:04:29 EDT Received: from unknown(129.185.1.1) by relay via smap (V1.3mjr) id sma003502; Wed Apr 13 09:03:41 1994 Received: from cooper.frmy.bull.fr by mybull.frmy.bull.fr; Wed, 13 Apr 1994 14:58:38 +0200 (MET) Received: by cooper.frmy.bull.fr; Wed, 13 Apr 94 13:00:41 GMT (MET) From: Denis PINKAS Message-Id: <9404131300.AA24744@cooper.frmy.bull.fr> Subject: Re: dnssec draft To: "Donald E. Eastlake 3rd" Date: Wed, 13 Apr 94 15:00:41 EET Cc: dns-security@tis.com In-Reply-To: <9404042121.AA29270@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Apr 4, 94 5:21 pm X-Mailer: ELM [version 2.3 PL2] > > > I'd be the first to admit that the current draft is not particularly > well written. However, I think that even more than improvement and > some reorganization of the technical documentation, there is a drastic > need for an "overview". This would have no bit fields or binary/hex > numbers in it but would try to give a thorough overview of the > proposal. It might incorporate some of the introductory and overview > material in the current draft but substantially augmented and > rewritten. > > What do other people think? Well ! I strongly support this view. Since I have not participated to any meeting, the paper has to be read several times to be understandable. Denis. > > Donald > > PS: I have gone through and replaced the secure hash standard with MD5 > everywhere in the draft as well as fixing many of the typos and am in > the process of de-emphasizing NTP, all as discussed in Seattle. I > plan to post this revised draft in a few days so people with > complaints about typos might want to wait to see if I've caught > them... > > --------------------------------------------------------------------------- > 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) > > -- ============================================================================ Denis Pinkas, Bull S.A E-mail : D.Pinkas@frmy.bull.fr 7, Rue Ampere Phone : (33-1) 69 93 95 75 91343 MASSY Cedex, France Fax : (33-1) 69 93 73 53 ============================================================================   Received: from sol.tis.com by magellan.TIS.COM id aa25653; 13 Apr 94 0:42 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA17215; Wed, 13 Apr 94 00:42:06 EDT Received: by relay.tis.com; id AA00577; Wed, 13 Apr 94 00:43:00 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma000572; Wed Apr 13 00:42:21 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 13 Apr 94 13:34:54 +0859 From: Masataka Ohta Return-Path: Message-Id: <9404130435.AA02338@necom830.cc.titech.ac.jp> Subject: Re: Security AD's assesment re RSAREF licensing To: Steve Kent Date: Wed, 13 Apr 94 13:34:52 JST Cc: paul@vix.com, dns-security@tis.com In-Reply-To: <9404122258.AA28259@relay.tis.com>; from "Steve Kent" at Apr 12, 94 6:55 pm X-Mailer: ELM [version 2.3 PL11] > 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). That's better, I think. > 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. If we choose to support ElGamal to avoid RSA, it is still necessary to make the scheme algorithm dependent. If both algorithms are allowed to be supported by DNS, implementations will most certainly be forced to support RSA. > It is clear from the spec that Donald and George worked hard > to deisgn a scheme that minimizes the extra space taken up by > signatures. True. > That probably motivated the use of RSA, the only one of > the algorithms mentioned above that is "reversable" in terms of > signature data. I've found another reason not to use "reversable" property. If public key is not made public and distributed to limited number of people, it is confidentiality. So, to avoid issues such as US export control, I think we should use "one way" signature. > In principle, I'd feel more comfortable with an > algorithm independent design, but I realse there is a concern about > overflowing DNS UDP responses. As far as I know, the serious issue is on unavoidable fragmentation, not on overflowing responses. I've heard that some broken name servers or some wrong configuration have once caused a lot of backbone DNS traffic. But that's a separate issue. BTW, regardles of whether we use "reversable" property or not, some additional section processing will become impractical which will cause extra queries. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa01544; 13 Apr 94 13:52 EDT Received: from magellan.tis.com by tis.com (4.1/SUN-5.64) id AA18210; Wed, 13 Apr 94 13:51:43 EDT Message-Id: <9404131751.AA18210@tis.com> Reply-To: James M Galvin To: minutes@cnri.reston.va.us Cc: dns-security@tis.com Subject: Minutes of DNS Security March 1994 (Seattle) Meeting Mime-Version: 1.0 Content-Type: multipart/signed; boundary="----- =_aaaaaaaaaa1"; protocol="pem"; hashalg="md5" Date: Wed, 13 Apr 1994 13:51:56 -0400 From: James M Galvin ------- =_aaaaaaaaaa1 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <1516.766259444.2@tis.com> ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1516.766259444.3@tis.com> Enclosed below are the minutes from DNS Security working group. If there are any questions please let me know. Thanks, Jim ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1516.766259444.4@tis.com> Content-Description: DNS Security WG Minutes DNS Security WG Meeting Minutes March 1994 Seattle Recorded by Jim Galvin, Chair The DNS Security Working Group met on Tuesday morning for a 2.5 hour meeting. Donald Eastlake and Charlie Kaufman had previously submitted a proposal (as an internet draft) for enhancing the DNS to support a digital signature security service. This meeting was dedicated to a review of that proposal. The meeting began with a review of the desired requirements identified at the BOF meeting held at the November 1993 Houston meeting. Donald and Charlie then led a presentation and discussion of their proposal. The following issues were discussed and resolved as indicated. o choice of algorithm The proposal currently specifies the SHA and RSA algorithms. It was agreed to replace SHA with MD5, the current Internet preference. o revisit DNS architecture The addition of SIG RRs increases the probability that the maximum UDP payload per packet may be exceeded. The requirement that we remain backward compatible with the existing installed base and the lack of empirical data to support the premise caused us to agree to leave the DNS architecture alone. o where do SIG RRs go in the reply A question was raised as to whether which section of the reply the SIG RRs should be placed. This is an issue because it was noted that, if necessary, implementations may ignore (and truncate) the additional records portion of a reply. It was agreed to query Paul Mockapetris in particular and to followup on the mailing list. o key per zone or key per server The proposal currently specifies that a public/private key pair is assigned to a zone, which is responsible for signing its data. In this way the data may be distributed by any server and, in fact, the actual signing of the data may (and should) occur as an off-line function. In addition, a specification is included for servers to optionally sign responses to queries. At this time it was agreed to leave the optional alternative in the document. We will revisit this issue after we have some implementation experience. o split the document It was suggested that the document may be better organized as several related documents. It was agreed Donald and/or Charlie would initiate a discussion of this issue on the mailing list. o use of the NTP time service The proposal currently emphasizes (if not requires) the use of a reliable time service, in particular NTP. It was agreed that DNS may depend on loosely synchronized clocks, on the order of a few hours. The authors agreed to rework this aspect of the proposal and to not mention any particular way of achieving synchronization. o partial and/or hash records The point was raised that the ability to directly include RRs of a particular type in more than one SIG record was overly complicated in that it caused the need for the "partial RR" signet to be sure you had all the relevant SIGs. The suggestion was that if all the RRs of a particular type did not fit directly into one SIG, the use of a hashed signet be required which would in turn require the RRs to be present in plain text outside the SIG. It was agreed to wait for implementation experience to see if this simplification to the proposal made sense. o key management It was observed that an integral part of the proposal is the specification of a key management protocol. As the new security area director was present at the meeting he was asked if the security area believed it was appropriate to specify another key management protocol, observing that both PEM and SNMP Security have also specified key management protocols. The response was that this key management protocol was sufficiently different from the other two that it was valuable in its own right and should remain part of the proposal. The meeting concluded with Jim Galvin noting that TIS would be implementing the proposal using the bind implementation of the DNS as a baseline. This software would be openly available to the Internet community. This group expects to meet in Toronto. ------- =_aaaaaaaaaa0-- ------- =_aaaaaaaaaa1 Content-Type: application/signature Content-ID: <1516.766259444.1@tis.com> Content-Transfer-Encoding: quoted-printable Version: 5 Originator-ID-Asymmetric: MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UE= ChMbVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA=3D=3D,0= 2 MIC-Info: RSA-MD5,RSA,tprXf8o6YPOZMAL74VKG5b2kfC8MWVYlX8TmAaznlUrJZG/p49tY= aUw37Xa2nVdhFof0mz9N0O8czMws+9kgngd1JxMS7H17T5Ul7MOmsKPp9xTQWFoFR5oUUze1z1= FA ------- =_aaaaaaaaaa1--   Received: from sol.tis.com by magellan.TIS.COM id aa02479; 13 Apr 94 17:29 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA06079; Wed, 13 Apr 94 17:29:27 EDT Received: by relay.tis.com; id AA07749; Wed, 13 Apr 94 17:30:21 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma007739; Wed Apr 13 17:29:44 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA16688; Wed, 13 Apr 94 14:24:42 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA14309; Wed, 13 Apr 1994 17:26:18 -0400 Message-Id: <9404132126.AA14309@skidrow.lkg.dec.com> To: "Henry W. Miller" Cc: dns-security@tis.com Subject: Re: SIG RR location in responses..several comments. In-Reply-To: Your message of "Tue, 12 Apr 94 17:59:00 PDT." <0097CDB6.15533168.2174@sacto.mp.usbr.gov> Date: Wed, 13 Apr 94 17:26:17 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: "Henry W. Miller" To: sblair@upurbmw.us.dell.com Cc: dns-security@magellan.TIS.COM, henrym@sacto.mp.usbr.gov >> From: MX%"sblair@upurbmw.us.dell.com" 12-APR-1994 17:15:21.95 >> Subj: Re: SIG RR location in responses..several comments. >>... >> vixie: >> ------ >> Am I the only person reading all this who is concerned about >> using RSA, a patented and licensed technology, for DNS security? >> I am very reluctant to put into BIND any technology which would >> require vendors to pay a royalty to RSA before they could ship >> it with their systems. >> >> I for one am still thinking about what the overseas folks will do Paul. ? There are plenty of free reasonably high quality implementations of RSA available outside the United States. Just look in ftp.informatik.uni-hamburg.de or ghost.dsi.unimi.it or garbo.uwasa.fi. >> May I remind all about Austin Code Works and the current legal issue just >> surrounding PgP? Vendors are having a hard enough time keeping up with things >> as fast as they change. Not all companies have mechinisms in place that can >> support the audit trails well enough to be defeneded in court when RSA, etc. >> al., decides that they may not be getting their fair share of $$'s from the >> licensing issues. There are no clear winners, the vendor, the customers, loose, >> and the lawyers win. That is not the direction I'd like to see BIND/dnssec go. >> > This is probably an 11th hour suggestion, but I wonder if it >might be better to develop an en/decryption technique explictly for >use for DNS, and perhaps other Internet services? One that would not >suffer from copyright and export restrictions? It's a lot of work to develop good different crypto algorithms, people don't have that much confidence in them until they have undergone years of examination and, while you might avoid copyright restrictions, the export restrictions will be the same if it is equally strong and of the same type. As for patent restrictions, which you don't mention, RSADSI/PKP claims to control, at least until 1997, the idea of public key crypto regardless of the algorithm. Many people dispute this claim but you are not going to get out from under the patent shadow and possibility of law suits by designing a new public key algorithm. >>... >... >-HWM >---------- >Henry W. Miller >Assistant Systems and Network Manager >U.S. Bureau of Reclamation, Mid Pacific Region >2800 Cottage Way MP1130 >Sacramento, CA 95825 (916) 978-5108 >Inet: "henrym@sacto.mp.usbr.gov" > >"I've fallen, and I can't get up!" Donald   Received: from sol.tis.com by magellan.TIS.COM id aa03232; 14 Apr 94 0:19 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA18366; Thu, 14 Apr 94 00:19:39 EDT Received: by relay.tis.com; id AA10290; Thu, 14 Apr 94 00:20:33 EDT Received: from zephyr.isi.edu(128.9.160.160) by relay via smap (V1.3mjr) id sma010284; Thu Apr 14 00:19:37 1994 Received: from aloha.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16) id ; Wed, 13 Apr 1994 21:16:24 -0700 Message-Id: <199404140416.AA02513@zephyr.isi.edu> To: "Donald E. Eastlake 3rd (Beast)" Cc: Paul A Vixie , dns-security@tis.com Reply-To: pvm@isi.edu Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of Tue, 12 Apr 1994 14:41:40 -0400. <9404121841.AA05194@skidrow.lkg.dec.com> Date: Wed, 13 Apr 94 21:14:34 PDT From: Paul Mockapetris I feel a bit responsible for adding some fuel to the fire, and wanted to suggest two principles: RSA deserves something for use of its technology, but consumers get to decide whether the price is fair and vote with their feet. But we can't make an informed decision on terms until we know them. Since I don't plan on going to law school, I'd like a simple statement from RSA. I am perfectly willing to believe that factoring large primes is tough, but crypto interfaces should probably admit to other choices; among other things, its just good modularity. (Yes I know that public and private key systems aren't the same, some systems claim to offer only authentication not...) paul USC/Information Sciences Institute phone: 310-822-1511 x285 4676 Admiralty Way, Marina del Rey, CA fax: 310-823-6714 90292   Received: from sol.tis.com by magellan.TIS.COM id aa03317; 14 Apr 94 1:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA18459; Thu, 14 Apr 94 00:30:41 EDT Received: by relay.tis.com; id AA10349; Thu, 14 Apr 94 00:31:36 EDT Received: from zephyr.isi.edu(128.9.160.160) by relay via smap (V1.3mjr) id sma010344; Thu Apr 14 00:31:03 1994 Received: from aloha.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16) id ; Wed, 13 Apr 1994 21:30:29 -0700 Message-Id: <199404140430.AA02692@zephyr.isi.edu> To: Steve Kent Cc: Paul A Vixie , dns-security@tis.com Reply-To: pvm@isi.edu Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of Tue, 12 Apr 1994 18:55:03 -0400. <9404122258.AA28259@relay.tis.com> Date: Wed, 13 Apr 94 21:28:40 PDT From: Paul Mockapetris DNS packets will get bigger, the only question is how much and how soon. We should plan on altering the present limit rather than squeezing bits. Truncation pressures will happen soon, even without security, because of several new applications coming up. paul USC/Information Sciences Institute phone: 310-822-1511 x285 4676 Admiralty Way, Marina del Rey, CA fax: 310-823-6714 90292   Received: from sol.tis.com by magellan.TIS.COM id aa03322; 14 Apr 94 1:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA19049; Thu, 14 Apr 94 01:12:52 EDT Received: by relay.tis.com; id AA10581; Thu, 14 Apr 94 01:13:47 EDT Received: from gw.home.vix.com(192.5.5.1) by relay via smap (V1.3mjr) id sma010575; Thu Apr 14 01:13:10 1994 Received: by gw.home.vix.com id AA27384; Wed, 13 Apr 94 22:12:35 -0700 Message-Id: <9404140512.AA27384@gw.home.vix.com> X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: pvm@isi.edu Cc: Steve Kent , dns-security@tis.com Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of "Wed, 13 Apr 1994 21:28:40 PDT." <199404140430.AA02692@zephyr.isi.edu> Date: Wed, 13 Apr 1994 22:12:35 -0700 From: Paul A Vixie 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.   Received: from sol.tis.com by magellan.TIS.COM id aa03071; 13 Apr 94 22:35 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA16254; Wed, 13 Apr 94 22:35:06 EDT Received: by relay.tis.com; id AA09655; Wed, 13 Apr 94 22:36:02 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma009650; Wed Apr 13 22:35:54 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 14 Apr 94 11:28:30 +0900 From: Masataka Ohta Return-Path: Message-Id: <9404140228.AA06895@necom830.cc.titech.ac.jp> Subject: Re: DNS security draft To: "Donald E. Eastlake 3rd" Date: Thu, 14 Apr 94 11:28:28 JST Cc: dns-security@tis.com In-Reply-To: <9404111650.AA15440@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Apr 11, 94 12:50 pm X-Mailer: ELM [version 2.3 PL11] > >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. 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. 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 7) B is poited from A 8) C is poited 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? In general, I think resolvers can't be sure that a zone is secure unless it knows key of its ancestor zone in advance. > 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   Received: from sol.tis.com by magellan.TIS.COM id aa06594; 14 Apr 94 10:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA04030; Thu, 14 Apr 94 10:21:49 EDT Received: by relay.tis.com; id AA13694; Thu, 14 Apr 94 10:22:45 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma013689; Thu Apr 14 10:21:52 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA06410; Thu, 14 Apr 94 07:15:12 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA20745; Thu, 14 Apr 1994 10:16:48 -0400 Message-Id: <9404141416.AA20745@skidrow.lkg.dec.com> To: pvm@isi.edu Cc: dns-security@tis.com Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of "Wed, 13 Apr 94 21:28:40 PDT." <199404140430.AA02692@zephyr.isi.edu> Date: Thu, 14 Apr 94 10:16:48 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Yes, we need to eventually aim for a DNS-II with provision for bigger packets and some ideas that will help in that are in the *ixfr* draft you co-authored. I hope to post a message on that topic on namedroppers in not too long. However, I think we need vast improvements in Internet security urgently, DNS security can play a big part in that (particularly for key distribution), and all this will happen a lot sooner if existing DNS servers and DNS servers with only minor modifications can particiapte. The only server changes required for the current DNS security proposal are at the primaries and there all you need is to be able to recognize the new RRs in zone files and have an off line application to sign/secure a zone. This seems pretty easy to me. (You do also need extensive changes to the resolvers/clients that will be using security.) I don't think the current DNS proposal squeezes bits though I would admit to squeezing bytes. A much higher density (though more complex) proposal could be come up with if you were willing to squeeze bits. Donald From: Paul Mockapetris To: Steve Kent Cc: Paul A Vixie , dns-security@tis.com Reply-To: pvm@isi.edu In-Reply-To: Your message of Tue, 12 Apr 1994 18:55:03 -0400. <9404122258.AA28259@relay.tis.com> >DNS packets will get bigger, the only question is how much and how >soon. We should plan on altering the present limit rather than >squeezing bits. Truncation pressures will happen soon, even without >security, because of several new applications coming up. > >paul > >USC/Information Sciences Institute phone: 310-822-1511 x285 >4676 Admiralty Way, Marina del Rey, CA fax: 310-823-6714 >90292   Received: from sol.tis.com by magellan.TIS.COM id aa07122; 14 Apr 94 11:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA04059; Thu, 14 Apr 94 10:22:50 EDT Received: by relay.tis.com; id AA13706; Thu, 14 Apr 94 10:23:46 EDT Received: from ns.gte.com(132.197.8.9) by relay via smap (V1.3mjr) id sma013697; Thu Apr 14 10:23:15 1994 Received: from bunny.gte.com by ns.gte.com (5.65c/IDA-1.4.4) id AA06853; Thu, 14 Apr 1994 10:21:48 -0400 Received: from pkarger by bunny.gte.com (5.61/GTEL2.19) id AA06737; Thu, 14 Apr 94 10:17:21 -0400 Received: from localhost by pkarger.tcc (4.1/SMI-4.1) id AA02924; Thu, 14 Apr 94 10:21:06 EDT Message-Id: <9404141421.AA02924@pkarger.tcc> 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 Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of "Wed, 13 Apr 94 13:34:52 +0200." <9404130435.AA02338@necom830.cc.titech.ac.jp> Date: Thu, 14 Apr 94 10:21:05 -0400 From: "Paul A. Karger" 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 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   Received: from sol.tis.com by magellan.TIS.COM id aa07486; 14 Apr 94 12:51 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA15148; Thu, 14 Apr 94 12:51:01 EDT Received: by relay.tis.com; id AA15185; Thu, 14 Apr 94 12:51:57 EDT Received: from mitsou.inria.fr(138.96.24.84) by relay via smap (V1.3mjr) id sma015173; Thu Apr 14 12:50:57 1994 Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA29770; Thu, 14 Apr 1994 18:51:57 +0200 Message-Id: <199404141651.AA29770@mitsou.inria.fr> To: Masataka Ohta Cc: Paul A Vixie , pvm@isi.edu, kent@bbn.com, dns-security@tis.com Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of "Fri, 15 Apr 1994 00:40:05 +0200." <9404141540.AA10587@necom830.cc.titech.ac.jp> Date: Thu, 14 Apr 1994 18:51:56 +0200 From: Christian Huitema => > 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 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. You could only do that if you replaced UDP by a "transaction" variant of TCP. Christian Huitema   Received: from sol.tis.com by magellan.TIS.COM id aa08173; 14 Apr 94 14:22 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA17988; Thu, 14 Apr 94 13:24:27 EDT Received: by relay.tis.com; id AA15559; Thu, 14 Apr 94 13:25:22 EDT Received: from gw.home.vix.com(192.5.5.1) by relay via smap (V1.3mjr) id sma015554; Thu Apr 14 13:24:57 1994 Received: by gw.home.vix.com id AA10646; Thu, 14 Apr 94 10:24:33 -0700 Message-Id: <9404141724.AA10646@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: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of "Fri, 15 Apr 1994 00:40:05 +0200." <9404141540.AA10587@necom830.cc.titech.ac.jp> Date: Thu, 14 Apr 1994 10:24:32 -0700 From: Paul A Vixie > I think we should start making name servers and resolvers can accept > (but not send) 64K byte UDP packets, immediately. > > Masataka Ohta i don't think so, for two reasons: (1) larger queries and responses cannot be generated without a protocol revision, which will almost certainly involve other changes than just maximum datagram size; (2) for a stub resolver, the maximum size of a response translates to stack space for the receive buffer -- and 64K is too large to ask every stub resolver client to have to grow. i was thinking that 1500 bytes would be reasonable, but before i put that into BIND i'll need at least an FYI blessed by pvm that gives the conditions under which a TC can be inferred when the sender puts more than 512 bytes into a dns datagram and the receiver isn't prepared to catch that many; also, i'll need some conceptual convergence from the wider DNS WG (not just this security group) on whether/when/why a sender would consider 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. 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.   Received: from sol.tis.com by magellan.TIS.COM id aa08090; 14 Apr 94 14:03 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA20937; Thu, 14 Apr 94 14:02:45 EDT Received: by relay.tis.com; id AA15948; Thu, 14 Apr 94 14:03:40 EDT Received: from zephyr.isi.edu(128.9.160.160) by relay via smap (V1.3mjr) id sma015942; Thu Apr 14 14:02:45 1994 Received: from aloha.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16) id ; Thu, 14 Apr 1994 10:59:16 -0700 Message-Id: <199404141759.AA13180@zephyr.isi.edu> To: "Donald E. Eastlake 3rd (Beast)" Cc: dns-security@tis.com Reply-To: pvm@isi.edu Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of Thu, 14 Apr 1994 10:16:48 -0400. <9404141416.AA20745@skidrow.lkg.dec.com> Date: Thu, 14 Apr 94 10:57:27 PDT From: Paul Mockapetris > Yes, we need to eventually aim for a DNS-II with provision for bigger > packets and some ideas that will help in that are in the *ixfr* draft > you co-authored. I hope to post a message on that topic on > namedroppers in not too long. I'm unaware of any draft I co-authored. > However, I think we need vast improvements in Internet security > urgently, DNS security can play a big part in that (particularly for > key distribution), and all this will happen a lot sooner if existing > DNS servers and DNS servers with only minor modifications can > particiapte. > > The only server changes required for the current DNS security proposal > are at the primaries and there all you need is to be able to recognize > the new RRs in zone files and have an off line application to > sign/secure a zone. This seems pretty easy to me. (You do also need > extensive changes to the resolvers/clients that will be using > security.) > > I don't think the current DNS proposal squeezes bits though I would > admit to squeezing bytes. A much higher density (though more complex) > proposal could be come up with if you were willing to squeeze bits. I was trying to relax constraints, not impose them. Your design should not be constrained to fit all responses in 512ish packets. paul   Received: from sol.tis.com by magellan.TIS.COM id aa08636; 14 Apr 94 15:24 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA26968; Thu, 14 Apr 94 15:24:28 EDT Received: by relay.tis.com; id AA16895; Thu, 14 Apr 94 15:25:24 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma016890; Thu Apr 14 15:24:43 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA26746; Thu, 14 Apr 94 12:16:58 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA23847; Thu, 14 Apr 1994 15:18:34 -0400 Message-Id: <9404141918.AA23847@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 "Thu, 14 Apr 94 10:24:32 PDT." <9404141724.AA10646@gw.home.vix.com> Date: Thu, 14 Apr 94 15:18:34 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Paul, From: Paul A Vixie To: dns-security@tis.com In-Reply-To: Your message of "Fri, 15 Apr 1994 00:40:05 +0200." <9404141540.AA10587@necom830.cc.titech.ac.jp> >> I think we should start making name servers and resolvers can accept >> (but not send) 64K byte UDP packets, immediately. >> >> Masataka Ohta > >i don't think so, for two reasons: > >(1) larger queries and responses cannot be generated without a protocol > revision, which will almost certainly involve other changes than just > maximum datagram size; > >(2) for a stub resolver, the maximum size of a response translates to > stack space for the receive buffer -- and 64K is too large to ask every > stub resolver client to have to grow. > >i was thinking that 1500 bytes would be reasonable, but before i put that >into BIND i'll need at least an FYI blessed by pvm that gives the >conditions under which a TC can be inferred when the sender puts more than >512 bytes into a dns datagram and the receiver isn't prepared to catch that >many; also, i'll need some conceptual convergence from the wider DNS WG >(not just this security group) on whether/when/why a sender would consider >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. 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. 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. 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? Donald   Received: from sol.tis.com by magellan.TIS.COM id aa08666; 14 Apr 94 15:29 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA27289; Thu, 14 Apr 94 15:29:31 EDT Received: by relay.tis.com; id AA16939; Thu, 14 Apr 94 15:30:27 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma016929; Thu Apr 14 15:30:08 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA27065; Thu, 14 Apr 94 12:22:03 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA23911; Thu, 14 Apr 1994 15:23:38 -0400 Message-Id: <9404141923.AA23911@skidrow.lkg.dec.com> To: pvm@isi.edu 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:57:27 PDT." <199404141759.AA13180@zephyr.isi.edu> Date: Thu, 14 Apr 94 15:23:38 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: Paul Mockapetris To: "Donald E. Eastlake 3rd (Beast)" Cc: dns-security@tis.com Reply-To: pvm@isi.edu In-Reply-To: Your message of Thu, 14 Apr 1994 10:16:48 -0400. <9404141416.AA20745@skidrow.lkg.dec.com> >> Yes, we need to eventually aim for a DNS-II with provision for bigger >> packets and some ideas that will help in that are in the *ixfr* draft >> you co-authored. I hope to post a message on that topic on >> namedroppers in not too long. > >I'm unaware of any draft I co-authored. My confusion I guess. You were among the short explicit list of people to whom I was told I should send comments on draft*ixfr*. >> However, I think we need vast improvements in Internet security >> urgently, DNS security can play a big part in that (particularly for >> key distribution), and all this will happen a lot sooner if existing >> DNS servers and DNS servers with only minor modifications can >> particiapte. >> >> The only server changes required for the current DNS security proposal >> are at the primaries and there all you need is to be able to recognize >> the new RRs in zone files and have an off line application to >> sign/secure a zone. This seems pretty easy to me. (You do also need >> extensive changes to the resolvers/clients that will be using >> security.) >> >> I don't think the current DNS proposal squeezes bits though I would >> admit to squeezing bytes. A much higher density (though more complex) >> proposal could be come up with if you were willing to squeeze bits. > >I was trying to relax constraints, not impose them. Your design >should not be constrained to fit all responses in 512ish packets. There are ceratinly cases where the response to a query won't fit into 512 bytes no matter what you do. However, any dns security proposal can be deployed more rapidly if most responses will fit into the current 512 bytes and if, as with our proposal, most DNS servers need not change at all for initial use. >paul Donald   Received: from sol.tis.com by magellan.TIS.COM id aa09479; 14 Apr 94 17:30 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA06946; Thu, 14 Apr 94 17:29:44 EDT Received: by relay.tis.com; id AA18435; Thu, 14 Apr 94 17:30:40 EDT Received: from gw.home.vix.com(192.5.5.1) by relay via smap (V1.3mjr) id sma018428; Thu Apr 14 17:30:18 1994 Received: by gw.home.vix.com id AA15573; Thu, 14 Apr 94 14:27:07 -0700 Message-Id: <9404142127.AA15573@gw.home.vix.com> X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us 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 1994 15:18:34 EDT." <9404141918.AA23847@skidrow.lkg.dec.com> Date: Thu, 14 Apr 1994 14:27:06 -0700 From: Paul A Vixie > 1250 bytes sounds reasonable. but like i said, this isn't a dns-security issue and i won't make a change of this nature in BIND without seeing at least an FYI published and knowing that PVM and the DNS WG have blessed it. > 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? yes. however, this will only hurt cases where the client sets them for its own nefarious purposes. the BIND resolver always clears the unused bits. if other resolvers (are there any?) do the same, we can safely allocate unused bits without hurting (or being hurt by) old software. bind's reuse of the query header for sending the response is something i'll probably try to change in 4.9.3's alpha test cycle, to see whether it causes widespread breakage. that's how it inherits all the query flags in the response. changing it will lead to great trepidation, since many reasonable changes to BIND have resulted in vastly unreasonable reactions from other/older software.   Received: from sol.tis.com by magellan.TIS.COM id aa09577; 14 Apr 94 18:10 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA09242; Thu, 14 Apr 94 18:10:05 EDT Received: by relay.tis.com; id AA18779; Thu, 14 Apr 94 18:11:01 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma018773; Thu Apr 14 18:10:59 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA06335; Thu, 14 Apr 94 15:06:02 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA25997; Thu, 14 Apr 1994 18:07:38 -0400 Message-Id: <9404142207.AA25997@skidrow.lkg.dec.com> To: Paul A Vixie Cc: dee@skidrow.lkg.dec.com, dns-security@tis.com Subject: Re: Security AD's assesment re RSAREF licensing In-Reply-To: Your message of "Thu, 14 Apr 94 14:27:06 PDT." <9404142127.AA15573@gw.home.vix.com> Date: Thu, 14 Apr 94 18:07:38 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: Paul A Vixie X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: "Donald E. Eastlake 3rd (Beast)" Cc: dns-security@tis.com In-Reply-To: Your message of "Thu, 14 Apr 1994 15:18:34 EDT." <9404141918.AA23847@skidrow.lkg.dec.com> >> 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? > >yes. however, this will only hurt cases where the client sets them for >its own nefarious purposes. the BIND resolver always clears the unused >bits. if other resolvers (are there any?) do the same, we can safely >allocate unused bits without hurting (or being hurt by) old software. ? I was talking about a server getting a query and leaving bits that were set in the query it received set in *queries* that it sends. This seems like broken behavior which could lead to lots of problems and which you indicates that BIND does *not* do. For example, under the present dns sec proposal, if a security aware client set the Security Desired bit and sent off a query to a non-security aware server, one would hope this would have no effect except that possibly the SD bit would be on in the response. If this non-security aware server forwarded the SD bit on a recursive query to a security aware server, then that security aware server might, under the current proposal, surpress some RRs in responses because they are embodies in SIG RRs. This would confuse the intermediate non-security aware server which would not know how to unpack this stuff from the SIG. As a result, the original client might easily get a wrong failure indication for, say, an A RR it was looking for. >bind's reuse of the query header for sending the response is something >i'll probably try to change in 4.9.3's alpha test cycle, to see whether >it causes widespread breakage. that's how it inherits all the query >flags in the response. changing it will lead to great trepidation, >since many reasonable changes to BIND have resulted in vastly unreasonable >reactions from other/older software. I don't see much problem with leaving unknown bits that are on in a query on the the *response* sent to that query. That was what I assumed DNS servers would do. Why change this behaviour? Donald