Received: from sol.tis.com by magellan.TIS.COM id aa00437; 2 Aug 94 11:33 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3) id sma005575; Tue Aug 2 11:33:35 1994 Received: from antares.tis.com by tis.com (4.1/SUN-5.64) id AA17925; Tue, 2 Aug 94 11:32:49 EDT Message-Id: <9408021532.AA17925@tis.com> Reply-To: James M Galvin To: dns-security@tis.com Subject: draft DNS Security WG minutes Mime-Version: 1.0 Content-Type: multipart/signed; protocol="pem"; hashalg="md5"; boundary="----- =_aaaaaaaaaa1" Date: Tue, 02 Aug 1994 11:32:50 -0400 From: James M Galvin ------- =_aaaaaaaaaa1 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <457.775841548.2@tis.com> ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <457.775841548.3@tis.com> These minutes will be submitted to the Secretariat by close of business on wednesday, August 3, EDT. Please review and comment as quickly as possible. Thanks, Jim ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <457.775841548.4@tis.com> Content-Description: DNS Security WG Minutes DNS Security WG Meeting Minutes July 1994 Toronto Recorded by Jim Galvin, Chair The DNS Security Working Group met on Wednesday morning for a 2.5 hours meeting. Masataka Ohta had previously submitted an alternative to the Donald Eastlake and Charlie Kaufman proposal. The majority of this meeting was dedicated to discussing the differences between the two proposals. The meeting began with Jim Galvin presenting a very brief summary of his implementation experience with the Eastlake/Kaufman proposal. No cryptography was implemented; in the interests of simplicity and expediency, values were exclusive-ored instead. Also, only the direct resource records were prototyped. Two results were reported: it is possible to implement the proposal and the proposal includes more options than are needed. Jim observed that one of the principal motivations for many of the options in the Eastlake/Kaufman proposal was the perception that the 512 byte limit for DNS messages was too small. However, he asserted that this limit was in fact not an issue, for two reasons that would be explained later. As a result, he had a proposal for how to proceed but preferred to yield the floor to the Kaufman and Ohta for a discussion of their lists of issues. The remainder of the meeting was dedicated to Kaufman and Ohta each presenting a list of questions and comments about each others' proposals. There was a great deal of vigorous and animated discussion about the issues. Careful time management allowed a complete presentation of all the issues, with some discussion for each, although no conclusions were reached. Since both Ohta and Kaufman agreed to distribute their lists to the electronic mailing lists for continued discussion and resolution, the details are not presented here. The meeting closed with Jim proposing that Eastlake/Kaufman reduce their proposal to including only the hashed resource record, for two reasons. First, there is the assertion that the 512 byte limit would be sufficient about 80-90% of the time. However, even without this assertion, Version 2 of DNS will shortly be proposed that will increase the message size limit to 1500 bytes, which is sufficient to support security as currently proposed. TIS will implement the proposed DNS security enhancements with this new version of DNS. Jim will followup with Eastlake and Kaufman about reducing their proposal, identified as Eastlake/Kaufman-lite. The Chair agreed to propose criteria that could be used to evaluate the two proposals --- Eastlake/Kaufman-lite and Ohta --- to aid the working group in selecting one to submit to the standards track. Consensus and a single proposal will be obtained on the mailing list prior to the next IETF; this group expects to meet in San Jose. ------- =_aaaaaaaaaa0-- ------- =_aaaaaaaaaa1 Content-Type: application/signature Content-ID: <457.775841548.1@tis.com> Content-Transfer-Encoding: quoted-printable Version: 5 Originator-ID: IS,MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1= c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA=3D=3D,02 MIC-Info: RSA-MD5,RSA,sS+KRT4WqB8xxC0q+KS4GIy6ROLXtb5i6C8OQZCN3Gn4jCp7uZta= YR3lzgivJlSt1dPHcrXEC7bn1raibwV+FoV5ogz/NOyZjGHhv2WW7y5/y/JFRDYydxo+qmlm2a= 8W ------- =_aaaaaaaaaa1--   Received: from sol.tis.com by magellan.TIS.COM id aa00660; 2 Aug 94 12:04 EDT Received: from brazos.is.rice.edu(128.42.42.2) by relay via smap (V1.3) id sma006141; Tue Aug 2 12:04:48 1994 Received: by brazos.is.rice.edu (AA06842); Tue, 2 Aug 94 11:04:31 CDT From: William Manning Message-Id: <9408021604.AA06842@brazos.is.rice.edu> Subject: Re: draft DNS Security WG minutes To: galvin@tis.com Date: Tue, 2 Aug 1994 11:04:30 -0500 (CDT) Cc: dns-security@tis.com In-Reply-To: <9408021532.AA17925@tis.com> from "James M Galvin" at Aug 2, 94 11:32:50 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 495 sufficient about 80-90% of the time. However, even without this assertion, Version 2 of DNS will shortly be proposed that will increase the message size limit to 1500 bytes, which is sufficient to support A followin DNS mtg touched briefly on this topic. I understand the implementation will actually have some slop in determining message size. If this actuall works out this way, I would not state a catagorical 1500 byte size. (I am ready for a new keyboard!) -- Regards, Bill Manning   Received: from sol.tis.com by magellan.TIS.COM id aa00821; 2 Aug 94 12:49 EDT Received: from rip.psg.com(147.28.0.39) by relay via smap (V1.3) id sma006805; Tue Aug 2 12:50:03 1994 Received: by rip.psg.com (Smail3.1.28.1 #7) id m0qVN2C-000308C; Tue, 2 Aug 94 09:49 PDT Message-Id: Date: Tue, 2 Aug 94 09:49 PDT From: Randy Bush To: James M Galvin Cc: dns-security@tis.com Subject: draft DNS Security WG minutes References: <9408021532.AA17925@tis.com> > First, there is the assertion that the 512 byte limit would be sufficient > about 80-90% of the time. I never did understand how an 10-20% failure rate was ok, but that's likely my problem. > However, even without this assertion, Version 2 of DNS will shortly be > proposed that will increase the message size limit to 1500 bytes, which is > sufficient to support security as currently proposed. From the DNSIND draft minutes of Tuesday the 26th: o If MTU discovery had been done, we would use that. So we can't The current plan is to let the client specify the max packet and let the server decide use as much as it can. What to do when not enough room? Round robin punt? Input from and coordination between DNSSEC and DNSIND on this might be interesting. randy   Received: from sol.tis.com by magellan.TIS.COM id aa00853; 2 Aug 94 12:57 EDT Received: from gw.home.vix.com(192.5.5.1) by relay via smap (V1.3) id sma006932; Tue Aug 2 12:57:27 1994 Received: by gw.home.vix.com id AA08311; Tue, 2 Aug 94 09:57:12 -0700 Date: Tue, 2 Aug 94 09:57:12 -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: draft DNS Security WG minutes Organization: Vixie Enterprises Message-Id: References: <9408021532.AA17925@tis.com> Nntp-Posting-Host: office.home.vix.com In-Reply-To: galvin@tis.com's message of 2 Aug 1994 09:13:53 -0700 As long as we're on the subject, I'd like to repeat in public a discussion Jim and I had with respect to DNS V2 and security. Jim's right -- V2 will permit larger responses. 1500 is just an example; it'll be up to each resolver to choose its receive buffer size and there will be a field in the request packet that tells the server how large that buffer is. 1500 will just be the value the server will maximize against unless it has a Discovered Path MTU that's larger. 1500 is also going to be the minimum recommended value, though 512 will remain the minimum legal value. So what Jim said in the minutes is all true, but the truth as always is more complex. But there's more. I've been on record as being against the use of our last two flag bits as SA and SD. Jim and I worked out an interesting scheme whereby neither bit is needed, which is too bad since V2 will have more flag bits and will define unused ones to MBZ (rather than UDF). I'm sure we'll need those flag bits eventually, but for now I proposed to Jim that he use multiple queries (QCOUNT==2) to ask simultaneously for an RRset and the SIG RRset for that (class,type,name). This begs the question as to how we'll specify the (type) portion of the SIG tuple -- we may have to get 'em all, or we may have to legislate that if the second query is for SIG, it is for the RR type of the first query. (Actually I'd hate that -- better to return 'em all.) For V1 prototyping, Jim (or any prototype implementor) could just use two separate queries. Using separate queries makes us pretty sure that the responses will each fit in V1's 512 byte limit, too. (For context -- I suggested to Jim that the RRdata field of any SIG should include the (type) portion of the signed (name,class,type) tuple.) That takes care of the size problem (TCP fallback on TC will still work when I'm wrong, which will hopefully not be a large percentage of the time) and the need for SD and SA bits. If we can then also take care of my concerns about RSA's patent, I'll have no further objections to the minimal-EK proposal being honed by Jim Galvin. I think the fundamental ideas are sound and I'm anxious to see it done. -- Paul Vixie Redwood City, CA decwrl!vixie!paul   Received: from sol.tis.com by magellan.TIS.COM id aa01050; 2 Aug 94 13:43 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3) id sma007918; Tue Aug 2 13:43:56 1994 Received: from antares.tis.com by tis.com (4.1/SUN-5.64) id AA10135; Tue, 2 Aug 94 13:43:10 EDT Message-Id: <9408021743.AA10135@tis.com> Reply-To: James M Galvin To: William Manning Cc: dns-security@tis.com Subject: Re: draft DNS Security WG minutes In-Reply-To: 's message of Tue, 02 Aug 1994 11:04:30 CDT. <9408021604.AA06842@brazos.is.rice.edu> Date: Tue, 02 Aug 1994 13:43:10 -0400 From: James M Galvin sufficient about 80-90% of the time. However, even without this assertion, Version 2 of DNS will shortly be proposed that will increase the message size limit to 1500 bytes, which is sufficient to support I've changed the wording as follows: However, even without this assertion, Version 2 of DNS will shortly be proposed that will increase the message size limit. Jim   Received: from sol.tis.com by magellan.TIS.COM id aa01130; 2 Aug 94 13:58 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3) id sma008224; Tue Aug 2 13:58:45 1994 Received: from antares.tis.com by tis.com (4.1/SUN-5.64) id AA14192; Tue, 2 Aug 94 13:57:58 EDT Message-Id: <9408021757.AA14192@tis.com> Reply-To: James M Galvin To: Randy Bush Cc: dns-security@tis.com Subject: Re: draft DNS Security WG minutes In-Reply-To: Randy Bush's message of Tue, 02 Aug 1994 09:49:00 PDT. Date: Tue, 02 Aug 1994 13:57:59 -0400 From: James M Galvin > First, there is the assertion that the 512 byte limit would be > sufficient about 80-90% of the time. I never did understand how an 10-20% failure rate was ok, but that's likely my problem. Not really. I frankly don't believe the failure rate is all that high. I believe my estimate to be conservative on the measure of success. The short form of the analysis is as follows: If a 1024 bit key is used, then 128 bytes are needed for the signature (plus a few bytes for "encoding"). Assume that dns names are 30 bytes on average. This number is derived from averaging the size of email addresses on the 6 email lists I maintain. (Note, I said address, not just the host part.) If the query is for IP addresses, how likely is it that the (type, class, name) in the question and 3 IP addresses in the answer are going to exceed 384 octets. if the query is for MX records, how likely is it that the (type, class, name) in the question and 3 MX names in the answer are going to exceed 384 octets. Jim   Received: from sol.tis.com by magellan.TIS.COM id aa01255; 2 Aug 94 14:19 EDT Received: from rip.psg.com(147.28.0.39) by relay via smap (V1.3) id sma008768; Tue Aug 2 14:20:29 1994 Received: by rip.psg.com (Smail3.1.28.1 #7) id m0qVORi-000308C; Tue, 2 Aug 94 11:20 PDT Message-Id: Date: Tue, 2 Aug 94 11:20 PDT From: Randy Bush To: James M Galvin Cc: dns-security@tis.com Subject: Re: draft DNS Security WG minutes References: <9408021757.AA14192@tis.com> > I never did understand how an 10-20% failure rate was ok, but > that's likely my problem. > > Not really. I frankly don't believe the failure rate is all that high. > I believe my estimate to be conservative on the measure of success. I think I understand the analysis. What I do not understand is how we can find failures acceptable, whether they are 20% or 2%. So I am assuming that there is something I do not understand in the basic operational requirements which makes this ok. Not to worry. I am sure I will sort it out as I keep lurking. randy   Received: from sol.tis.com by magellan.TIS.COM id aa01327; 2 Aug 94 14:29 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3) id sma009094; Tue Aug 2 14:30:04 1994 Received: from antares.tis.com by tis.com (4.1/SUN-5.64) id AA25016; Tue, 2 Aug 94 14:29:17 EDT Message-Id: <9408021829.AA25016@tis.com> Reply-To: James M Galvin To: Randy Bush Cc: dns-security@tis.com Subject: Re: draft DNS Security WG minutes In-Reply-To: 's message of Tue, 02 Aug 1994 11:20:00 PDT. Date: Tue, 02 Aug 1994 14:29:20 -0400 From: James M Galvin > I never did understand how an 10-20% failure rate was ok, but > that's likely my problem. > > Not really. I frankly don't believe the failure rate is all > that high. I believe my estimate to be conservative on the > measure of success. I think I understand the analysis. What I do not understand is how we can find failures acceptable, whether they are 20% or 2%. So I am assuming that there is something I do not understand in the basic operational requirements which makes this ok. Not to worry. I am sure I will sort it out as I keep lurking. What should happen is the server returns a response that is marked as truncated. A "smart" client will then re-query but use TCP instead of UDP. By failure, what I mean is the fallback onto TCP, thus increasing the overhead and time to get a response. Failure is not meant to imply that no response is available, except when servers and clients are not "well-behaved". Jim   Received: from sol.tis.com by magellan.TIS.COM id aa01508; 2 Aug 94 14:49 EDT Received: from hp.com(15.255.152.4) by relay via smap (V1.3) id sma009615; Tue Aug 2 14:49:32 1994 Received: from hpindbg.cup.hp.com by hp.com with SMTP (1.36.108.7/15.5+IOS 3.13) id AA07598; Tue, 2 Aug 1994 11:49:15 -0700 Received: by hpindsh.cup.hp.com (1.37.109.11.2/15.5+IOS 3.20+cup+OMrelay) id AA224613360; Tue, 2 Aug 1994 11:49:20 -0700 From: Art Harkin Message-Id: <9408021149.ZM22459@hpindbg.cup.hp.com> Date: Tue, 2 Aug 1994 11:49:19 -0700 In-Reply-To: Randy Bush "Re: draft DNS Security WG minutes" (Aug 2, 11:20am) References: <9408021757.AA14192@tis.com> X-Mailer: Z-Mail (2.1.5 20sep93) To: Randy Bush Subject: Re: draft DNS Security WG minutes Cc: dns-security@tis.com On Aug 2, 11:20am, Randy Bush wrote: > I think I understand the analysis. What I do not understand is how we can > find failures acceptable, whether they are 20% or 2%. So I am assuming that > there is something I do not understand in the basic operational requirements > which makes this ok. Not to worry. I am sure I will sort it out as I keep > lurking. > > randy >-- End of excerpt from Randy Bush I think the success rate is 100% when TCP fallback is considered, but less for first time success when UDP is used. I think the concern is to to minimize the need to fallback to TCP... is this correct? -art -- ------------------------------------------------------------------------------ A r t H a r k i n Hewlett-Packard Company Information Networks Division E-Mail: ash@cup.hp.com 19420 Homestead Road MS 43LN, Phone: (408) 447-3755 Cupertino, CA 95014 USA ------------------------------------------------------------------------------   Received: from sol.tis.com by magellan.TIS.COM id aa01778; 2 Aug 94 15:11 EDT Message-Id: <9408021912.AA10180@relay.tis.com> Received: from labs-n.bbn.com(128.89.0.100) by relay via smap (V1.3) id sma010175; Tue Aug 2 15:12:16 1994 To: James M Galvin Cc: dns-security@tis.com Subject: Re: draft DNS Security WG minutes In-Reply-To: Your message of Tue, 02 Aug 94 13:57:59 -0400. <9408021757.AA14192@tis.com> Date: Tue, 02 Aug 94 15:11:58 -0400 From: Steve Kent Jim, I think your analysis on size of returned records is good, but I still would feel better if we had histogram data from DNS servers showing the numer of responses of each length. We need to collect this data from servers at various tiers in the hierarchy, i.e., at the root, at top level domains like COM and EDU and some non-US domains (Germany is an obvious candidate given the long names in that language), and from several organizational tier domains (e.g., good size companies, government organizations, and universities). That data would provide the best support for this discussion, if it isn't made moot by DNS v2. On a separate topic, let me suggest that we still ought to be looking at a truly algorithm independent spec. Making specific provisions for packing bits in the case of RSA use may very well lead to ONLY RSA-compatible code in servers and clients, if there is a belief that RSA will be the signature algorithm of choice. If the protocl didn't allow one to try to economize on space, the resulting protocol and software could be much easier to switch over to different signature algorithms. I think a hybrid scheme, with Ohta's simplier structure for signing records and storing keys, but with the E-K approach to forward, reverse and cross-certificates (with carefully specified rules on allowed certification paths to avoid the problems Ohta and other were concerend about), would be a clean design that avoids algorithm dependence, is easier to explain to people, and has fewer opportunities for errors due to inclusion of lots of special cases for representations, etc. Steve   Received: from sol.tis.com by magellan.TIS.COM id aa01910; 2 Aug 94 15:39 EDT Received: from rodan.uu.net(153.39.128.10) by relay via smap (V1.3) id sma010747; Tue Aug 2 15:39:33 1994 Received: by rodan.UU.NET id QQxbgg20654; Tue, 2 Aug 1994 15:34:17 -0400 Message-Id: To: Art Harkin Cc: Randy Bush , dns-security@tis.com From: "Louis A. Mamakos" Subject: Re: draft DNS Security WG minutes In-Reply-To: Your message of "Tue, 02 Aug 1994 11:49:19 PDT." <9408021149.ZM22459@hpindbg.cup.hp.com> Date: Tue, 02 Aug 1994 15:34:16 -0400 Sender: louie@uunet.uu.net > I think the success rate is 100% when TCP fallback is considered, but > less for first time success when UDP is used. I think the concern is to > to minimize the need to fallback to TCP... is this correct? Clever resolvers can notice that the truncation occured *after* the answer section (such as in the additional records section) and choose to not retry the query using TCP. This can further reduce the effective "failure" rate. Louis A. Mamakos louie@alter.net UUNET Technologies, Inc. uunet!louie 3110 Fairview Park Drive., Suite 570 Voice: +1 703 204 8023 Falls Church, Va 22042 Fax: +1 703 204 8001   Received: from sol.tis.com by magellan.TIS.COM id aa02320; 2 Aug 94 16:20 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3) id sma011471; Tue Aug 2 16:20:23 1994 Received: from antares.tis.com by tis.com (4.1/SUN-5.64) id AA23869; Tue, 2 Aug 94 16:19:37 EDT Message-Id: <9408022019.AA23869@tis.com> Reply-To: James M Galvin To: Steve Kent Cc: dns-security@tis.com Subject: Re: draft DNS Security WG minutes In-Reply-To: Steve Kent's message of Tue, 02 Aug 1994 15:11:58 EDT. <9408021912.AA10180@relay.tis.com> Date: Tue, 02 Aug 1994 16:19:39 -0400 From: James M Galvin On a separate topic, let me suggest that we still ought to be looking at a truly algorithm independent spec. Although I have not had a chance to review it carefully, the draft distributed to this mailing list last week is algorithm independent. This point is somewhat obscure in some places but that is fixable. If the protocl didn't allow one to try to economize on space, the resulting protocol and software could be much easier to switch over to different signature algorithms. The E-K-lite proposal does not include the space economizing options. This is not obvious since the "lite" proposal has not actually put forth in "print" but it should be forthcoming soon. I agree, in principle, with everything else you said. Jim   Received: from sol.tis.com by magellan.TIS.COM id aa02373; 2 Aug 94 16:29 EDT Received: from zephyr.isi.edu(128.9.160.160) by relay via smap (V1.3) id sma011643; Tue Aug 2 16:29:29 1994 Received: from aloha.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16) id ; Tue, 2 Aug 1994 13:28:52 -0700 Message-Id: <199408022028.AA05306@zephyr.isi.edu> To: Steve Kent Cc: James M Galvin , dns-security@tis.com Reply-To: pvm@isi.edu Subject: Re: draft DNS Security WG minutes In-Reply-To: Your message of Tue, 02 Aug 1994 15:11:58 -0400. <9408021912.AA10180@relay.tis.com> Date: Tue, 02 Aug 94 13:25:05 PDT From: Paul Mockapetris Two suggestions: The DNS group should seek the wisdom of the IPng types with regard to larger MTUs, and is probably pretty safe bumping existing IP size up to ethernet. We should probably not invent a MTU mechanism that is DNS specific other than to say "if your MTU is less then X, use TCP". Measurements of the current servers are interesting, but IPng will chage the stats pretty violently, and in the more balzanized world which may be coming with the demise of the NSFnet, we may need more redundancy, rather than less. So holding the line probably isn't an option regrardless. Even if as Charlie sez, "we went to great lengths to keep packets short". 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 aa02655; 2 Aug 94 16:57 EDT Message-Id: <9408022058.AA12344@relay.tis.com> Received: from labs-n.bbn.com(128.89.0.100) by relay via smap (V1.3) id sma012340; Tue Aug 2 16:58:14 1994 To: James M Galvin Cc: dns-security@tis.com Subject: Re: draft DNS Security WG minutes In-Reply-To: Your message of Tue, 02 Aug 94 16:19:39 -0400. <9408022019.AA23869@tis.com> Date: Tue, 02 Aug 94 16:53:20 -0400 From: Steve Kent Jim, Thanks for the clarification. When I spoke with Charlie last week I thought he indicated that the latest version still had an option for sending signed data, in lieu of sending the data and the signature. That's the sort of non-algorithm independence I was concerend about, but if that is gone, I fell much better. One might also ask if signing the data, rather than a hash of the data, is worth the extra complexity it introduces, so long as both the data and the hash will be sent anyway in an purely algorithm independent design. Steve   Received: from sol.tis.com by magellan.TIS.COM id aa02579; 2 Aug 94 16:54 EDT Received: from decvax.zk3.dec.com(16.140.0.3) by relay via smap (V1.3) id sma012260; Tue Aug 2 16:55:14 1994 Received: from alpha.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA01575; Tue, 2 Aug 1994 16:55:11 -0400 Received: from localhost by alpha.zk3.dec.com; (5.65/1.1.8.2/26May94-1024AM) id AA21666; Tue, 2 Aug 1994 16:55:19 -0400 Message-Id: <9408022055.AA21666@alpha.zk3.dec.com> To: galvin@tis.com Cc: dns-security@tis.com Subject: Re: draft DNS Security WG minutes Date: Tue, 02 Aug 94 16:55:18 -0400 From: kaufman@zk3.dec.com X-Mts: smtp These are important issues to discuss. On the time critical issue of the minutes, I think the draft minutes are a fair statement of what happened at the meeting if one carefully reads the "XXX asserted". There might be a more forceful statement that no consensus was reached on any of the controversial statements (including whether hacks to keep responses as small as possible are necessary) and that discussion would continue on the list. As it already has. --Charlie (kaufman@zk3.dec.com)   Received: from sol.tis.com by magellan.TIS.COM id aa02978; 2 Aug 94 21:04 EDT Received: from munnari.oz.au(128.250.1.21) by relay via smap (V1.3) id sma015120; Tue Aug 2 21:04:42 1994 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17858; Wed, 3 Aug 1994 10:41:45 +1000 (from kre@munnari.OZ.AU) To: pvm@isi.edu Cc: Steve Kent , James M Galvin , dns-security@tis.com Subject: Re: draft DNS Security WG minutes In-Reply-To: Your message of "Tue, 02 Aug 1994 13:25:05 PDT." <199408022028.AA05306@zephyr.isi.edu> Date: Wed, 03 Aug 1994 10:41:41 +1000 Message-Id: <29730.775874501@munnari.OZ.AU> From: Robert Elz Date: Tue, 02 Aug 94 13:25:05 PDT From: Paul Mockapetris Message-ID: <199408022028.AA05306@zephyr.isi.edu> The DNS group should seek the wisdom of the IPng types with regard to larger MTUs, and is probably pretty safe bumping existing IP size up to ethernet. I'm not sure that there is a lot of wisdom to impart - the issue is not decided. There is a camp arguing for a 1500 minumum mtu, with other link levels being required to internally fragment and re-assemble, and a camp arguing that minimum mtu should be left more or less as now (which is 80 bytes incidentally, not 512 or 536 or 576 or something - the larger number is the minimum "max packet size receivable" and has nothing whatever to do with mtus). Since this doesn't affect the protocol at all, there is no real pressure to come to a decision on this anytime soon. I believe it would be entirely reasonable to require that hosts that want to participate in either DNSv2 or secure DNS (which probably implies the former) have resolver buffers of at least 1500 bytes to handle replies that big. This requires nothing of MTUs in IPv4 (though obviously larger ones avoid fragmentation) nor much of IP6, other than that the servers can discover the MTU so as to know when to send fragments. Certainly sending frags isn't a great thing to do if it can be avoided, but nor is it total disaster. With IP6, as the sender has to know if fragmentation is going to happen, it can always opt to send a TC response, and require a TCP connection for a complete answer. We should probably not invent a MTU mechanism that is DNS specific other than to say "if your MTU is less then X, use TCP". This is reasonable, provided the sender is going to know the MTU - for this kind of query the sender's packet is small, so that's not going to elicit an MTU exceeded ICMP message. Its not clear to me that on a random query sent to a random nameserver the sender has any mechanism to know its MTU, or ever could have, unless we were to adopt a convention that required queries to be sent imbedded in packets that are the same size as the max reply packet we wish to receive (so pad a query to 1500 bytes if a reply up to 1500 was requested). This doesn't seem great to me. I suspect that we're going to need better kernel interfaces, so an ICMP returned will get back to datagram sending applications, along with DNS servers holding responses for a short while (few seconds) after sending them so an ICMP ("frag required") response can be matched with the packet that caused it and some sensible action taken (a TC response, or resend with the frag header). All this is quite a way away from the way things operate now. kre   Received: from sol.tis.com by magellan.TIS.COM id aa03675; 3 Aug 94 5:27 EDT Received: from gw.home.vix.com(192.5.5.1) by relay via smap (V1.3) id sma019403; Wed Aug 3 05:27:49 1994 Received: by gw.home.vix.com id AA29087; Wed, 3 Aug 94 02:27:33 -0700 Date: Wed, 3 Aug 94 02:27:33 -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: draft DNS Security WG minutes Organization: Vixie Enterprises Message-Id: References: Nntp-Posting-Host: office.home.vix.com In-Reply-To: louie@uunet.uu.net's message of 2 Aug 1994 13:30:46 -0700 >Clever resolvers can notice that the truncation occured *after* the answer >section (such as in the additional records section) and choose to not retry >the query using TCP. This can further reduce the effective "failure" rate. That's all true. And in light of it I'd like to point out that BIND is not "clever" by this definition. Yet. -- Paul Vixie Redwood City, CA decwrl!vixie!paul   Received: from sol.tis.com by magellan.TIS.COM id aa03239; 3 Aug 94 1:29 EDT Received: from necom830.cc.titech.ac.jp(131.112.32.132) by relay via smap (V1.3) id sma016531; Wed Aug 3 00:04:48 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 3 Aug 94 12:57:42 +0900 From: Masataka Ohta Return-Path: Message-Id: <9408030357.AA15304@necom830.cc.titech.ac.jp> Subject: Re: draft DNS Security WG minutes To: galvin@tis.com Date: Wed, 3 Aug 94 12:57:41 JST Cc: dns-security@tis.com In-Reply-To: <9408021532.AA17925@tis.com>; from "James M Galvin" at Aug 2, 94 11:32 am X-Mailer: ELM [version 2.3 PL11] > The meeting began with Jim Galvin presenting a very brief summary of his > implementation experience with the Eastlake/Kaufman proposal. No > cryptography was implemented; in the interests of simplicity and > expediency, values were exclusive-ored instead. Also, only the direct > resource records were prototyped. Two results were reported: it is > possible to implement the proposal and the proposal includes more > options than are needed. "it is possible to implement the proposal"? Well, yes, as long as it is self consistent. But that is not what we expected with your implementation effort. Considering that, when I asked you about the partial RR problem of the Eastlake/Kaufman proposal, you didn't understand what "partial RR" means and, at first, we can't even communicate. So, from your effort, you can't say anything more than: it is possible to implement the basic cryptographic frame work of the proposals But, I wrote another draft not because I think the basic cryptographic framework is broken. > The Chair agreed to propose criteria that could be used to evaluate the > two proposals --- Eastlake/Kaufman-lite and Ohta --- One basic difference was and still is simplicity. And you propose to simplify Eastlake/Kaufman a little. And you can continue to do so every time a serious defect of Eastlake/Kaufman proposal is recognized by you. But, what is the point in doing so, as my much simpler proposal is already here? Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa03185; 3 Aug 94 0:59 EDT Received: from necom830.cc.titech.ac.jp(131.112.32.132) by relay via smap (V1.3) id sma016592; Wed Aug 3 00:17:37 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 3 Aug 94 13:04:42 +0900 From: Masataka Ohta Return-Path: Message-Id: <9408030404.AA15356@necom830.cc.titech.ac.jp> Subject: Re: draft DNS Security WG minutes To: Randy Bush Date: Wed, 3 Aug 94 13:04:41 JST Cc: galvin@tis.com, dns-security@tis.com In-Reply-To: ; from "Randy Bush" at Aug 2, 94 11:20 am X-Mailer: ELM [version 2.3 PL11] > > I never did understand how an 10-20% failure rate was ok, but > > that's likely my problem. > > > > Not really. I frankly don't believe the failure rate is all that high. > > I believe my estimate to be conservative on the measure of success. > > I think I understand the analysis. What I do not understand is how we can > find failures acceptable, whether they are 20% or 2%. It seems to me that clear concensus of the DNS SEC meeting among the DNS experts is that 20% or 2% is a problem. But, it does not matter so much, if packet size of 1500 is available without pain. It all depends on how DNS v2 will be. So, what we need for further discussion on the issue is a rather stable and concrete proposal of DNS v2. Without it, only Vixie can say something which can not be a discussion. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa03126; 3 Aug 94 0:29 EDT Received: from necom830.cc.titech.ac.jp(131.112.32.132) by relay via smap (V1.3) id sma016701; Wed Aug 3 00:24:00 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 3 Aug 94 13:15:29 +0900 From: Masataka Ohta Return-Path: Message-Id: <9408030415.AA15431@necom830.cc.titech.ac.jp> Subject: Re: draft DNS Security WG minutes To: Steve Kent Date: Wed, 3 Aug 94 13:15:27 JST Cc: galvin@tis.com, dns-security@tis.com In-Reply-To: <9408021912.AA10180@relay.tis.com>; from "Steve Kent" at Aug 2, 94 3:11 pm X-Mailer: ELM [version 2.3 PL11] > I think a hybrid scheme, with Ohta's simplier structure for > signing records and storing keys, but with the E-K approach to > forward, reverse and cross-certificates (with carefully specified > rules on allowed certification paths to avoid the problems Ohta and > other were concerend about), Beside simplicity, the authentication chain should be the most important difference between two proposals. But, why do you think we need "forward, reverse and cross-certificates"? "titech.ac.jp" and "bbn.com" can cross-certificate each other by configuring each name servers as secondary of the other. Childs of each zone may also do so or may use "forwarder" mechanism. The mechanism is safe, even if the root zone is compromized. So, why do we need "forward, reverse and cross-certificates" mechanism which is not existing-DNS-friendly? secondary   Received: from sol.tis.com by magellan.TIS.COM id aa04022; 3 Aug 94 10:36 EDT Message-Id: <9408031437.AA22269@relay.tis.com> Received: from labs-n.bbn.com(128.89.0.100) by relay via smap (V1.3) id sma022254; Wed Aug 3 10:36:45 1994 To: Masataka Ohta Cc: dns-security@tis.com Subject: Re: draft DNS Security WG minutes In-Reply-To: Your message of Wed, 03 Aug 94 13:15:27 +0200. <9408030415.AA15431@necom830.cc.titech.ac.jp> Date: Wed, 03 Aug 94 10:33:37 -0400 From: Steve Kent I am generally a supporter of top-down certification, as anyone familiar with PEM will attest. I also suggested that we can ask the managers of the DNS root and top level domains to see if they will be quick to sign the records that they have responsibility for, rather than assuming that it will be hard to get these folks to "sign up" for this service. However, I've seen a lot of email traffic suggesting that the top level domains representing countries do exhibit widely varying levels of service, so it may be the case that these domains will not be uniformly quick to support this technology. That argues for allowing one-hop cross-certification, to enable domains to bridge the gaps that may be arise. Also, I agree with Charlie's argument that such cross-certificates are helpful during start up. I'm less persuaded by the argument Steve Bellovin put forth, about companies needing to trust only one another in this scheme, because if cross-certification were common place, rather than the exception, I think the system would be quite unmanageable. I've found many folks who believe that, in general, the higher tier domains are well run and are thus more likely to do a good job of managing this certification process. Many argue that lower tier domains are often poorly managed today, which leads one to question how trusting them to manage the added burden of cross-certificates will make the system more secure! Nonetheless, if the one-hop rule for cross-certification is rigorously enforced in the client software, then cross-certification seems like a reasonable tact. Because the DNS certification hierarchy does not have a PCA tier like the PEM system, and because there is an existing root, some of the reasons that cross-certification is banned in RFC 1422 don't really apply here. (Conversely, the lack of PCAs also argues that the certificates that result from this system will not be appropriate for non-repudiation purposes.) As for the reverse certificates, there are two major arguments in favor of this construct. One argument in favor of forward certificates is that they facillitate use of cross-certificates. The other is that they facilitate switching over to a new root key. The later argument is based on the observation that when such a changeover is required, it is easier to effect if the change need be propogated to only the top level domains, i.e., the ones immediately inferior to the root. In general, when a new key pair is employed anywhere in the system, the affected node must resign data for all of the immediately inferior nodes, and these nodes must each resign their reverse certificates. (Any cross-certificates associated with the affected node also must be reissued.) At any node other than the root, this entails more work than in a system that has only forward certificates. However, in a system with only forward certificates, every node must have the root public key and the distribution of such a new key is obviously a big task. The concern about the logistics of this changeover motivate the use of reverse certificates, as they avoid the need for every node to acquire the root key directly. If one can propose a specific changeover strategy that does not entail the use of reverse certificates, that would help. Use of reverse certificates doubles the storage requirements for certificates in the servers and, in the absence of caching, it generally doubles the certification path length. If caching is used, then the validation burden is lessened, but cache storage requirements grow considerably as well. Moreover, folks are talking about relatively short lifetimes for the certificates, to compensate for the lack of other timeliness safeguards in the DNS interactions. So, caching of certificates may not be as big a win here as in other contexts. Nonetheless, a concrete proposal for root key changeover, that does not require reverse certificates, would help. Personally, I don't think the root key will need to be changed very often, if the root makes use of appropriate security technology and procedures. I am familiar with an existing system that adopts a top-down approach, has over 350,000 leaf nodes, and which supports periodic root key changeover. It does the changeover incrementally, with the old and new keys being valid for an overlapped interval, allowing time for all the leaves to get the new key, which is distributed under the old key. In this system, the leafs are all directly under the root (a very shallow hierarchy) and thus all the leaves must get new certificates as well, a rather major re-distribution activity since the nominal lifettime for the leaf keys is one year. Such a changeover has been effected once already for the system, over the course of several years of operation. So, it can be done, but the details need to be worked out for each specific system. However, for those who feel that cross-certificates are essential, for whatever reason, even solving the root key changeover problem will not do away with the reverse certificate requirement. In that light, it may not be worth the effort to design a root key changeover procedure. Steve   Received: from sol.tis.com by magellan.TIS.COM id aa05036; 3 Aug 94 13:30 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3) id sma025217; Wed Aug 3 13:30:56 1994 Received: from antares.tis.com by tis.com (4.1/SUN-5.64) id AA23999; Wed, 3 Aug 94 13:30:05 EDT Message-Id: <9408031730.AA23999@tis.com> Reply-To: James M Galvin To: kaufman@zk3.dec.com Cc: dns-security@tis.com Subject: Re: draft DNS Security WG minutes In-Reply-To: kaufman@zk3.dec.com's message of Tue, 02 Aug 1994 16:55:18 EDT. <9408022055.AA21666@alpha.zk3.dec.com> Date: Wed, 03 Aug 1994 13:30:12 -0400 From: James M Galvin There might be a more forceful statement that no consensus was reached on any of the controversial statements (including whether hacks to keep responses as small as possible are necessary) and that discussion would continue on the list. I've added the following statement to the last paragraph of the minutes: Since consensus was not possible within the timeframe allotted for the working group meeting, further discussion of the relative merits of each proposal will continue on the mailing list. Jim   Received: from sol.tis.com by magellan.TIS.COM id aa05227; 3 Aug 94 14:37 EDT Received: from mordor.stanford.edu(36.53.0.155) by relay via smap (V1.3) id sma026467; Wed Aug 3 14:38:06 1994 Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id LAA25381; Wed, 3 Aug 1994 11:37:13 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 3 Aug 1994 11:37:18 -0700 To: Steve Kent From: Dave Crocker Subject: Re: draft DNS Security WG minutes Cc: Masataka Ohta , dns-security@tis.com > Many argue that lower tier >domains are often poorly managed today, which leads one to question >how trusting them to manage the added burden of cross-certificates >will make the system more secure! Unfortunately, this is a fair concern. On the other hand, such folk are also going to be required to manage telent, ftp, and other access to/for their organization well-enough. So the result will be that their DNS records will be (only) as good as their administration. On the other hand, I don't see how a multi-level inheritence model improves on the flakiness of a site. At best, it maintain it. At worst, it adds more opportunities for flakiness (though probably less likely, as you observe.) ----- Dave Crocker 675 Spruce Dr. +1 408 246 8253; fax: +1 408 249 6205 Sunnyvale, CA 94086 (USA)   Received: from sol.tis.com by magellan.TIS.COM id aa05278; 3 Aug 94 14:52 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3) id sma026815; Wed Aug 3 14:53:11 1994 Received: from antares.tis.com by tis.com (4.1/SUN-5.64) id AA28694; Wed, 3 Aug 94 14:52:22 EDT Message-Id: <9408031852.AA28694@tis.com> Reply-To: James M Galvin To: minutes@cnri.reston.va.us Cc: dns-security@tis.com Subject: DNS Security Working Group Minutes Mime-Version: 1.0 Content-Type: multipart/signed; protocol="pem"; hashalg="md5"; boundary="----- =_aaaaaaaaaa1" Date: Wed, 03 Aug 1994 14:52:28 -0400 From: James M Galvin ------- =_aaaaaaaaaa1 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <4466.775939930.2@tis.com> ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4466.775939930.3@tis.com> Please find enclosed below the minutes of the DNS Security Working Group July 1994 (Toronto) Meeting for inclusion in the proceedings. Jim Galvin Chair ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4466.775939930.4@tis.com> Content-Description: DNSSEC WG minutes DNS Security WG Meeting Minutes July 1994 Toronto Recorded by Jim Galvin, Chair The DNS Security Working Group met on Wednesday morning for a 2.5 hours meeting. Masataka Ohta had previously submitted an alternative to the Donald Eastlake and Charlie Kaufman proposal. The majority of this meeting was dedicated to discussing the differences between the two proposals. The meeting began with Jim Galvin presenting a very brief summary of his implementation experience with the Eastlake/Kaufman proposal. No cryptography was implemented; in the interests of simplicity and expediency, values were exclusive-ored instead. Also, only the direct resource records were prototyped. Two results were reported: it is possible to implement the proposal and the proposal includes more options than are needed. Jim observed that one of the principal motivations for many of the options in the Eastlake/Kaufman proposal was the perception that the 512 byte limit for DNS messages was too small. However, he asserted that this limit was in fact not an issue, for two reasons that would be explained later. As a result, he had a proposal for how to proceed but preferred to yield the floor to the Kaufman and Ohta for a discussion of their lists of issues. The remainder of the meeting was dedicated to Kaufman and Ohta each presenting a list of questions and comments about each others' proposals. There was a great deal of vigorous and animated discussion about the issues. Careful time management allowed a complete presentation of all the issues, with some discussion for each, although no conclusions were reached. Since both Ohta and Kaufman agreed to distribute their lists to the electronic mailing lists for continued discussion and resolution, the details are not presented here. The meeting closed with Jim proposing that Eastlake/Kaufman reduce their proposal to include only the hashed resource record, for two reasons. First, there is the assertion that the 512 byte limit would be sufficient about 80-90% of the time. However, even without this assertion, Version 2 of DNS will shortly be proposed that will increase the message size limit. TIS will implement the proposed DNS security enhancements with this new version of DNS. Jim will followup with Eastlake and Kaufman about reducing their proposal, identified as Eastlake/Kaufman-lite. Since consensus was not possible within the timeframe allotted for the working group meeting, further discussion of the relative merits of each proposal will continue on the mailing list. The Chair agreed to propose criteria that could be used to evaluate the two proposals --- Eastlake/Kaufman-lite and Ohta --- to aid the working group in selecting one to submit to the standards track. Consensus and a single proposal will be obtained on the mailing list prior to the next IETF; this group expects to meet in San Jose. ------- =_aaaaaaaaaa0-- ------- =_aaaaaaaaaa1 Content-Type: application/signature Content-ID: <4466.775939930.1@tis.com> Content-Transfer-Encoding: quoted-printable Version: 5 Originator-ID: IS,MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1= c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA=3D=3D,02 MIC-Info: RSA-MD5,RSA,TTHTYlpfSeX5vN9nvjcYomGZ/KE/Ng+YPl2OCmkNY0q1TVztfu4J= BZC5LllMqHW48LR3xV8yLJ5RNqNpKrwZ8JA/e3KV+GO6AFRiqK9Z2Y5IzERFxJ9A2HVHY/oEWJ= lm ------- =_aaaaaaaaaa1--   Received: from sol.tis.com by magellan.TIS.COM id aa05567; 3 Aug 94 16:29 EDT Received: from atc.boeing.com(130.42.28.80) by relay via smap (V1.3) id sma028338; Wed Aug 3 16:11:59 1994 Received: by atc.boeing.com (5.57) id AA25721; Wed, 3 Aug 94 13:13:49 -0700 Received: from commanche.ca.boeing.com by splinter.boeing.com with SMTP (16.6/16.2) id AA24439; Wed, 3 Aug 94 13:12:02 -0700 Received: by commanche.ca.boeing.com. (AIX 3.2/UCB 5.64/4.03) id AA22467; Wed, 3 Aug 1994 13:10:48 -0700 Message-Id: <9408032010.AA22467@commanche.ca.boeing.com.> To: kent@bbn.com Cc: galvin@tis.com, dns-security@tis.com Subject: Re: draft DNS Security WG minutes In-Reply-To: (Your message of Tue, 02 Aug 94 15:11:58 D.) <9408021912.AA10180@relay.tis.com> Date: Wed, 03 Aug 94 13:10:47 -0800 From: "Terry L. Davis P.E., Boeing Computer Services, Bellevue, WA" Steve In response to your suggestion that an analysis of the length of the typical DNS server responses was needed. We trapped four hours of data on one of our busier servers here at Boeing. We have twenty-some others active as primary/secondaries within the corporation. It makes for some interesting discussion and probably asks more questions than it answers alone. The address has been blanked per security. Take care Terry L. Davis | 206-957-5325 | tld5032@commanche.ca.boeing.com. Charles DeRykus | 206-957-5326 | ced@carios2.ca.boeing.com. Boeing Computer Services, Bellevue, WA --------------- Wednesday August 03,1994 12:57 PM PDT ------------- == As always, the above cannot be construed as representing BOEING. == ---------------------------------------------------------- ---------------------------------------------------------- DNS Server -- Packet Len Data ---------------------------------------------------------- Wed Aug 3 07:19:45 PDT 1994 analysing dns packets to xxx.xx.xxx.xx from: host='*' begin: Wed Aug 3 07:19:46 PDT 1994 end: Wed Aug 3 11:20:07 PDT 1994 query total: 90235 Packet Size No. of Requests ----------- --------------- 553 1 550 1 422 34 421 5 412 1 357 1 335 1 320 1 317 1 316 1 255 27 254 3 253 1 252 1 246 1 240 1 226 2 222 1 220 1 217 2 216 16 210 1 208 4 204 35 201 1 193 1 178 1 175 6 174 2 173 198 172 267 171 303 170 5 169 2 167 1 166 3 165 19 164 21 163 55 162 88 161 181 160 200 159 315 158 1347 157 331 156 548 155 326 154 126 153 94 152 48 151 204 150 95 149 123 148 58 147 43 146 263 145 367 144 3472 143 256 142 215 141 284 140 648 139 460 138 3267 137 2031 136 407 135 34 134 44 133 37 132 2 131 9 130 1 129 3 128 4 127 2 126 2 125 6 124 2 123 17 122 41 121 33 120 26 119 22 118 15 117 5 116 4 115 5 114 6 113 5 112 4 111 1 110 24 109 6 108 5 107 1 106 8 105 13 104 6 103 3 102 14 101 106 100 136 99 171 98 181 97 334 96 519 95 1553 94 654 93 920 92 1986 91 886 90 3736 89 2754 88 1176 87 5235 86 6099 85 2954 84 4344 83 4099 82 2694 81 12039 80 2040 79 1594 78 5505 77 1848 76 472 75 953 74 772 73 3271 72 2074 71 414 70 34 69 57 68 35 67 2 66 9 65 1 63 1 60 1342   Received: from sol.tis.com by magellan.TIS.COM id aa05753; 3 Aug 94 18:15 EDT Received: from tsx-11.mit.edu(18.172.1.2) by relay via smap (V1.3) id sma000266; Wed Aug 3 18:16:22 1994 Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA17478; Wed, 3 Aug 94 18:14:28 EDT Date: Wed, 3 Aug 94 18:14:28 EDT From: Theodore Ts'o Message-Id: <9408032214.AA17478@tsx-11.MIT.EDU> To: Masataka Ohta Cc: Steve Kent , galvin@tis.com, dns-security@tis.com In-Reply-To: Masataka Ohta's message of Wed, 3 Aug 94 13:15:27 JST, <9408030415.AA15431@necom830.cc.titech.ac.jp> Subject: Re: draft DNS Security WG minutes Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 From: Masataka Ohta Date: Wed, 3 Aug 94 13:15:27 JST X-Mailer: ELM [version 2.3 PL11] But, why do you think we need "forward, reverse and cross-certificates"? "titech.ac.jp" and "bbn.com" can cross-certificate each other by configuring each name servers as secondary of the other. This is not correct; merely configuring a nameserver to secondary off of another does not imply that the two domains have cross-certified each other. Every domain is required to set up secondary name servers; this does not imply that each domain will be setting up cross-certificates! - Ted   Received: from sol.tis.com by magellan.TIS.COM id aa05764; 3 Aug 94 18:17 EDT Message-Id: <9408032218.AA00296@relay.tis.com> Received: from labs-n.bbn.com(128.89.0.100) by relay via smap (V1.3) id sma000291; Wed Aug 3 18:18:21 1994 To: "Terry L. Davis P.E., Boeing Computer Services, Bellevue,\ WA" Cc: dns-security@tis.com Subject: Re: draft DNS Security WG minutes In-Reply-To: Your message of Wed, 03 Aug 94 13:10:47 -0800. <9408032010.AA22467@commanche.ca.boeing.com.> Date: Wed, 03 Aug 94 18:16:54 -0400 From: Steve Kent Terry, Thanks for the data. This is exactly the sort of info I think one needs to be able to make some projections about the impact of signatures on DNS accesses. It will, as you suggested, take some time to analyze, and I hope other DNS operators will follow your lead and gather the same sort of data. Steve   Received: from sol.tis.com by magellan.TIS.COM id aa05809; 3 Aug 94 19:00 EDT Received: from tsx-11.mit.edu(18.172.1.2) by relay via smap (V1.3) id sma001124; Wed Aug 3 19:01:12 1994 Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA17936; Wed, 3 Aug 94 19:00:55 EDT Date: Wed, 3 Aug 94 19:00:55 EDT From: Theodore Ts'o Message-Id: <9408032300.AA17936@tsx-11.MIT.EDU> To: Steve Kent Cc: Masataka Ohta , dns-security@tis.com In-Reply-To: Steve Kent's message of Wed, 03 Aug 94 10:33:37 -0400, <9408031437.AA22269@relay.tis.com> Subject: Re: draft DNS Security WG minutes Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 There is another reason for reverse certificates, which is limiting the number of keys that you need to trust. For example, if your hierarchy is: UN US USSR Army Navy Alice Bob One can make the argument that Alice, in the the U.S. Army, and Bob, in the U.S. Navy, should be able to authenticate to one another without needing to trust the U.N. The reverse certificates provide this because they allow Alice can verify Bob's key using the two reverse certificates (Alice->Army, Army->US), and two forward certificates (US->Navy, Navy->Bob) starting from a locally known, trusted key (Alice's). In contrast, in the top down certification, Alice would have to check three forward certificates (UN->US, US->Navy, Navy->Bob), starting from the U.N.'s key. Perhaps this means that you "obviously" don't put an untrusted organization (like the U.N.) at the top of the hierarchy. But if two users in LCS.MIT.EDU and AI.MIT.EDU want to authenticate to each other, why should they need to rely on anyone's keys at the root level? After all, they need to rely on the security of the keys closest to them anyway, so why add extra trust requirements? - Ted P.S. Also note that the above example also shows that the reverse certificates do not necessarily double the certification chain, compared to the top-down approach. It all depends on how many zones there are between you and the root. In some cases, the reverse certificate approach might actually require fewer certificate verifications!   Received: from sol.tis.com by magellan.TIS.COM id aa05935; 4 Aug 94 3:04 EDT Received: from gw.home.vix.com(192.5.5.1) by relay via smap (V1.3) id sma005448; Thu Aug 4 03:05:26 1994 Received: by gw.home.vix.com id AA27273; Thu, 4 Aug 94 00:05:09 -0700 Date: Thu, 4 Aug 94 00:05:09 -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: draft DNS Security WG minutes Organization: Vixie Enterprises Message-Id: References: <9408032300.AA17936@tsx-11.MIT.EDU> Nntp-Posting-Host: office.home.vix.com In-Reply-To: tytso@athena.mit.edu's message of 3 Aug 1994 17:01:09 -0700 Agreed. In Ted's example, LCS and AI should be able to learn to trust each other if they both trust MIT. EDU and Root shouldn't (have to be) involved. -- Paul Vixie Redwood City, CA decwrl!vixie!paul   Received: from sol.tis.com by magellan.TIS.COM id aa06639; 4 Aug 94 10:10 EDT Message-Id: <9408041411.AA10040@relay.tis.com> Received: from labs-n.bbn.com(128.89.0.100) by relay via smap (V1.3) id sma010034; Thu Aug 4 10:10:57 1994 To: Theodore Ts'o Cc: dns-security@tis.com Subject: Re: draft DNS Security WG minutes In-Reply-To: Your message of Wed, 03 Aug 94 19:00:55 -0400. <9408032300.AA17936@tsx-11.MIT.EDU> Date: Thu, 04 Aug 94 10:07:46 -0400 From: Steve Kent Ted, My comments were to be interpreted strictly in the context of the DNS, where the hierarchy is already well defined and where the mapping between those who already control the name space in question and the certification hierarchy could be a homomorphism. Your example is from a different context, one that mixes DNS-style names and X.500- style directory strucure, a hierarchy that does not exist. Nonetheless, your point about a motivation for cross-certificates being appropriate when the higher tiers are not trusted by lower tiers to vouch for identity is generally true. There is a subtle point here, namely that an authority who is recognized as empowered to manage a portion of a name space does is not necessarily trusted by subordinate entities to authenticate them in that name space. This concept was recognized in the PEM hierarchy by not requiring name subordination starting at the root, but rather requiring it only below the third tier in the hierarchy, at the organizational and geopolitical tier. However, because the top two tiers of that design embody semantics that is not derrivable from name formats, and because of the limitations of X.509 certificate formats, it was not possible to syntactically implement the sort of limited cross-certification that the E-K proposal calls for in the DNS context. For example, a cross-certificate that transitioned from one PCA domain to another would not have been automatically detectable by a user following a certification path. As for doubling certification path length, you're right that cross-certificates can actually shorten the length, if they are used as short-cuts between relatively deep points in the hierarchy. However, if they are used primarily at the organization level (rather than at subordinate organizations, etc.), then in the current DNS structure it is likely that they will not really shorten path lengths and probably will lengthen them. Also, I think my comment focused on the use of reserve-certificates per se, where this observation is true, as opposed to reverse certificates plus cross-certificates. Steve   Received: from sol.tis.com by magellan.TIS.COM id aa06865; 4 Aug 94 10:29 EDT Received: from venera.isi.edu(128.9.0.32) by relay via smap (V1.3) id sma010088; Thu Aug 4 10:13:27 1994 Received: from zephyr.isi.edu by venera.isi.edu (5.65c/5.61+local-14) id ; Thu, 4 Aug 1994 07:09:25 -0700 Message-Id: <199408041409.AA09987@venera.isi.edu> To: Steve Kent Cc: Masataka Ohta , dns-security@tis.com Reply-To: pvm@isi.edu Subject: Re: draft DNS Security WG minutes In-Reply-To: Your message of Wed, 03 Aug 1994 10:33:37 -0400. <9408031437.AA22269@relay.tis.com> Date: Thu, 04 Aug 94 07:08:10 PDT From: Paul Mockapetris Regardless of which system is adopted, we probably need a model that allows the system to be tested and developed without root participation. Also, since the DNS root is international, we may find ourselves down a policy rathole. 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 aa07830; 4 Aug 94 15:36 EDT Received: from tsx-11.mit.edu(18.172.1.2) by relay via smap (V1.3) id sma015935; Thu Aug 4 15:36:57 1994 Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA02226; Thu, 4 Aug 94 15:36:30 EDT Date: Thu, 4 Aug 94 15:36:30 EDT From: Theodore Ts'o Message-Id: <9408041936.AA02226@tsx-11.MIT.EDU> To: Steve Kent Cc: Theodore Ts'o , dns-security@tis.com In-Reply-To: Steve Kent's message of Thu, 04 Aug 94 10:07:46 -0400, <9408041410.AA28462@MIT.EDU> Subject: Re: draft DNS Security WG minutes Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Well, I can certainly come up with examples that are DNS-centric, as opposed to the X.500-style example that I came up with; I simply chose that because it was more "vivid" an example. :-) But there are others that I could come up with, involving transferring grades (aka educational records) between someone at prof@lcs.mit.edu and TA@ai.mit.edu --- or personnel information between AO@research.ibm.com and reorg@corporate.ibm.com where there might very well be strong reasons why MIT and IBM might want some sort of authentication which didn't rely on the trustworthiness of the root servers. There is a valid question of how often these sorts of things come up --- which should drive whether they should be better handled as special-case "cross-certificates", or whether we should use a more general approach using the "up" and "down" certifications of the E-K proposal. - Ted   Received: from sol.tis.com by magellan.TIS.COM id aa07939; 4 Aug 94 16:45 EDT Message-Id: <9408042046.AA17055@relay.tis.com> Received: from labs-n.bbn.com(128.89.0.100) by relay via smap (V1.3) id sma017047; Thu Aug 4 16:46:13 1994 To: Theodore Ts'o Cc: dns-security@tis.com Subject: Re: draft DNS Security WG minutes In-Reply-To: Your message of Thu, 04 Aug 94 15:36:30 -0400. <9408041936.AA02226@tsx-11.MIT.EDU> Date: Thu, 04 Aug 94 16:43:12 -0400 From: Steve Kent Ted, I'm much more comfortable with having a general purpose mechanism for allowing cross-certification within the DNS hierarchy, so that client and server software is generally availabel to do "the right thing," than making special arrangements that would not be readily supported by COTS software. However, I think we need to keep in mind the added complexity of having folks manage cross-certificates, especially in light of the stories I hear about less than ideal management of parts of the current system elements. One should not design on the assumption that cross-certificates would be required in general, since the fan out on cross-certificates could be horrible. One should push for forward certificates from the root, and allow for cross certificates on an as needed basis (and for experiementation and initial deployment). This is the model Charlie articulated last week and its one I'm comfortable with. Steve   Received: from sol.tis.com by magellan.TIS.COM id aa08107; 4 Aug 94 18:40 EDT Received: from tsx-11.mit.edu(18.172.1.2) by relay via smap (V1.3) id sma018503; Thu Aug 4 18:40:25 1994 Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA05913; Thu, 4 Aug 94 18:40:01 EDT Date: Thu, 4 Aug 94 18:40:01 EDT From: Theodore Ts'o Message-Id: <9408042240.AA05913@tsx-11.MIT.EDU> To: Steve Kent Cc: Theodore Ts'o , dns-security@tis.com In-Reply-To: Steve Kent's message of Thu, 04 Aug 94 16:43:12 -0400, <9408042045.AA25397@MIT.EDU> Subject: Re: draft DNS Security WG minutes Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Date: Thu, 04 Aug 94 16:43:12 -0400 From: Steve Kent I'm much more comfortable with having a general purpose mechanism for allowing cross-certification within the DNS hierarchy, so that client and server software is generally availabel to do "the right thing," than making special arrangements that would not be readily supported by COTS software. However, I think we need to keep in mind the added complexity of having folks manage cross-certificates, especially in light of the stories I hear about less than ideal management of parts of the current system elements. One should not design on the assumption that cross-certificates would be required in general, since the fan out on cross-certificates could be horrible. One should push for forward certificates from the root, and allow for cross certificates on an as needed basis (and for experiementation and initial deployment). This is the model Charlie articulated last week and its one I'm comfortable with. I think there's a disconnect here somewhere, perhaps in our use of terminologies. In the E-K proposal, there are three kinds of certificates. "Down" certificates, where the parent node certifies the child, "Up" certificates, where the child certifies the parent, and "Cross" certificates where a node certifies some other node which is neither a child nor a parent. (I don't know if they are using these terms, but this is the basic concept in the DASS/SPX model, which is carried over in the E-K proposal, as I understand things.) In the examples that I gave, there weere no cross certificates; there were simply "up" certificates and "down" certificates --- and so without needing any cross certificates, it is possible for users in LCS.MIT.EDU and AI.MIT.EDU to certify one another without needing to trust the root. The claim is that "Up" certificates are not particular hard to manage, compared to "Cross" certificates, since like "Down" certificates, they have a well defined semantic meaning --- this is a certification by a child of its parent's public key. Are you disputing this claim, or the claim that the applications detailed in my last message cannot be accomplished without "Cross" certificates. - Ted   Received: from sol.tis.com by magellan.TIS.COM id aa08502; 5 Aug 94 4:29 EDT Received: from necom830.cc.titech.ac.jp(131.112.32.132) by relay via smap (V1.3) id sma022627; Fri Aug 5 03:54:37 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 5 Aug 94 16:45:43 +0900 From: Masataka Ohta Return-Path: Message-Id: <9408050745.AA01836@necom830.cc.titech.ac.jp> Subject: Re: draft DNS Security WG minutes To: Steve Kent Date: Fri, 5 Aug 94 16:45:42 JST Cc: dns-security@tis.com In-Reply-To: <9408031428.AA17783@necom830.cc.titech.ac.jp>; from "Steve Kent" at Aug 3, 94 10:33 am X-Mailer: ELM [version 2.3 PL11] > I am generally a supporter of top-down certification, as > anyone familiar with PEM will attest. I also suggested that we can > ask the managers of the DNS root and top level domains to see if they > will be quick to sign the records that they have responsibility for, > rather than assuming that it will be hard to get these folks to "sign > up" for this service. However, I've seen a lot of email traffic > suggesting that the top level domains representing countries do > exhibit widely varying levels of service, so it may be the case that > these domains will not be uniformly quick to support this technology. > That argues for allowing one-hop cross-certification, to enable > domains to bridge the gaps that may be arise. Also, I agree with > Charlie's argument that such cross-certificates are helpful during > start up. I'm less persuaded by the argument Steve Bellovin put > forth, about companies needing to trust only one another in this > scheme, because if cross-certification were common place, rather than > the exception, I think the system would be quite unmanageable. Then, what we need is not cross certification, but authentication roots other than the DNS root. Moreover, field of ZSIG RR in my proposal is the mechanism to support it, I think. For example, "masterauthenticator.int" can be a signer of "bbn.com" and "titech.ac.jp" and all the name servers in "bbn.com" and "titech.ac.jp" should have some information, for example, MD5 of the zones public key, to authenticate "masterauthenticator.int". The machanism also allows the root zone sign "titech.ac.jp" without signing "ac.jp" nor "jp". So, aren't your requirements satisfied? > I've found many folks who believe that, in general, the higher > tier domains are well run and are thus more likely to do a good job of > managing this certification process. Many argue that lower tier > domains are often poorly managed today, which leads one to question > how trusting them to manage the added burden of cross-certificates > will make the system more secure! Cross-certificates, in one sense, make the system less secure. Currently, resolvers are tied to name servers (SBELT) but not tied to any zone. (Donald-Charile draft is confused on this point that they think name servers are tied to zones they serve, but the issue is a resolver issue) Thus, with the hierarchical scheme, compromizing of a zone only affect zones below it. Moreover, if SBELT hosts are configured with a public key of a foreign zone, the resolver is further protected from the compromized parent zone of the foreign zone. On the other hand, if an SBELT host is compromized, the resolver is compromized. But with a resolver tied to a zone, compromizing of zones above the resolver's zone affect all the queries the resolver makes with false cross certificates. So, the issue is whether we trust SBELT hosts, which are expected to be local, and a root zone or parent zones of some zone > However, in a system with only forward certificates, every node must > have the root public key and the distribution of such a new key is > obviously a big task. The concern about the logistics of this > changeover motivate the use of reverse certificates, as they avoid the > need for every node to acquire the root key directly. That mechanism to dynamically changes information on root name servers has been available for a long time. The problem was that the information was not reliable. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa08776; 5 Aug 94 5:59 EDT Received: from necom830.cc.titech.ac.jp(131.112.32.132) by relay via smap (V1.3) id sma022814; Fri Aug 5 04:39:52 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 5 Aug 94 17:30:07 +0900 From: Masataka Ohta Return-Path: Message-Id: <9408050830.AA02170@necom830.cc.titech.ac.jp> Subject: Re: draft DNS Security WG minutes To: Theodore Ts'o Date: Fri, 5 Aug 94 17:30:05 JST Cc: kent@bbn.com, galvin@tis.com, dns-security@tis.com In-Reply-To: <9408032214.AA17478@tsx-11.MIT.EDU>; from "Theodore Ts'o" at Aug 3, 94 6:14 pm X-Mailer: ELM [version 2.3 PL11] > But, why do you think we need "forward, reverse and cross-certificates"? > > "titech.ac.jp" and "bbn.com" can cross-certificate each other > by configuring each name servers as secondary of the other. > > This is not correct; merely configuring a nameserver to secondary off of > another does not imply that the two domains have cross-certified each > other. Oops, OK, first of all, in the current DNS model, entities who ask a query may not belongs to DNS tree at all. Even if the entity has a domain name, it has not necessarily the name from which the upward query starts. Even if the entity is a name server serving several zones, it has not necessarily the zone(s) from which the upward query starts. So, saying "cross-certificate" is rather meaningless. When I wrote: > "titech.ac.jp" and "bbn.com" can cross-certificate each other > by configuring each name servers as secondary of the other. it meant that resolvers asking name servers of "titech.ac.jp" about data in "bbn.com" won't be affected by the compromized "com" or "." zone and vice versa. I also assume, as written in my draft, that secondaries statically knows public key (or something like that) of the zone it serves. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa09428; 5 Aug 94 11:50 EDT Message-Id: <9408051551.AA26805@relay.tis.com> Received: from labs-n.bbn.com(128.89.0.100) by relay via smap (V1.3) id sma026801; Fri Aug 5 11:51:26 1994 To: Masataka Ohta Subject: Re: draft DNS Security WG minutes Cc: dns-security@tis.com Date: Fri, 05 Aug 94 11:48:57 -0400 From: Steve Kent Ohta san, One could have authentication roots other than the DNS root, and that is what cross-certificates, or following reverse certificates to a common ancestor, allows. A cross-certificate enables a node (e.g. an organization) to make an explicit assertion that it trusts another node without having to trust nodes higher in the certification tree. A cross-certificate is generally assumed to be manually configured and thus maintenance of cross-certificates is potentially a labor intensive activity. So, without creating any new nodes or pseudo-nodes, one can express these trust relationships whenever it is deemed necessary, e.g., whenever the parties in question do not have adequate trust in superior nodes. I agree that cross-certificates can make the system less secure, but, as pointed out last week, errors (or malicious attacks) in configuring cross-certificates affect only those nodes lower in the certification tree. If one employs cross-certificates only at the organizational level, then this bounds the damage "appropriately." I think the arguments presented in favor of cross-certification don't apply very well if, for example, cross-certificates were employed at TLDs like COM or EDU. I think I understand your comments about about the association between resolvers and name servers vs. zones. The E-K proposal does assume, I believe, that a client (resolver) making a query is a client of some zone, and thus can easily acquire (via local, integrity-secure means) the public key of that zone. That key represents the operable part of the up-certificate from that resolver to the zone, and thus is the basis for starting an up-certification path. I believe your point is that if resolvers don't have such a close association to zones, but rather to servers (which are not represented as secure entities in our models), then the task of acquiring some zone key as a starting point is no easier than acquiring the root key, maybe even harder. Also, if a resolver does not have an affiliation with a zone, then the trust arguments that motivate cross-certificates are not applicable, either. Is this an accurate paraphrase of your concerns? As for the final point, about root key changeover, remember that the requirement here is to be able to distribute a new one to all the resolvers. If the change is just a "preventative maintenance" measure, then I agree that it can be effected in an orderly fashion using the old key. There is a concern that a compromise of the root key would make it very hard to distribute a new one, and so that possibility is the one that the up-certificate approach tends to address better than a pure top-down model. Steve   Received: from sol.tis.com by magellan.TIS.COM id aa09450; 5 Aug 94 11:56 EDT Message-Id: <9408051557.AA26949@relay.tis.com> Received: from labs-n.bbn.com(128.89.0.100) by relay via smap (V1.3) id sma026938; Fri Aug 5 11:56:37 1994 To: Theodore Ts'o Cc: dns-security@tis.com Subject: Re: draft DNS Security WG minutes In-Reply-To: Your message of Thu, 04 Aug 94 18:40:01 -0400. <9408042240.AA05913@tsx-11.MIT.EDU> Date: Fri, 05 Aug 94 11:55:07 -0400 From: Steve Kent Ted, I apologize for getting lost in our discussion. The terminology I was using is from X.509, where up-certificates are referred to as reverse-certificates, forward-certificates are the equivalent of down-certificates, and cross-certificates are more or less the same. You are right that your examples required only up (reverse) certificates, not cross certificates. In the DNS example, because of the existing tree structure and name constraints, one can use up certificates alone to minimize trust in the top-most tiers, but only if there is a lower node that they trust and which is a common ancestor. Examples given by other folks to motivate cross-certificates focus on inter-organization relationships at higher tiers, where there was no common ancestor node that was trusted. In those cases, cross-certificates are needed to avoid trust in the root or in TLDs such as COM. Sorry for the confusion, Steve   Received: from sol.tis.com by magellan.TIS.COM id aa10306; 5 Aug 94 17:08 EDT Received: from tsx-11.mit.edu(18.172.1.2) by relay via smap (V1.3) id sma002395; Fri Aug 5 17:09:07 1994 Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA26388; Fri, 5 Aug 94 17:07:58 EDT Date: Fri, 5 Aug 94 17:07:58 EDT From: Theodore Ts'o Message-Id: <9408052107.AA26388@tsx-11.MIT.EDU> To: Masataka Ohta Cc: kent@bbn.com, galvin@tis.com, dns-security@tis.com In-Reply-To: Masataka Ohta's message of Fri, 5 Aug 94 17:30:05 JST, <9408050830.AA02170@necom830.cc.titech.ac.jp> Subject: Re: draft DNS Security WG minutes Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 From: Masataka Ohta Date: Fri, 5 Aug 94 17:30:05 JST When I wrote: > "titech.ac.jp" and "bbn.com" can cross-certificate each other > by configuring each name servers as secondary of the other. it meant that resolvers asking name servers of "titech.ac.jp" about data in "bbn.com" won't be affected by the compromized "com" or "." zone and vice versa. And how do resolvers asking the name servers of "titech.ac.jp" know that they really got an answer from "titech.ac.jp"? Are you assuming authentication by IP address, ala rlogin? - Ted   Received: from sol.tis.com by magellan.TIS.COM id aa12538; 8 Aug 94 7:38 EDT Received: from tsx-11.mit.edu(18.172.1.2) by relay via smap (V1.3) id sma012767; Mon Aug 8 07:38:49 1994 Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA07338; Mon, 8 Aug 94 07:37:39 EDT Date: Mon, 8 Aug 94 07:37:39 EDT From: Theodore Ts'o Message-Id: <9408081137.AA07338@tsx-11.MIT.EDU> To: Masataka Ohta Cc: kent@bbn.com, galvin@tis.com, dns-security@tis.com In-Reply-To: Masataka Ohta's message of Mon, 8 Aug 94 13:44:55 JST, <9408080445.AA05157@necom830.cc.titech.ac.jp> Subject: Re: draft DNS Security WG minutes Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 From: Masataka Ohta Date: Mon, 8 Aug 94 13:44:55 JST > Are you assuming > authentication by IP address, ala rlogin? No. Resolvers retrieve authenticated data through authenticated communication between SBELT or co-located name servers. Your claim is that you can deal with the cross-certification issue by merely making one site (titech.ac.jp) be a secondary for another (bbn.com). This doesn't work. Merely making one site be a secondary for another doesn't change the fact that the zone key for bbn.com is still signed by the com public key --- which may have been spoofed. There is no authenticated communication between the resolver and the nameserver; the nameserver only hands back signed records, and changing where you get the information by having the resolver talk to a secondary does not change who has signed the records. Hence, your suggested solution of making titech.ac.jp be a secondary for bbn.com has no cryptographic significance, and is rather pointless. If you are suggesting a solution where you have authenticated communication between the resolver and the name server, recall that this requires that the zone private key (or at least some other private key) must be on-line on the name server. This is considered a Bad Thing, for the obvious security reasons. - Ted   Received: from sol.tis.com by magellan.TIS.COM id aa12043; 8 Aug 94 1:59 EDT Received: from necom830.cc.titech.ac.jp(131.112.32.132) by relay via smap (V1.3) id sma011427; Mon Aug 8 00:53:17 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 8 Aug 94 13:44:57 +0859 From: Masataka Ohta Return-Path: Message-Id: <9408080445.AA05157@necom830.cc.titech.ac.jp> Subject: Re: draft DNS Security WG minutes To: Theodore Ts'o Date: Mon, 8 Aug 94 13:44:55 JST Cc: kent@bbn.com, galvin@tis.com, dns-security@tis.com In-Reply-To: <9408052107.AA26388@tsx-11.MIT.EDU>; from "Theodore Ts'o" at Aug 5, 94 5:07 pm X-Mailer: ELM [version 2.3 PL11] > > "titech.ac.jp" and "bbn.com" can cross-certificate each other > > by configuring each name servers as secondary of the other. > > it meant that resolvers asking name servers of "titech.ac.jp" about > data in "bbn.com" won't be affected by the compromized "com" or "." > zone and vice versa. > > And how do resolvers asking the name servers of "titech.ac.jp" know that > they really got an answer from "titech.ac.jp"? Don't assume PEM environment where both senders and recipients have mail addresses. Resolvers don't get answer from "titech.ac.jp". Resolvers get answer from name servers. The name servers may or may not serve "titech.ac.jp". > Are you assuming > authentication by IP address, ala rlogin? No. Resolvers retrieve authenticated data through authenticated communication between SBELT or co-located name servers. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa12029; 8 Aug 94 1:54 EDT Received: from necom830.cc.titech.ac.jp(131.112.32.132) by relay via smap (V1.3) id sma011746; Mon Aug 8 01:54:48 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 8 Aug 94 14:45:18 +0900 From: Masataka Ohta Return-Path: Message-Id: <9408080545.AA14050@necom830.cc.titech.ac.jp> Subject: Re: draft DNS Security WG minutes To: Steve Kent Date: Mon, 8 Aug 94 14:45:17 JST Cc: dns-security@tis.com In-Reply-To: <9408051551.AA26805@relay.tis.com>; from "Steve Kent" at Aug 5, 94 11:48 am X-Mailer: ELM [version 2.3 PL11] > Ohta san, > > One could have authentication roots other than the DNS root, > and that is what cross-certificates, or following reverse certificates > to a common ancestor, allows. Fine. I think the following ZSIG mechanism already satisfies your requirements. ZSIG (Zone SIGnature) Data added to a secure zone to specify how to verify ZA of the zone. ZSIG data contains a signature of digest of the zone's ZA signed by other secure zones, typically its parent zone. ^^^^^^^^^^^^^^^^^^^^^^^^^^ [ZSIG] RRs have the following syntax. [ZSIG] <[NSIG]> where [ZSIG] is the RR name of ZSIG data, is a domain name of a zone who signs [ZA], <[NSIG]> is the methods used for signature (represented in RR type) used by the . In general, only a who is a parent or ancestor of the signed zone or the root zone should be considered to be secure, though local administrator may add or remove reliable s ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ according to their local security policy. For the root zone or ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ locally reliable zones, name servers should be statically configured with information to authenticate [ZSIG]. I provided the field partly because of initial deployment phase. Wordings on treatment of multiple ZSIGs should be added, I think. > A cross-certificate enables a node > (e.g. an organization) to make an explicit assertion that it trusts > another node without having to trust nodes higher in the certification > tree. Certainly. > A cross-certificate is generally assumed to be manually > configured and thus maintenance of cross-certificates is potentially > a labor intensive activity. Agreed. > So, without creating any new nodes or > pseudo-nodes, one can express these trust relationships whenever it is > deemed necessary, e.g., whenever the parties in question do not have > adequate trust in superior nodes. Yes, though I don't think it is so useful in the long run (because the third party is not protected from the malicious superior nodes). Anyway, singer mechanism of ZSIG does not need any new nodes nor pseudo-nodes. > I think I understand your comments about about the association > between resolvers and name servers vs. zones. The E-K proposal does > assume, I believe, that a client (resolver) making a query is a client > of some zone, and thus can easily acquire (via local, integrity-secure > means) the public key of that zone. That key represents the operable > part of the up-certificate from that resolver to the zone, and thus is > the basis for starting an up-certification path. OK, so far. > I believe your point > is that if resolvers don't have such a close association to zones, but > rather to servers (which are not represented as secure entities in our > models), then the task of acquiring some zone key as a starting point > is no easier than acquiring the root key, maybe even harder. Also, if > a resolver does not have an affiliation with a zone, then the trust > arguments that motivate cross-certificates are not applicable, either. > Is this an accurate paraphrase of your concerns? No. What if a host running resolver is compromised? In my model, a resolver may trust local name servers, just as the resovler must trust the very local host on which it is running. My point is that, if there is no strong reason to change DNS architecture, it should be kept as is. > As for the final point, about root key changeover, remember > that the requirement here is to be able to distribute a new one to all > the resolvers. No. "to all the name servers". Resolvers today are not configured with information on root. So, I didn't change it. How resolvers securely know root keys is, in my model, a separate issue. > If the change is just a "preventative maintenance" > measure, then I agree that it can be effected in an orderly fashion > using the old key. There is a concern that a compromise of the root > key would make it very hard to distribute a new one, and so that > possibility is the one that the up-certificate approach tends to > address better than a pure top-down model. An interesting point. But, if root is compromized, keys for "com." and "edu." can be forged, and then, keys for all the organizations can be forged. Revoking them all is a lot harder than redistribution of a new root key, I think. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa14413; 8 Aug 94 10:30 EDT Received: from tsx-11.mit.edu(18.172.1.2) by relay via smap (V1.3) id sma014103; Mon Aug 8 10:21:42 1994 Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA09076; Mon, 8 Aug 94 10:20:59 EDT Date: Mon, 8 Aug 94 10:20:59 EDT From: Theodore Ts'o Message-Id: <9408081420.AA09076@tsx-11.MIT.EDU> To: Masataka Ohta Cc: kent@bbn.com, galvin@tis.com, dns-security@tis.com In-Reply-To: Masataka Ohta's message of Mon, 8 Aug 94 21:39:58 JST, <9408081240.AA27960@necom830.cc.titech.ac.jp> Subject: Re: draft DNS Security WG minutes Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 From: Masataka Ohta Date: Mon, 8 Aug 94 21:39:58 JST No. First of all, as I already wrote to you, precisely speaking, it's not cross-cirtification, at all. Yes, it's not cross-certification at all. It's manual key exchange by another name. > This doesn't work. Merely making one site be a secondary for another > doesn't change the fact that the zone key for bbn.com is still signed by > the com public key --- which may have been spoofed. In my draft, "making one site be a secondary" means configuring the site with zone's public key (or something like that), which does not need com public key to authenticate. Right. I think our key problem is one of terminology. You have been continually redefining words away from their original meaning. Most people understand secondary to mean what it means in the DNS/BIND context --- which is reasonable, since this is the DNS security working group, after all. A secondary name server has a very well definied meaning, as does making one site be a secondary for another. You have an entirely different concept in mind, which is making communications difference. I am reminded of a quotation on Alice in Wonderland --- "A word means what says it means, no more, no less." Which is fine, but which is not very useful when you are trying to communicate to us. So what you are proposing is a method of manual key exchange --- in a method that's even more cumbersome than PGP's friends and family method. In fact, it's identical to what Kerberos administrators need to do now when they want to exchange a cross-realm key --- they meet at a Chinese restaurant, and write down a shared key on the back of a fortune cookie. If we're going to all of the trouble to use a patented public-key cryptrography solution, we might as well get some more benefit out of it than that. Granted, you only have to do it in the case where you don't trust the root, but using the reverse and forward certificates, it's all handled automatically, without the need for a manual key exchange. You still don't understand that, in existing DNS architecture, neither resolver nor name server is bound to a zone. No, but a resolver will tend to trust one zone more than another. In the worse case, system administrator who is designing the resolver can decide that it trusts the root, in which case the resolver's private key can be used to sign the root public key, instead of the public key of some zone. In this model, the security risks are the same as in a pure top-down approach. However, the administrator of a resolver should be able to choose to trust one zone's security administratoion more than another --- and the forward/reverse certificates allow you to do that. - Ted   Received: from sol.tis.com by magellan.TIS.COM id aa14772; 8 Aug 94 10:59 EDT Received: from tsx-11.mit.edu(18.172.1.2) by relay via smap (V1.3) id sma014275; Mon Aug 8 10:32:05 1994 Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA09248; Mon, 8 Aug 94 10:31:39 EDT Date: Mon, 8 Aug 94 10:31:39 EDT From: Theodore Ts'o Message-Id: <9408081431.AA09248@tsx-11.MIT.EDU> To: tytso@mit.edu Cc: Masataka Ohta , kent@bbn.com, galvin@tis.com, dns-security@tis.com In-Reply-To: Theodore Ts'o's message of Mon, 8 Aug 94 10:20:59 EDT, <9408081420.AA09076@tsx-11.MIT.EDU> Subject: Re: draft DNS Security WG minutes Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Date: Mon, 8 Aug 94 10:20:59 EDT From: tytso@MIT.EDU (Theodore Ts'o) So what you are proposing is a method of manual key exchange --- in a method that's even more cumbersome than PGP's friends and family method. In fact, it's identical to what Kerberos administrators need to do now when they want to exchange a cross-realm key --- they meet at a Chinese restaurant, and write down a shared key on the back of a fortune cookie. Upon reviewing my words, I realized I spoke too quickly. What Ohta-San is suggesting is not precisely identical to manual key exchange --- you don't actually have to exchange keys. However, it still requires a manual certification of the zone's public key by the zone administrators. Hence, it requires the zone administrators either phyiscally meeting to verify the public key, or some other out of band method secured by public key (using PGP, perhaps) to establish the bona fides of the public key. In this way, it's identical to the requirement of Kerberos cross-authentication problem. The realm administrators either need to meet in person, or use PGP-authenticated and encrypted path to establish the shared session key. (The difference is that in Ohta-san's proposal, it doesn't need to be encrypted, although it still needs to be authenticated out of band.) Like the Kerberos cross-realm authentication, Ohta-san's proposal is an N**2 proposition, where as the reverse and forward certificates are an order N proposition. Finally, since the zone key is not actually signed, but merely configured on the "secondary", it's subject to modification and spoofing at a later date. - Ted   Received: from sol.tis.com by magellan.TIS.COM id aa15241; 8 Aug 94 12:00 EDT Received: from tsx-11.mit.edu(18.172.1.2) by relay via smap (V1.3) id sma015322; Mon Aug 8 11:35:46 1994 Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA10233; Mon, 8 Aug 94 11:34:58 EDT Date: Mon, 8 Aug 94 11:34:58 EDT From: Theodore Ts'o Message-Id: <9408081534.AA10233@tsx-11.MIT.EDU> To: Masataka Ohta Cc: kent@bbn.com, galvin@tis.com, dns-security@tis.com In-Reply-To: Masataka Ohta's message of Mon, 8 Aug 94 23:46:39 JST, <9408081446.AA01004@necom830.cc.titech.ac.jp> Subject: Re: draft DNS Security WG minutes Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 From: Masataka Ohta Date: Mon, 8 Aug 94 23:46:39 JST > No. First of all, as I already wrote to you, precisely speaking, it's > not cross-cirtification, at all. > > Yes, it's not cross-certification at all. It's manual key exchange by > another name. Without the forwarder mechanism I mentioned but you have failed to notice, yes. Great. I wish you had admitted this up-front, though. My apologies for my previous outburst, by the way; I let my frustration at your terminology (war is peace, freedom is slavery, cross-certification is manual key exchange) get the better of me. > You still don't understand that, in existing DNS architecture, neither > resolver nor name server is bound to a zone. > > No, but a resolver will tend to trust one zone more than another. A resolver, currently, tends to trust one name server, not one zone, more than another. Yes, but a nameserver isn't guaranteed to have a key (part of the design is that dns records could be signed off-line, so that a name server didn't need to have any trusted information on-line). Hence, you can't trust a name server without doing authentication by IP address. You can, however, trust a zone, since a zone which is playing the secure DNS game is guaranteed to have a key. > In > the worse case, system administrator who is designing the resolver can > decide that it trusts the root, in which case the resolver's private key > can be used to sign the root public key, instead of the public key of > some zone. Are you suggesting any change, or stating your view on the current resolver? I'm not suggesting any change. What I'm suggesting can be done now under the current E-K model. The question which zone a resolver "belongs" to is merely a question of which key does that resolver ultimately trust. If the resolver wants to ultimately trust the root, it can do so. If the resolver wants to trust, say, MIT or BBN, it can do so too. All it needs is to have the ability to get that one single key securely out of band, and sign it. Then, it can use the reverse and forward certificates (and cross-certificates, if they exist) to get from where it is to anywhere else in the tree. - Ted   Received: from sol.tis.com by magellan.TIS.COM id aa13103; 8 Aug 94 8:59 EDT Received: from necom830.cc.titech.ac.jp(131.112.32.132) by relay via smap (V1.3) id sma013206; Mon Aug 8 08:48:52 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 8 Aug 94 21:40:00 +0900 From: Masataka Ohta Return-Path: Message-Id: <9408081240.AA27960@necom830.cc.titech.ac.jp> Subject: Re: draft DNS Security WG minutes To: Theodore Ts'o Date: Mon, 8 Aug 94 21:39:58 JST Cc: kent@bbn.com, galvin@tis.com, dns-security@tis.com In-Reply-To: <9408081137.AA07338@tsx-11.MIT.EDU>; from "Theodore Ts'o" at Aug 8, 94 7:37 am X-Mailer: ELM [version 2.3 PL11] > > Are you assuming > > authentication by IP address, ala rlogin? > > No. Resolvers retrieve authenticated data through authenticated > communication between SBELT or co-located name servers. > > Your claim is that you can deal with the cross-certification issue by > merely making one site (titech.ac.jp) be a secondary for another > (bbn.com). No. First of all, as I already wrote to you, precisely speaking, it's not cross-cirtification, at all. > This doesn't work. Merely making one site be a secondary for another > doesn't change the fact that the zone key for bbn.com is still signed by > the com public key --- which may have been spoofed. In my draft, "making one site be a secondary" means configuring the site with zone's public key (or something like that), which does not need com public key to authenticate. > There is no > authenticated communication between the resolver and the nameserver; There is. But I don't mind if you insists on using authentication by IP address. Your security is your problem. > the > nameserver only hands back signed records, and changing where you get > the information by having the resolver talk to a secondary does not > change who has signed the records. So what? > Hence, your suggested solution of making titech.ac.jp be a secondary for > bbn.com has no cryptographic significance, and is rather pointless. I never suggested such a thing. "titech.ac.jp" is a zone. "a secodary" is a name server. "a zone" != "a name server". Thus, it is completely pointless to say "making titech.ac.jp be a secondary". > If you are suggesting a solution where you have authenticated > communication between the resolver and the name server, recall that this > requires that the zone private key (or at least some other private > key) must be on-line on the name server. This is considered a Bad > Thing, for the obvious security reasons. You still don't understand that, in existing DNS architecture, neither resolver nor name server is bound to a zone. As a name server is bound to a host. Thus, the host's private key, whose correcponding public key can not be distributed by secure DNS and will be configured statically, will be used of course. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa14729; 8 Aug 94 10:54 EDT Received: from necom830.cc.titech.ac.jp(131.112.32.132) by relay via smap (V1.3) id sma014602; Mon Aug 8 10:54:42 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 8 Aug 94 23:46:42 +0900 From: Masataka Ohta Return-Path: Message-Id: <9408081446.AA01004@necom830.cc.titech.ac.jp> Subject: Re: draft DNS Security WG minutes To: Theodore Ts'o Date: Mon, 8 Aug 94 23:46:39 JST Cc: kent@bbn.com, galvin@tis.com, dns-security@tis.com In-Reply-To: <9408081420.AA09076@tsx-11.MIT.EDU>; from "Theodore Ts'o" at Aug 8, 94 10:20 am X-Mailer: ELM [version 2.3 PL11] > No. First of all, as I already wrote to you, precisely speaking, it's > not cross-cirtification, at all. > > Yes, it's not cross-certification at all. It's manual key exchange by > another name. Without the forwarder mechanism I mentioned but you have failed to notice, yes. > You still don't understand that, in existing DNS architecture, neither > resolver nor name server is bound to a zone. > > No, but a resolver will tend to trust one zone more than another. A resolver, currently, tends to trust one name server, not one zone, more than another. > In > the worse case, system administrator who is designing the resolver can > decide that it trusts the root, in which case the resolver's private key > can be used to sign the root public key, instead of the public key of > some zone. Are you suggesting any change, or stating your view on the current resolver? > In this model, the security risks are the same as in a pure > top-down approach. However, the administrator of a resolver should be > able to choose to trust one zone's security administratoion more than > another --- and the forward/reverse certificates allow you to do that. The problem is whether such a change is necessary or not. I'm still unconvinced. But, I'm tired. I think I had better write a separate draft (about optional behaviour of resolvers) on how easily your requirement can be filfulled without changing the existing draft than spending time on ML discussion. Then, let someone else choose. Deal? Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa17944; 9 Aug 94 8:33 EDT Received: from zephyr.isi.edu(128.9.160.160) by relay via smap (V1.3) id sma023837; Tue Aug 9 08:33:59 1994 Received: by zephyr.isi.edu (5.65c/5.61+local-16) id ; Tue, 9 Aug 1994 05:32:30 -0700 From: Bill Manning Message-Id: <199408091232.AA22981@zephyr.isi.edu> Subject: Re: draft DNS Security WG minutes To: Masataka Ohta Date: Tue, 9 Aug 1994 05:32:30 -0700 (PDT) Cc: tytso@athena.mit.edu, kent@bbn.com, galvin@tis.com, dns-security@tis.com In-Reply-To: <9408090540.AA00689@necom830.cc.titech.ac.jp> from "Masataka Ohta" at Aug 9, 94 02:40:25 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1052 > > What I'm suggesting can be done now > > under the current E-K model. > > E-K model suggests too much unnecessary changes to the current DNS > architectture, which is, IMHO, fatal defect of the model. > > Thus, based on the same framework supported by WG consensus, I developped > a simpler model. > > Masataka Ohta > I feel I must interject here. There were a large number of concerns raised in the WG about your top-down approch. This does not indicate to me that the WG has reached a consensus based on your design, which is what I read in the statement above. Also, I do feel that there is a large contigent (including most of the existing developers and designers) that beleive that it will take a change in the DNS structure to support a good security model. This (dnssec) is one of the items driving the development of DNSv2. Attempts to provide security in the current model don't seem to meet the desired needs of the community, even though there are some clever ways to make the attempt. (Such as your model). -- bill   Received: from sol.tis.com by magellan.TIS.COM id aa17487; 9 Aug 94 1:47 EDT Received: from necom830.cc.titech.ac.jp(131.112.32.132) by relay via smap (V1.3) id sma022522; Tue Aug 9 01:48:04 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 9 Aug 94 14:40:26 +0900 From: Masataka Ohta Return-Path: Message-Id: <9408090540.AA00689@necom830.cc.titech.ac.jp> Subject: Re: draft DNS Security WG minutes To: Theodore Ts'o Date: Tue, 9 Aug 94 14:40:25 JST Cc: kent@bbn.com, galvin@tis.com, dns-security@tis.com In-Reply-To: <9408081534.AA10233@tsx-11.MIT.EDU>; from "Theodore Ts'o" at Aug 8, 94 11:34 am X-Mailer: ELM [version 2.3 PL11] > > Yes, it's not cross-certification at all. It's manual key exchange by > > another name. > > Without the forwarder mechanism I mentioned but you have failed to > notice, yes. > > Great. I wish you had admitted this up-front, though. My apologies for > my previous outburst, by the way; I let my frustration at your > terminology (war is peace, freedom is slavery, cross-certification is > manual key exchange) get the better of me. Your frustration is your problem of having complete illusion on the exsiting DNS. > A resolver, currently, tends to trust one name server, not one zone, > more than another. > > Yes, but a nameserver isn't guaranteed to have a key (part of the design > is that dns records could be signed off-line, so that a name server > didn't need to have any trusted information on-line). Hence, you can't > trust a name server without doing authentication by IP address. My draft explicitely requires the communication between resolvers and SBELT name servers secure. Read it. > You > can, however, trust a zone, since a zone which is playing the secure DNS > game is guaranteed to have a key. In the current DNS, zones are not required to have keys. > Are you suggesting any change, or stating your view on the current > resolver? > > I'm not suggesting any change. You are suggesting a lot of changes. You just don't know how the current DNS is. > What I'm suggesting can be done now > under the current E-K model. E-K model suggests too much unnecessary changes to the current DNS architectture, which is, IMHO, fatal defect of the model. Thus, based on the same framework supported by WG consensus, I developped a simpler model. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa18852; 9 Aug 94 11:44 EDT Received: from tsx-11.mit.edu(18.172.1.2) by relay via smap (V1.3) id sma025931; Tue Aug 9 11:44:47 1994 Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA09198; Tue, 9 Aug 94 11:44:13 EDT Date: Tue, 9 Aug 94 11:44:13 EDT From: Theodore Ts'o Message-Id: <9408091544.AA09198@tsx-11.MIT.EDU> To: Masataka Ohta Cc: kent@bbn.com, galvin@tis.com, dns-security@tis.com In-Reply-To: Masataka Ohta's message of Tue, 9 Aug 94 14:40:25 JST, <9408090540.AA00689@necom830.cc.titech.ac.jp> Subject: Re: draft DNS Security WG minutes Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 From: Masataka Ohta Date: Tue, 9 Aug 94 14:40:25 JST > You > can, however, trust a zone, since a zone which is playing the secure DNS > game is guaranteed to have a key. In the current DNS, zones are not required to have keys. Ah, but if you're doing secure DNS, zones will have keys. Is this a change? Yes. Can you do secure DNS cleanly without requiring that zones have keys? No. > Are you suggesting any change, or stating your view on the current > resolver? > > I'm not suggesting any change. You are suggesting a lot of changes. You just don't know how the current DNS is. We are all suggesting changes to implement secure DNS. That is what this working group is all about. The question is how many changes we need to make. What I was trying to say was that what I was suggesting did not require any changes to the current E-K model. As for whether I know how the current DNS works, is not worth debating on this list. Having rumaged around within the source code of BIND, and done a lot of the work dealing with the MIT nameservers, I would beg to differ, but that's outside the scope of this list. > What I'm suggesting can be done now > under the current E-K model. E-K model suggests too much unnecessary changes to the current DNS architectture, which is, IMHO, fatal defect of the model. Thus, based on the same framework supported by WG consensus, I developped a simpler model. I disagree; and I disagree that you have any consensus supporting your ideas. - Ted   Received: from sol.tis.com by magellan.TIS.COM id aa19539; 9 Aug 94 16:16 EDT Message-Id: <9408092017.AA02040@relay.tis.com> Received: from labs-n.bbn.com(128.89.0.100) by relay via smap (V1.3) id sma002038; Tue Aug 9 16:17:05 1994 To: Theodore Ts'o Cc: dns-security@tis.com Subject: Re: draft DNS Security WG minutes In-Reply-To: Your message of Tue, 09 Aug 94 11:44:13 -0400. <9408091544.AA09198@tsx-11.MIT.EDU> Date: Tue, 09 Aug 94 16:14:12 -0400 From: Steve Kent Ted, Ohta's proposal has many elements, and I agree with you that a combination of up, down and cross-certificates (with well-defined validation rules) is probably going to be more palatable to the WG overall than a top-down only scheme. However, I endorse the simplier, more algorithm independent signature record approach of Ohta's proposal and I don't think we should "throw the baby out with the certification hierarchy," to coin a new phrase. Steve   Received: from sol.tis.com by magellan.TIS.COM id aa20703; 10 Aug 94 4:36 EDT Received: from gw.home.vix.com(192.5.5.1) by relay via smap (V1.3) id sma008981; Wed Aug 10 04:37:14 1994 Received: by gw.home.vix.com id AA02609; Wed, 10 Aug 94 01:36:49 -0700 Date: Wed, 10 Aug 94 01:36:49 -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: draft DNS Security WG minutes Organization: Vixie Enterprises Message-Id: References: <199408091232.AA22981@zephyr.isi.edu> Nntp-Posting-Host: office.home.vix.com In-Reply-To: bmanning@isi.edu's message of 9 Aug 1994 06:40:36 -0700 >This (dnssec) is one of the items driving the development of DNSv2. That's true. >Attempts to provide security in the current model don't seem to meet the >desired needs of the community, even though there are some clever ways to >make the attempt. (Such as your model). That's not as obviously true, and maybe not true at all. I expect V2 to make things work _better_ but noone has asked for anything in V2 that will _only_ be used to enable security. I've offered a plan by which the most restrictive aspects of V1 (lack of MBZ header bits, limited packet size) can be worked around while V2 proceeds somewhat independently. If you folks are going to hinge DNSSEC on the existence of DNS V2, I need to reshape my priorities. Let me know :-}... -- Paul Vixie Redwood City, CA decwrl!vixie!paul   Received: from sol.tis.com by magellan.TIS.COM id aa20833; 10 Aug 94 7:03 EDT Received: from necom830.cc.titech.ac.jp(131.112.32.132) by relay via smap (V1.3) id sma009961; Wed Aug 10 07:03:33 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 10 Aug 94 16:53:25 +0900 From: Masataka Ohta Return-Path: Message-Id: <9408100753.AA06560@necom830.cc.titech.ac.jp> Subject: Re: draft DNS Security WG minutes To: Bill Manning Date: Wed, 10 Aug 94 16:53:24 JST Cc: tytso@athena.mit.edu, kent@bbn.com, galvin@tis.com, dns-security@tis.com In-Reply-To: <199408091232.AA22981@zephyr.isi.edu>; from "Bill Manning" at Aug 9, 94 5:32 am X-Mailer: ELM [version 2.3 PL11] > > E-K model suggests too much unnecessary changes to the current DNS > > architectture, which is, IMHO, fatal defect of the model. > > > > Thus, based on the same framework supported by WG consensus, I developped > > a simpler model. > > > > Masataka Ohta > > > > I feel I must interject here. There were a large number of > concerns raised in the WG about your top-down approch. This > does not indicate to me that the WG has reached a consensus > based on your design, which is what I read in the statement > above. "the same framework supported by WG consensus" means minimum granularity and zone, not host, based keying. That's all I assumed. I avoided to assume even the public key cryptography. E-K model assumed a lot more than that in a way hostile to the current DNS architecture. Moreover, X-authentication of E-K model is not yet stated precisely and, thus, not yet a proposal. > Also, I do feel that there is a large contigent (including Please don't just "feel" but try to exlain engneering reason. > most of the existing developers and designers) that beleive > that it will take a change in the DNS structure to support > a good security model. And one counter example is enough to disprove it. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa20869; 10 Aug 94 7:29 EDT Received: from necom830.cc.titech.ac.jp(131.112.32.132) by relay via smap (V1.3) id sma009968; Wed Aug 10 07:03:51 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 10 Aug 94 16:57:28 +0900 From: Masataka Ohta Return-Path: Message-Id: <9408100757.AA06575@necom830.cc.titech.ac.jp> Subject: Re: draft DNS Security WG minutes To: Steve Kent Date: Wed, 10 Aug 94 16:57:27 JST Cc: tytso@athena.mit.edu, dns-security@tis.com In-Reply-To: <9408092017.AA02040@relay.tis.com>; from "Steve Kent" at Aug 9, 94 4:14 pm X-Mailer: ELM [version 2.3 PL11] > Ted, > > Ohta's proposal has many elements, and I agree with you that a > combination of up, down and cross-certificates (with well-defined > validation rules) is probably going to be more palatable to the WG > overall than a top-down only scheme. I don't think adding combination of up, down and cross-certificates is so difficult nor complex. But as it changes some fundamental assumptions of DNS, I'd like to be conservative and wanted to know the reason to add it. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa22037; 21 Nov 94 2:56 EST Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3) id sma015139; Mon Nov 21 02:56:14 1994 Received: from skidrow.tay.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA10228; Sun, 20 Nov 94 23:51:26 -0800 Received: by skidrow.tay.dec.com (5.65/MS-081993); id AA25638; Mon, 21 Nov 1994 02:55:52 -0500 Message-Id: <9411210755.AA25638@skidrow.tay.dec.com> To: Internet Drafts Cc: dee@skidrow.tay.dec.com, dns-security@tis.com Subject: draft-ietf-dnssec-as-map-01.txt Date: Mon, 21 Nov 94 02:55:51 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp I am hereby submitting the following internet draft: --------------------------------------------------------------------------- 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) INTERNET-DRAFT Mapping A.S. Number into the DNS 19 November 1994 Expires 20 May 1995 Mapping Autonomous Systems Number into the Domain Name System ------- ---------- ------- ------ ---- --- ------ ---- ------ Donald E. Eastlake 3rd Status of This Document This draft, file name draft-ietf-dnssec-as-map-01.txt, is intended to be become a standards track RFC concerning DNS and routing security. Distribution of this document is unlimited. Comments should be sent to the DNS Security Working Group mailing list [is there also a router [WG?] mailing list is should be sent to?] or to the author. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. Donald E. Eastlake 3rd [Page 1] INTERNET-DRAFT Mapping A.S. Numbers into the DNS Abstract One requirement of secure routing is that independent routing entities, such as those identified by Internet Autonomous System Numbers, be able to authenticate messages to each other. Modifications currently being developed (see other draft-ietf- dnssec-*.txt) to the Domain Name System will enable it to be used for convenient public key distribution. This draft maps all Autonomous System numbers into DNS Domain Names so that the DNS can be used to distribute their public keys. Acknowledgements The contributions of the following persons to this draft are gratefully acknowledged: Ran Atkinson, Michale A. Patton Donald E. Eastlake 3rd [Page 2] INTERNET-DRAFT Mapping A.S. Numbers into the DNS Table of Contents Status of This Document....................................1 Abstract...................................................2 Acknowledgements...........................................2 Table of Contents..........................................3 1. Introduction............................................4 2. Autonomous System Number Mapping........................5 3. Meaning of RRs..........................................6 4. Security Considerations.................................7 References.................................................7 Author's Address...........................................8 Expiration and File Name...................................8 Donald E. Eastlake 3rd [Page 3] INTERNET-DRAFT Mapping A.S. Numbers into the DNS 1. Introduction There are a number of elements that will be required to secure routing in the Internet. One of these is a way that independently operated top level routing domains be able to authenticate messages to each other. Sharing a private symmetric key between each pair of such domains is impractical. The Automonous System numbering scheme provides for 2**16 such domains which implies approximately 2**31 pairs, an impractical number of keys to securely generate, install, and periodically replace. The solution is to use public key technology whereby each domain has a private key it can use to sign messages. Other domains that know the corresponding public key can then authenticate these messages. Such authenticated messages can be used to set up and replace efficient symmetric keys on an as needed basis. But how do the domains securely obtain the Autonomous System number to public key mapping? Extensions currently being developed for the Domain Name System will enable it to be conveniently used for authenticated public key distribution (see other draft-ietf-dnssec-*.txt). All that is required is a mapping of Autonomous System numbers into domain names, which is provided by this draft. It should be noted that the public keys retrieved from DNS will likely be used mostly to authenticate only initial set up messages. Autonomous Systems that need to converse with any frequency will probably negotiate more efficient session keys. Donald E. Eastlake 3rd [Page 4] INTERNET-DRAFT Mapping A.S. Numbers into the DNS 2. Autonomous System Number Mapping Autonomous System (A.S.) numbers are 16 bit quantities. The A.S. number is mapped into a domain name as follows: (1) write the A.S. as a four digit hex number (with leading zeros if necessary), (2) reverse these digits and separated them with dots, and (3) append ".in-as.arpa" to them. Thus the domain name correspond to Autonomos System 69, which is 0045 hex, is 5.4.0.0.in-as.arpa. All of *.in-as.arpa could be handled as one zone or parts of it carved out as subzones as administrative convenience dictates. [I choose .arpa as that seems to follow the in-addr model and A.S. numbers originated in the IPv4 world.] Donald E. Eastlake 3rd [Page 5] INTERNET-DRAFT Mapping A.S. Numbers into the DNS 3. Meaning of RRs There are no enforceable restrictions on what resource records can be stored under *.in-as.arpa names; however, the following guidance is given for some RR types (the KEY RR is given first, then the rest in alphabetic order). KEY: This type of resource record associates a public key with the Autonomous System (A.S.) designated by its name. Such a public key can be used to authenticate communications with or between A.S.s. The existence of KEY RRs in the reason for mapping A.S. names into the DNS. Under DNS security as proposed in draft-ietf-dnssec- secext-*.txt the KEY RR can be used to store any type of digital key. A: DO NOT place type A RRs at A.S. nodes. A.S. domain names are reserved for Autonomous Systems only and should NEVER be used for a host or any type of end entity other than an Autonomous System. CNAME: This type of RR is an alias pointing to another domain name. An A.S. could have a CNAME pointing to a different A.S. but this is not likely to be very useful as A.S. RRs will normally be looked up when the A.S. number is actually encountered in use. MX: There is no designated use for an MX RR for an A.S. name. It could point to a host that would accept mail related to that A.S. NS: The presence of NS records under an in-as.arpa name means that it has been carved out as a subzone. This gives the A.S. complete control over the zone refresh parameters and control over the creation of inferior names. No special meaning is currently assigned to such inferior names so, although this is not advised, they could be used for hosts or whatever. PTR: The part of the forward domain tree that administratively corresponds to the A.S. should be indicated by a PTR RR. It some entity, say example.net, has several A.S.s, there would be PTRs to example.net from several names in the in-as.arpa hierarchy. RP: A Responsible Person RR should appear under each A.S. name telling you who you should contact in the case of problems with that A.S. TXT: Text RRs can be used for comments, postal address, or similar notes under an A.S. name. Donald E. Eastlake 3rd [Page 6] INTERNET-DRAFT Mapping A.S. Numbers into the DNS 4. Security Considerations The entirety of this document concerns a means to map Internet Autonomous System numbers into the Domain Name System (DNS) so that secure DNS can be used to provide secure distribution of Autonomous System's public keys. References [RFC904] - Exterior Gateway Protocol Formal Specification, D. L. Mills [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris, November 1987 [RFC1035] - Domain Names - Implementation and Specifications, P. Mockapetris Donald E. Eastlake 3rd [Page 7] INTERNET-DRAFT Mapping A.S. Numbers into the DNS Author's Address Donald E. Eastlake 3rd Digital Equipment Corporation 550 King Street, LKG2-1/BB3 Littleton, MA 01460 Telephone: +1 508 486 6577(w) +1 508 287 4877(h) EMail: dee@lkg.dec.com Expiration and File Name This draft expires 20 May 1995 Its file name is draft-ietf-dnssec-as-map-01.txt. Donald E. Eastlake 3rd [Page 8]   Received: from sol.tis.com by magellan.TIS.COM id aa22074; 21 Nov 94 3:00 EST Received: from inet-gw-3.pa.dec.com(16.1.0.33) by relay via smap (V1.3) id sma015178; Mon Nov 21 03:01:00 1994 Received: from skidrow.tay.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA28423; Sun, 20 Nov 94 23:55:20 -0800 Received: by skidrow.tay.dec.com (5.65/MS-081993); id AA25744; Mon, 21 Nov 1994 02:59:35 -0500 Message-Id: <9411210759.AA25744@skidrow.tay.dec.com> To: Internet Drafts Cc: dns-security@tis.com, dee@skidrow.tay.dec.com, Charlie Kaufman Subject: draft-ietf-dnssec-secext-02.txt Date: Mon, 21 Nov 94 02:59:35 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp I am hereby submitting the following internet draft: --------------------------------------------------------------------------- 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) INTERNET-DRAFT DNS Protocol Security Extensions 20 November 1994 Expires 19 May 1995 Domain Name System Protocol Security Extensions ------ ---- ------ -------- -------- ---------- Donald E. Eastlake 3rd & Charles W. Kaufman Status of This Document This draft, file name draft-ietf-dnssec-secext-02.txt, is intended to be become a standards track RFC. Distribution of this document is unlimited. Comments should be sent to the DNS Security Working Group mailing list or to the authors. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 1] INTERNET-DRAFT DNS Protocol Security Extensions Abstract The Domain Name System (DNS) has become a critical operational part of the Internet infrastructure yet it has no strong security mechanisms to assure data integrity or authentication. Extensions to the DNS are described in detail that provide these services to security aware resolvers or applications through the use of cryptographic digital signatures. These digital signatures are included in secured zones as resource records. Security can still be provided even through non-security aware DNS servers. A explanatory overview of the proposed extensions appears in draft- ietf-dnssec-over-*.txt. The extensions also provide for the storage of authenticated keys in the DNS for DNS use and to support a general public key distribution service. The stored keys enable security aware resolvers to learn the authenticating key of zones in addition to keys for which they are initially configured. Keys associated with DNS names can be retrieved to support other protocols. Provision is made for a variety of key types and algorithms. In addition, the security extensions provide for the optional authentication of DNS protocol transactions. Acknowledgements The significant contributions of the following persons (in alphabetic order) to this draft are gratefully acknowledged: Madelyn Badger, James M. Galvin, Olafur Gudmundsson, Sandy Murphy, Masataka Ohta, Jeffrey I. Schiller. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 2] INTERNET-DRAFT DNS Protocol Security Extensions Table of Contents Status of This Document....................................1 Abstract...................................................2 Acknowledgements...........................................2 Table of Contents..........................................3 1. Introduction............................................5 2. Brief Overview of the Extensions.......................6 2.1 Key Distribution.......................................6 2.2 Data Origin Authentication.............................6 2.2.1 Security Provided...................................6 2.2.2 The SIG Resource Record..............................7 2.2.3 The NXD Resource Record..............................7 2.2.4 Signers Other Than The Zone..........................8 2.2.5 Special Problems With Time-to-Live...................8 2.3 DNS Transaction Authentication.........................8 3. The KEY Resource Record................................10 3.1 KEY RDATA format......................................10 3.2 Object Types and DNS Names and Keys...................11 3.3 The KEY RR Flag Octet.................................11 3.4 The KEY Algorithm Version.............................12 3.5 KEY RRs in the Construction of Responses..............13 3.6 File Representation of KEY RRs........................13 4. The SIG Resource Record................................15 4.1 SIG RDATA Format......................................15 4.1.1 Signature Format....................................17 4.1.2 SIG RRs Covering Type ANY...........................18 4.1.3 Zone Transfer (AXFR) SIG............................18 4.1.4 Transaction SIGs....................................18 4.2 SIG RRs in the Construction of Responses..............19 4.3 Processing Responses with SIG RRs.....................19 4.4 File Representation of SIG RRs........................20 5. Non-existent Names.....................................22 5.1 The NXD Resource Record...............................22 5.2 NXD RDATA Format......................................23 5.3 Example...............................................23 5.4 Interaction of NXD RRs and Wildcard RRs...............23 5.5 Blocking NXD Pseudo-Zone Transfers....................24 6. How to Resolve Securely................................25 6.1 Boot File Format......................................25 6.2 Chaining Through Zones................................26 6.3 Secure Time...........................................27 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 3] INTERNET-DRAFT DNS Protocol Security Extensions 7. Operational Considerations.............................28 7.1 Key Size Considerations...............................28 7.2 Key Storage...........................................28 7.3 Key Generation........................................29 7.4 Key Lifetimes.........................................29 7.5 Revocation............................................29 7.6 Root..................................................30 8. Conformance............................................31 8.1 Server Conformance....................................31 8.2 Resolver Conformance..................................31 9. Security Considerations................................32 References................................................32 Authors Addresses.........................................33 Expiration and File Name..................................33 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 4] INTERNET-DRAFT DNS Protocol Security Extensions 1. Introduction This draft provides detailed descriptions of the DNS protocol extensions to support DNS security and public key distribution. A broad overview of these extensions is provided in draft-ietf- dnssec-over-*.txt. This draft assumes that the reader is familiar with that overview and with the Domain Name System particularly as described in RFCs 1034 and 1035. The requirements and goals of DNS security are described in the overview document. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 5] INTERNET-DRAFT DNS Protocol Security Extensions 2. Brief Overview of the Extensions The DNS protocol extensions provide three distinct services: key distribution as described in section 2.1 below, data origin authentication as described in section 2.2 below, and transaction authentication, described in section 2.3 below. 2.1 Key Distribution The resource records are defined to associate keys with DNS names. This permits the DNS to be used as a general public key distribution mechanism in support of the data origin authentication and transaction authentication DNS services as well as other security services such as IP level security. The syntax of a KEY resource record is described in Section 3. It includes the name of the entity the key is associated with (frequently but not always the KEY RR owner name), an algorithm identifier, flags indicating the type of entity the key is associated with or asserting that there is no key associated with that entity, and the actual public key parameters. 2.2 Data Origin Authentication Adding security requires no change to the "on-the-wire" DNS protocol beyond the addition of the signature resource types (and, as a practical matter, the key resource type needed for key distribution). An additional domain name non-existence resource is added to extend authentication to negative responses. This service can be supported by existing resolver and server implementations so long as they could support the additional resource types. If signatures are always separately retrieved and verified when retrieving the information they authenticate, there will be more trips to the server and performance will suffer. To avoid this, security aware servers mitigate that degradation by automatically send exactly the signature(s) needed. 2.2.1 Security Provided Security is provided by associating with resource records in the DNS a cryptographically generated digital signature. Commonly, there will be a single private key that signs for an entire zone. If a security aware resolver reliably learns the public key of the zone, Donald E. Eastlake 3rd & Charles W. Kaufman [Page 6] INTERNET-DRAFT DNS Protocol Security Extensions it can verify that all the data read was properly authorized and is reasonably current. The expected implementation is for the zone private key to be kept off-line and used to re-sign all of the records in the zone periodically. The data origin authentication key belongs to the zone and not to the servers that store copies of the data. That means compromise of a server or even all servers for a zone will not affect the degree of assurance that a resolver has that the data is genuine. A resolver can learn the public key of a zone either by reading it from DNS or by having it staticly configured. To reliably learn the public key by reading it from DNS, the key itself must be signed. Thus, to provide a reasonable degree of security, the resolver must be configured with at least the public key of one zone. From that, it can securely read the public keys of other zones if the intervening zones in the DNS tree are secure. It is in principle more secure to have the resolver manually configured with the public keys of multiple zones, since then the compromise of a single zone would not permit the faking of information from other zones. It is also more administratively cumbersome, however, particularly when public keys change. 2.2.2 The SIG Resource Record The syntax of a SIG resource record (signature) is described in Section 4. It includes the type of the RR(s) being signed, the name of the signer, the time at which the signature was created, the time it expires (when it is no longer to be believed), its original time to live (which may be longer than its current time to live but cannot be shorter), the cryptographic algorithm in use, and the actual signature. Every name in a zone supporting signed data will have associated with it a SIG resource records for each resource type under that name. A security aware server supporting the performance enhanced version of the DNS protocol security extensions will return with all records retrieved the corresponding SIGs. If a server does not support the protocol, the resolver must retrieve all the SIG records for a name and select the one or ones that sign the resource record(s) that resolver is interested in. 2.2.3 The NXD Resource Record The above security mechanism provides only a way to sign existing RRs in a zone. Data origin authentication is not obviously provided for Donald E. Eastlake 3rd & Charles W. Kaufman [Page 7] INTERNET-DRAFT DNS Protocol Security Extensions the non-existence of a domain name in a zone. This gap is filled by the NXD RR which authenticatably asserts a range of non-existent names in a zone. The owner of the NXD RR is the start of such a ranger and its RDATA is the end of the range; however, there are additional complexities due to wildcards. Section 6 below covers the NXD RR. 2.2.4 Signers Other Than The Zone There are two general cases where a signature is generated by other than the zone private key. One is for future support of dynamic update where an entity is permitted to authenticate/update its own record. The public key of the entity must be present in the DNS and be appropriately signed but the other RR(s) may be signed with the entity's key. The other is for support of transaction authentication as described in 2.3 below. 2.2.5 Special Problems With Time-to-Live A digital signature will fail to verify if any change has occurred to the data between the time it was originally signed and the time the signature is verified. This conflicts with our desire to have the time-to-live field tick down when resource records are cached. This could be avoided by leaving the time-to-live out of the digital signature, but that would allow unscrupulous secondaries to set arbitrarily long time to live values undetected. Instead, we include the "original" time-to-live in the signature and communicate that data in addition to the current time-to-live. Unscrupulous servers under this scheme can manipulate the time to live but a security aware resolver will bound the TTL value it uses at the original signed value. Separately, signatures include a time signed and an expiration time. A resolver that knows an absolute time can determine securely whether a signature has expired. 2.3 DNS Transaction Authentication The data origin authentication service described above protects resource records but provides no protection for message headers. If header bits are falsely set by a server, there is little that can be done. However, it is possible to add transaction authentication. Such authentication means that a resolver can be sure it is getting messages from the server it thinks it queried and that the response is from the query it sent and that these messages have not been Donald E. Eastlake 3rd & Charles W. Kaufman [Page 8] INTERNET-DRAFT DNS Protocol Security Extensions diddled in transit. This is accomplished by optionally adding a special SIG resource record to end of the reply which digitally signs the concatenation of the server's response and the resolver's query. The private key used belongs to the host composing the reply, not to the zone being queried. The corresponding public key is stored in and retrieved from the DNS. Because replies are highly variable, message authentication SIGs can not be precalculated. Thus it will be necessary to keep the private key on-line, for example in software or in a directly connected piece of hardware. The best way to get the security provided by the transaction authentication service would be to use a good IP level security protocol. The authors of this draft decry the every growing number of IP application level security protocols such as Telnet, NTP, FTP, etc., etc. when a single IP-security protocol could secure most of these applications. Unfortunately, an IP-security standard has not yet been adopted. And even if it had, there will be many systems for many years where it will be hard to add IP security but relatively easy to replace the DNS components. Furthermore, the data origin authentication service requires the implementation of essentially all the mechanisms needed for a rudimentary message authentication service. Thus a simple transaction authentication service based on mechanisms already required by DNS security is included as a strictly optional part of these extensions. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 9] INTERNET-DRAFT DNS Protocol Security Extensions 3. The KEY Resource Record The KEY RR is used to document a key that is associated with a DNS name. It will be a public key as only public keys are stored in the DNS. This can be the public key of a zone owner, of a host or other end entity, or a user. A KEY RR is, like any other RR, authenticated by a SIG RR. Security aware DNS implementations should be designed to handle at least two simultaneously valid keys of the same type associated with a name. The type number for the KEY RR is 25. 3.1 KEY RDATA format The RDATA for a KEY RR consists of an object name, flags, the algorithm version, and the public key itself. For the MD5/RSA algorithm, that is the public exponent and the public modulus. The format is as follows: 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | / +- object name +---------------+ / | flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | algorithm | public key exponent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | modulus length| | +---------------+ public key modulus -+ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The object name, and the flags octets are described in Sections 3.2 and 3.3 below. The flags must be examined before any following data as they control its the format and even whether there is any following data. The public key exponent and modulus length fields show apply only if the MD5/RSA algorithm is in use and a key is present. The public key exponent is an unsigned 24 bit integer. The public key modulus field is a multiprecision unsigned integer. The "modulus length" is an unsigned octet which is the actual modulus length minus 64. This limits keys to a maximum of 255+64 or 319 octets and a minimum of 64 octets. Although moduluses of less than 512 significant bits are not recommended, due to the weak security they provide, they can be represented by using leading zeros. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 10] INTERNET-DRAFT DNS Protocol Security Extensions 3.2 Object Types and DNS Names and Keys The public key in a KEY RR belongs to the object named in the object name field. Frequently this will also be the owner name of the KEY RR. But they will be different in the case of the key or keys stored under a zone's name for the zone's superzone or keys that are stored for cross certification. The DNS object name may refer to up to three things. For example, dee.lkg.dec.com could be (1) a zone, (2) a host, and (3) the mapping into a DNS name of the user dee@lkg.dec.com . Thus, there are flags in the KEY RR to indicate with which of these roles the object name and public key are associated as described below. It is possible to use the same key for these different things with the same name but this is discouraged. In addition, there are three control bits, the "no key" bit, the "experimental" bit, and the "signatory" bit, as described in 3.3 below. It would be desirable for the growth of DNS to be managed so that additional possible simultaneous uses for names are NOT added. New uses should be distinguished by exclusive domains. For example, all IP autonomous system numbers have been mapped into the in-as.arpa domain [draft-ietf-dnssec-as-map-*.txt] and all telephone numbers in the world have been mapped into the tpc.int domain [...]. This is preferable to having the same name possibly be an autonomous system number, telephone number, and/or host as well as a zone and a user. 3.3 The KEY RR Flag Octet In the "flags" field: Bit 0 is the "no key" bit. If this bit is on, there is no key information and the RR stopw with the flags octet. Bits 1 is the "experimental" bit. Keys may be associated with zones or entities for experimental, trial, or optional use, in which case this bit will be one. If this bit is a zero, it means that the use or availability of security based on the key is "mandatory". Thus, if this bit is off for a zone, the zone should be assumed secured by SIG RRs and any responses indicating the zone is not secured should be considered bogus. Similarly, if this bit were off for a host key and attempts to negotiate IP-security with the host produced indications that IP-security was not supported, it should be assumed that the host has been compromised or communications with it are being spoofed. On the other hand, if this bit were a one, the host might very well sometimes operate in a secure mode and at other Donald E. Eastlake 3rd & Charles W. Kaufman [Page 11] INTERNET-DRAFT DNS Protocol Security Extensions times operate without the availability of IP-security. The experimental bit, like all other aspects of the KEY RR, is only effective if the KEY RR is appropriately signed by a SIG RR. Bit 2 is the "signatory" bit. It indicates that the key can validly sign RRs of the same name. If the owner name is a wildcard, then RRs with any name which is in the wildcard's scope can be signed including NS and corresponding KEY RRs to carve out a subzone. This bit is meaningless for zone keys which always have authority to sign any RRs in the zone. The signatory bit, like all other aspects of the KEY RR, is only effective if the KEY RR is appropriately signed by a SIG RR. Bits 3-4 are reserved and must be zero. If they are found non- zero, they should be ignored and the KEY RR used as indicated by the other flags. Bit 5 on indicates that this is a key associated with a "user" or "account" at an end entity, usually a host. The coding of the owner name is that used for the responsible individual mailbox in the SOA record: The owner name is the user name as the name of a node under the entity name. For example, "j.random_user" on host.subdomain.domain could have a public key associated through an KEY RR with name j\.random_user.host.subdomain.domain. It could be used in an IP-security protocol where authentication of a user was desired. This key would be useful in IP or other security for a user level service such a telnet, ftp, rlogin, etc. Bit 6 on indicates that this is a key associated with the non- zone entity whose name is the RR owner name. This will commonly be a host but could, in some parts of the DNS tree, be some other type of entity such as an Autonomous System [draft-ietf-dnssec-as-map-*.txt]. This is the public key used in connection with the optional DNS transaction authentication service that can be used if the owner name is a DNS server host. It could also be used in an IP-security protocol where authentication of a host was desired. Bit 7 on indicates that this is a zone key for the zone whose name is the RSA RR owner name. This is the fundamental type of DNS data origin authentication public key. 3.4 The KEY Algorithm Version This octet is the key algorithm version parallel to the same field for the SIG resource. The MD5/RSA algorithm described in this draft is number 1. Version numbers 2 through 253 are available for assignment should sufficient reason arise. However, the designation of a new version could have a major impact on interoperability Donald E. Eastlake 3rd & Charles W. Kaufman [Page 12] INTERNET-DRAFT DNS Protocol Security Extensions requires an IETF standards action. Version 254 is reserved for private use and will never be assigned a specific algorithm. For version 254, the combined "public exponent", "modulus length" and "modulus" area shown above will actually begin with an Object Identifier (OID) indicating the private algorithm in use and the remainder of the combined area is whatever is required by that algorithm. Algorithm versions 0 and 255 are illegal. 3.5 KEY RRs in the Construction of Responses A request for KEY RRs does not cause any special additional information processing except, of course, for the corresponding SIG RR from a security aware server. Security aware DNS servers will include KEY RRs as additional information in responses where appropriate as follows: On the retrieval of NS RRs, the zone key KEY RR(s) for the zone served by these name servers will be included. If not all additional info will fit, the KEY RR(s) have lower priority than type A glue RRs. On retrieval of type A RRs, the end entity KEY RR(s) for the host named will be included. On inclusion of A RRs as additional information, their KEY RRs will also be included but with lower priority than the relevant A RRs. 3.6 File Representation of KEY RRs KEY RRs may appear as lines in a zone data file. The object name appears first. The flag octet and algorithm version octets are then represented as unsigned integers; however, if the "no key" flag is on in the flags, nothing appears after the flag octet. If the algorithm specified is the MD5/RSA algorithm, then the exponent and modulus appear. The public key exponent is an unsigned integer from 3 to 16777215. The public key modulus can be quite large, up to 319 octets. It is the last data field and is represented in hex and may be divided up into any number of white space separated substrings, down to single hex digits, which are concatenated to obtain the full signature. These hex substrings can span lines using the standard parenthesis. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 13] INTERNET-DRAFT DNS Protocol Security Extensions If an algorithm from 2 through 253 is specified, the public key parameters required by that algorithm are given. If the algorithm specified is number 254, then an OID appears followed by whatever is required for the private algorithm. Algorithm versions 0 and 255 are illegal. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 14] INTERNET-DRAFT DNS Protocol Security Extensions 4. The SIG Resource Record The SIG or "signature" resource record (RR) is the fundamental way that data is authenticated in the secure DNS. As such it is the heart of the security provided. The SIG RR unforgably authenticates other RRs of a particular type and binds them to a time interval and the signer's fully qualified domain name. This is done using cryptographic techniques and the signer's private key. The signer is usually the owner of the zone from which the RR originated. 4.1 SIG RDATA Format The RDATA portion of a SIG RR is as shown below. The integrity of the RDATA information and that of the SIG RRs owner, type, and class are protected by the signature field. 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type covered | algorithm | labels | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | original TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | signature expiration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | time signed | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | key footprint | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ signer's name / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | signature / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The value of the SIG type is 24. The "type covered" is the type of the other RRs covered by this SIG. The algorithm version number is an octet specifying the digital signature algorithm used. The MD5/RSA algorithm described in this draft is version one. Version numbers 2 through 253 are available for assignment should sufficient reason arise to allocate them. However, the designation of a new version could have a major impact on the interoperability of the global DNS systems and requires an IETF standards action. Version 254 is reserved for private use and Donald E. Eastlake 3rd & Charles W. Kaufman [Page 15] INTERNET-DRAFT DNS Protocol Security Extensions will never be assigned a specific algorithm. For version 254, the "signature" area shown above will actually begin with an Object Identified (OID) indicating the private algorithm in use and the remainder of the signature area is whatever is required by that algorithm. Version numbers 0 and 2555 are illegal. The "labels" octet is an unsigned count of how many labels there are in the original SIG RR owner name not counting the null label for root and not counting any initial "*" for a wildcard. If, on retrieval, the RR appears to have a longer name, the resolver can tell it is the result of wildcard substitution. If the RR owner name appears to be shorter than the labels count, the SIG RR should be considered corrupt and ignored. The maximum number of labels possible in the current DNS is 127 but the entire octet is reserved and would be required should DNS names ever be expanded to 255 labels. If a secured retrieval is the result of wild card substitution, it is necessary for the resolver to use the original form of the name in verifying the digital signature. The field helps optimize the determination of the original form. The "original TTL" field is included in the RDATA portion to avoid authentication problems that caching servers would otherwise cause by decrementing the real TTL field and security problems that unscrupulous servers could otherwise cause by manipulating the real TTL field. This original TTL is protected by the signature while the real TTL field is not. The SIG is valid until the "signature expiration" time which is an unsigned number of seconds since the start of 1 January 1970. The "time signed" field is an unsigned number of seconds since the start of 1 January 1970. The "key footprint" is a 16 bit quantity that is used to help efficiently select between multiple keys which may be applicable and as a quick check that a public key about to be used for the computationally expensive effort to decode the signature is possibly valid. Its exact meaning is algorithm dependent. For the MD5/RSA algorithm, it is the next to the bottom two octets of the public key modulus needed to decode the signature field. That is to say, the most significant 16 of the lest significant 24 bits of this quantity. The "signer's name" field is the fully qualified domain name of the signer generating the SIG RR. This is usually the zone which contained the RR(s) being authenticated. The structured of the "signature" field depends on the algorithm chosen and is described below. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 16] INTERNET-DRAFT DNS Protocol Security Extensions 4.1.1 Signature Format The actual signature portion of the SIG RR binds the owner, signer, class, original TTL, time signed, flags, and expiration time of the SIG RR to all of the "type covered" RRs with that owner name. These covered RRs are thereby authenticated. To accomplish this, a data sequence is constructed as follows: data = algorithm | original TTL | Expiration Time | Time signed | Signer's Name | RR(s)... where | is concatenation and RR(s) are all the expanded (no name abbreviation) RR(s) of the type covered with the same owner name as the SIG RR in canonical order. The canonical order for RRs is to sort them in ascending order as left justified unsigned octet sequences where a missing octet sorts before a zero octet. How this data sequence is processed into the signature is algorithm dependent. For the MD5/RSA algorithm, the signature is as follows hash = MD5 ( data ) signature = ( 01 | FF* | 00 | hash ) ** e (mod n) where "|" is concatenation, "e" is the secret key exponent of the signer, and "n" is the public modulus that is the signer's public key. 01, FF, and 00 are fixed octets of the corresponding hexadecimal value. The FF octet is repeated the maximum number of times such that the value of the quantity being exponentiated is one octet shorter than the value of n. The size of n, including most and least significant bits (which will be 1) SHALL be not less than 512 bits and not more than 2552 bits. n and e MUST be chosen such that the public exponent is less than 2**24 - 1 and SHOULD be chosen such that the public exponent is small. The above specifications are similar to Public Key Cryptographic Standard #1 [PKCS1]. (A public exponent of 3 minimizes the effort needed to decode a signature. Use of 3 as the public exponent may be weak for confidentiality uses since, if the same data can be collected encrypted under three different keys with an exponent of 3 then, using the Chinese Remainder Theorem [ref], the original plain text can be easily recovered. This weakness is not significant for DNS because we seek only authentication, not confidentiality.) Donald E. Eastlake 3rd & Charles W. Kaufman [Page 17] INTERNET-DRAFT DNS Protocol Security Extensions 4.1.2 SIG RRs Covering Type ANY The SIG RR described above protects all the RRs with a particular owner name and type. Thus a server must supply them all to convince a security aware resolver. However, an unscrupulous server could claim there were no RRs of a particular type under an owner name while presenting signed RRs of other types. To provide a means of protection against this, one SIG RR is added for each owner name that covers the type ANY. It is calculated as indicated above except that all RRs for that owner name, except the SIG RR covering type ANY itself, are included in the data string which is processed into the signature. 4.1.3 Zone Transfer (AXFR) SIG The above SIG mechanisms assure the authentication of all the RRs of a particular name and type and all the RRs of a particular name and any type. However, to secure complete zone transfers, a SIG RR owned by the zone name must be created with a type covered of AXFR that covers all other zone signed RRs. It will be calculated by hashing together all other static zone RRs, including SIGs. The RRs are ordered and concatenated for hashing as described in Section 4.1.1. This SIG, other than having to be calculated last of all zone key signed SIGs in the zone, is the same as any other SIG. Dynamic zone RRs which might be added by some future dynamic zone update protocol and signed by an end entity or user key rather than a zone key (see Section 3.2) are not included. They originate in the network and will not, in general, be migrated to the recommended off line zone signing procedure (see Section 8.2). Thus such dynamic RRs are not directly signed by the zone and are not generally protected against omission during zone transfers. 4.1.4 Transaction SIGs A response message from a security aware server may optionally contain a special SIG as the last item in the additional information section to authenticate the transaction. This SIG has a "type covered" field of zero, which is not a valid RR type. It is calculated by using a "data" (see section 4.1.1) of the entire preceding DNS reply message, including header, concatenated with the entire DNS query message that produced this response, including the query's header. That is data = full response (less trailing message SIG) | full query Donald E. Eastlake 3rd & Charles W. Kaufman [Page 18] INTERNET-DRAFT DNS Protocol Security Extensions Verification of the message SIG (which is signed by the server host key, not the zone key) by the requesting resolver shows that the query and response were not tampered with in transit and that the response corresponds to the intended query. 4.2 SIG RRs in the Construction of Responses Security aware servers MUST, for every RR the query will return, attempt to send the available SIG RRs which authenticate the requested RR. If multiple such SIGs are available, there may be insufficient space in the response to include them all. In this case, SIGs whose signer is the zone containing the RR MUST be given highest priority and retained even if SIGs with other signers must be dropped. To minimize possible truncation problems, if a SIG covers any RR that would be in the answer section of the response, its automatic inclusion MUST be the answer section. If it covers an RR that would appear in the authority section, its automatic inclusion MUST be in the authority section. If it covers an RR that would appear in the additional information section it MUST appear in the additional information section. Optionally, DNS transactions may be authenticated by a SIG RR at the end of the response in the additional information section (section 4.1.4). Such SIG RRs are signed by the DNS server originating the response. Although the signer field must be the name of the originating server host, the name, class, TTL, and original TTL, are meaningless. The class and TTL fields can be zero. To save space, the name should be root (a single zero octet). [There may be a problem with SIG and NXD RR's associated with domain names that are CNAMEs. The DNS RFCs prohibit other types of RRs appearing with a CNAME RR. This problem is being ignored until it is clear if DNS servers will really have a problem with this.] 4.3 Processing Responses with SIG RRs If SIG RRs are received in response to a query specifying the SIG type, no special processing is required but a security aware client may wish to authenticate them by decoding the signature and applying consistency checks. If SIG RRs are received in any other response, a security aware client should decoded them using the public key of the signer. The result of such decoding should thenbe verified against the Donald E. Eastlake 3rd & Charles W. Kaufman [Page 19] INTERNET-DRAFT DNS Protocol Security Extensions appropriate other RRs retrieved. If the message does not pass reasonable checks or the SIG does not check against the signed RRs, the SIG RR is invalid and should be ignored. The time of receipt of the SIG RR must be in the inclusive range of the time signed and the signature expiration but the SIG can be retained and remains locally valid until the expiration time plus the authenticated TTL. If the SIG RR is the last RR in a response in the additional information section and has a type covered of zero, it is a transaction signature of the the response and the query that produced the response. It may be optionally checked and the message rejected if the checks fail. But even it the checks succeed, such a transaction authentication SIG does NOT authenticate any RRs in the message. Only proper direct or hashed RR signets signed by the zone can authenticate RRs. If a resolver does not implement transaction SIGs, it MUST at least ignore them without error. If all reasonable checks indicate that the SIG RR is valid then RRs verified by it should be considered authenticated and all other RRs in the response should be considered with suspicion. 4.4 File Representation of SIG RRs A SIG RR covering RRs can be represented as a single logical line in a zone data file [RFC1033] but there are some special problems as described below. (It does not make sense to include a transaction authenticating SIG RR in a file as it is a transient authentication that must be calculated in real time by the DNS server.) There is no particular problem with the signer, covered type, and times. The time fields appears in the form YYYYMMDDHHMMSS where YYYY is the year, the first MM is the month number (01-12), DD is the day of the month (01-31), HH is the hour in 24 hours notation (00-23), the second MM is the minute (00-59), and SS is the second (00-59). The original TTL and algorithm fields appears as unsigned integers. The "labels" field does not appear in the file representation as it can be calculated from the owner name. The key footprint appears as an eight digit unsigned hexadecimal number. However, the signature itself can be very long. It is the last data field and is represented in hex and may be divided up into any number of white space separated substrings, down to single hex digits, which Donald E. Eastlake 3rd & Charles W. Kaufman [Page 20] INTERNET-DRAFT DNS Protocol Security Extensions are concatenated to obtain the full signature. These hex substrings can be split between lines using the standard parenthesis. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 21] INTERNET-DRAFT DNS Protocol Security Extensions 5. Non-existent Names The SIG RR mechanism described in section 4 above provides strong authentication of RRs that exist in a zone. But is it not immediately clear how to authenticatably deny the existence of a name in a zone. The nonexistence of a name in a zone is indicates by the NXD RR for a name interval containing the nonexistent name. An NXD RR and its SIG are returned in the additional information section, along with the error, if the resolver is security aware. NXD RRs can also be returned if an explicit query is made for the NXD type. The existence of a complete set of NXD records in a zone means that any query for any name to a security aware server serving the zone should result in an reply containing at least one signed RR. 5.1 The NXD Resource Record The NXD resource record is used to securely indicate that no RRs with an owner name in a certain name interval exist in a zone. The owner name of the NXD RR is an existing name in the zone. It's RDATA is another existing name in the zone. The presence of the NXD RR means that no name between its owner name and the name in its RDATA area exists. This implies a canonical ordering of all domain names in a zone. The ordering is to sort labels as unsigned left justified octet strings where the absence of a byte sorts before a zero byte. Names are then sorted by sorting on the highest level label and then, within those names with the same highest level label by the next lower label, etc. Since we are talking about a zone, the zone name itself always exists and all other names are the zone name with some prefix of lower level labels. Thus the zone name itself always sorts first. There is a slight problem with the last NXD in a zone as it wants to have an owner name which is the last existing name in sort order, which is easy, but it is not obvious what name to put in its RDATA to indicate the entire remainder of the name space. This is handled by treating the name space as circular and putting the zone name in the RDATA of the last NXD. There are additional complexities due to interaction with wildcards as explained below. The NXD RRs for a zone can be automatically calculated and added to Donald E. Eastlake 3rd & Charles W. Kaufman [Page 22] INTERNET-DRAFT DNS Protocol Security Extensions the zone by the same recommended off-line process that signs the zone. The NXD RRs TTL should not exceed the zone minimum TTL. The type number for the NXD RR is xxx. 5.2 NXD RDATA Format The RDATA for an NXD RR consists simply of a domain name. 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | next domain name / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.3 Example Assume a zone has entries for big.foo.bar medium.foo.bar small.foo.bar tiny.foo.bar Then a query to a security aware server for huge.foo.bar would produce an error reply with the additional information section containing big.foo.bar NXD medium.foo.bar 5.4 Interaction of NXD RRs and Wildcard RRs As a wildcard RR causes all possible names in an interval to exist, there should not be an NXD record that would cover any part of this interval. Thus if *.X.ZONE exists you would expect an NXD RR that ends at X.ZONE and one that starts with the last name covered by *.X.ZONE. However, this "last name covered" is something very ugly and long like \255\255\255....X.zone. So the NXD for the interval following is simply given the owner name *.X.zone. This "*" type name is not expanded when the NXD is returned as additional information in connection with a query for a non-existent name. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 23] INTERNET-DRAFT DNS Protocol Security Extensions If there could be any wildcard RRs in a zone and thus wildcard NXDs, care must be taken in interpreting the results of explicit NXD retrievals as the owner name may be a wildcard expansion. The existence of one or more wildcard RRs covering a name interval makes it possible for a malicious server to hide any more specificly named RRs in the internal. The server can just falsely return the wildcard match NXD instead of the more specificly named RRs. If there is a zone wide wildcard, there will be only one NXD RR whose owner name and RDATA are both the zone name. In this case a server could conceal the existence of any more specific RRs in the zone. It would be possible to make a more complex NXD feature, taking into account the types of RRs that did not exist in a name interval, and the like, which would eliminate this possibility. But it would be more complex and would be so constraining as to make any future dynamic update feature that could create new names very difficult (see Section 3.2). 5.5 Blocking NXD Pseudo-Zone Transfers In a secure zone, a resolver can query for the initial NXD associated with the zone name. Using the RDATA field from that RR, it can query for the next NXD RR. By repeating this, it can walk through all the NXDs in the zone. If there are no wildcards, it can use this technique to find all names in a zone. If it does type ANY queries, it can incrementally get all information in the zone and perhaps defeat attempts to administratively block zone transfers. If there are any wildcards, this NXD walking technique will not find any more specific RR names in the part of the name space the wildcard covers. By doing explicit retrievals for wildcard names, a resolver could determine what intervals are covered by wildcards but still could not, with these techniques, find any names inside such intervals except by trying every name. If it is desired to block NXD walking, the recommended method is to add a zone wide wildcard of the KEY type which asserts the nonexistence of any keys. This will cause there to be only one NXD RR in the zone for the zone name and leak no information about what real names exist in the zone. This protection from pseudo-zone transfers is bought at the expense of eliminating the data origin authentication of the non-existence of names that NXD RRs can provide. If an entire zone is covered by a wildcard, a malicious server can return an RR produced by matching that wildcard and can thus hide all the real data and delegations with more specific names in the zone. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 24] INTERNET-DRAFT DNS Protocol Security Extensions 6. How to Resolve Securely Retrieving or resolving authentic data from the DNS involves starting with one or more trusted public keys and, in general, progressing securely from them through the DNS zone structure to the zone of interest. Such trusted public keys would normally be configured in a manner similar to that described in section 6.1. However, as a practical matter, a security aware resolver would still gain some confidence in the results it returns even if it was not configured with any keys but trusted what it got from a local well known server as a starting point. 6.1 Boot File Format The recommended format for a boot file line to configure starting keys is as follows: zonekey f.q.d.n algorithm [exponent modulus] for a zone public key or hostkey f.q.d.n algorithm [exponent modulus] for a host public key. f.q.d.n is the domain name of the zone or host. Algorithm is the algorithm in use where one is the MD5/RSA algorithm and 254 indicates a private algorithm. The material after the algorithm is algorithm dependent and, for private algorithms, starts with the algorithm's identifying OID. For the RSA algorithm, it is the public key exponent as a decimal number between 3 and 16777215, and the modulus in hex. 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. Furthermore, many organizations will explicitly wish their "interior" DNS implementations to completely 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. If desired, the IP address for the f.q.d.n's with configured keys can generally also be configured via an /etc/hosts or similar local file. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 25] INTERNET-DRAFT DNS Protocol Security Extensions 6.2 Chaining Through Zones Starting with one trusted zone key, it is possible to retrieve signed keys for subzones which have a key. Every secure zone (except root) should also include the RSA record for its super-zone signed by the secure zone. This makes it possible to climb the tree of zones if one starts below root. A secure sub-zone is generally indicated by a KEY RR appearing with the NS RRs for the sub-zone. These make it possible to descend within the tree of zones. A resolver should keep track of the number of successive secure zones traversed from a starting point to any secure zone it can reach. In general, the lower such a distance number is, the greater the confidence in the data. Data configured via a boot file should be given a distance number of zero. Should a query encounter different data with different distance values, that with a larger value should be ignored. A security conscious resolver should completely refuse to step from a secure zone into a non-secure zone unless the non-secure zone is certified to be non-secure or only experimentally secure by the presence of an authenticated KEY RR for the non-secure zone with a no key flag or the presence of a KEY RR with the experimental bit set. Otherwise the resolver is probably getting completely bogus or spoofed data. If legitimate non-secure zones are encountered in traversing the DNS tree, then no zone can be trusted as secure that can be reached only via information from such non-secure zones. Since the non-secure zone data could have been spoofed, the "secure" zone reach via it could be counterfeit. The "distance" to data in such zones or zones reached via such zones could be set to 512 or more as this exceeds the largest possible distance through secure zones in the DNS. Nevertheless, continuing to apply secure checks within "secure" zones reached via non-secure zones will, as a practical matter, provide some increase in security. The existence of cross certifications adds further policy questions. Assume we have a zone B.A and a zone Y.X. Many possibilities exist for a secure resolver configured with the B.A key to get to Y.X. If all the zones along the way are secure, it could climb to root and then descend the other side, a total of four hops (B.A -> A -> . -> X -> Y.X). If the B.A administrator had installed a cross certified key for Y.X in the B.A zone, using that would be a shorter and presumably more secure way to find Y.X's key which would be immune to the non-security or even compromise of the servers for A or root or X. But what if some less trusted subzone of B.A, say C.B.A installed a cross certified key for Y.X? If there is a conflict, should this be preferred to a hierarhically derived key obtained by climbing to root and descending? Such questions are a matter of local resolver Donald E. Eastlake 3rd & Charles W. Kaufman [Page 26] INTERNET-DRAFT DNS Protocol Security Extensions policy. 6.3 Secure Time Coordinated interpretation of the time fields in SIG RRs requires that reasonably consistent time be available to the hosts implementing the DNS security extensions. A variety of time synchronization protocols exist including the Network Time Protocol (NTP, RFC1305). If such protocols are used, they should be used securely so that time can not be spoofed. Otherwise, for example, a host could get its clock turned back and might then believe old SIG and KEY RRs which were valid but no longer are. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 27] INTERNET-DRAFT DNS Protocol Security Extensions 7. Operational Considerations This section discusses a variety of considerations in secure operation of DNS using these proposed protocol extensions. 7.1 Key Size Considerations There are a number of factors that effect public key size choice for use in the DNS security extension. Unfortunately, these factors usually do not all point in the same direction. Choice of a key size should be made by the zone administrator depending on their local conditions. For most schemes, larger keys are more secure but slower. Verification (the most common operation) for the MD5/RSA algorithm will vary roughly with the square of the modulus length, signing will vary with the cube of the modulus length, and key generation (the least common operation) will vary with the fourth power of the modulus length. The current best algorithms for factoring a modulus and breaking RSA security vary roughly with the square of the modulus itself. Thus going from a 640 bit modulus to a 1280 bit modulus only increases the verification time by a factor of 4 but vastly increases the work factor of breaking the key. [RSA FAQ] However, larger keys increase size of the KEY RR and usually the SIG RR. This increases the change of UDP packet flow and the possible necessity for using higher overhead TCP. The recommended minimum RSA algorithm modulus size, 640 bits, is believed by the authors to be secure at this time and for some years but high level nodes in the DNS tree may wish to set a higher minimum, perhaps 1000 bits, for security reasons. (Since the United States National Security Agency generally permits export of encryption systems using an RSA modulus of up to 512 bits, use of that small a modulus, i.e. n, must be considered weak.) 7.2 Key Storage It is strongly recommended that zone private keys and the zone file master copy be kept and used in off-line non-network connected physically secure machines only. Periodically an application can be run to re-sign the RRs in a zone by adding NXD and SIG RRs. Then the augmented file can be transferred, perhaps by sneaker-net, to the networked zone primary server machine. The idea is to have a one way information flow to the network to Donald E. Eastlake 3rd & Charles W. Kaufman [Page 28] INTERNET-DRAFT DNS Protocol Security Extensions avoid the possibility of tampering from the network. Keeping the zone master file on-line on the network and simply cycling it through an off-line signer does not do this. The on-line version could still be tampered with if the host it resides on is compromised. The master copy of the zone file should be off net and should not be updated based on an unsecured network mediated communication. Non-zone private keys, such as host keys, may have to be kept on line to be used for real-time purposes such a IP secure session set-up. 7.3 Key Generation Careful key generation is a sometimes over looked but absolutely essential element in any cryptographically secure system. The strongest algorithms used with the longest keys are still of no use if an adversary can guess enough to lower the size of the likely key space so that it can be exhaustively searched. Suggestions will be found in draft-ietf-security-randomness-*.txt. It is strongly recommended that key generation also occur off-line, perhaps on the machine used to sign zones (see Section 7.2). 7.4 Key Lifetimes No key should be used forever. The longer a key is in use, the greater the probability that it will have been compromised through carelessness, accident, espionage, or cryptanalysis. No zone key should have a lifetime significantly over five years. The recommended maximum lifetime for zone keys that are kept off-line and carefully guarded is 13 months with the intent that they be replaced every year. The recommended maximum lifetime for end entity keys that are used for IP-security or the like and are kept on line is 36 days with the intent that they be replaced monthly or more often. In some cases, an entity key lifetime of a little over a day may be reasonable. 7.5 Revocation [This is new and should probably be moved to someplace above...] Data in the DNS is authenticated via keyed digital signatures. Thus to revoke data, we need to alter the time period of the key's effectiveness to not include the date signed of the data to be remoked. Note that the case of a compromised key, where we wish to Donald E. Eastlake 3rd & Charles W. Kaufman [Page 29] INTERNET-DRAFT DNS Protocol Security Extensions make its period of effectiveness null, we generally need only think of the KEY RR as data and make the period of effectiveness of the superzone's key not include the time of the previous superzone signing of the key. Normally, a KEY retrieved from the DNS appears to be effective from the beginning of time until the expiration of the SIG that authenticated it. (If this were not so, a secure zone would have to be resigned every time its superzone is resigned.) When data is being revoked, a zone can be resigned with a later date signed but a mechanism is need to make the earlier SIG of the now revoked data not longer valid. A dawn for the effectiveness of a node's KEY RR is provided, when desired, by having the key appear self-signed. This declares the time signed of the self signature as the time of effectiveness of the key(s). Note this is entirely under the control of a zone and asynchronous with its superzone's signings. This technique covers non-zone entities as well. For an owner to have a dawn to the effectiveness of its delegated key (which is signed by the zone key), it need only self-sign its key and the date signed is the dawn. 7.6 Root The root zone includes its own key self-signed. It should also be noted that in DNS the root is a zone unto itself. Thus the root zone key should only be see signing itself or signing RRs with names one level below root, such as .aq, .edu, or .arpa. Implementations MAY reject as bogus any purported root signature of records with a name more than one level below root. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 30] INTERNET-DRAFT DNS Protocol Security Extensions 8. Conformance Several levels of server and resolver conformance are defined. 8.1 Server Conformance Three levels of server conformance are defined as follows: Zilch server compliance is the ability to store and retrieve (including zone transfer) SIG, KEY, and NXD RRs. It is believed that most current servers meet this level of compliance. Minimal server compliance adds the following to zilch compliance: (1) ability to read SIG, KEY, and NXD RRs in zone files and (2) ability, given a zone file and private key, to add appropriate SIG and NXD RRs, possibly via a separate application. Primary servers for secure zones must be at least minimally compliant. Full server compliance is ability to automatically include SIG, KEY, and NXD RRs in responses as appropriate, as well as meeting minimal compliance. 8.2 Resolver Conformance Two levels of resolver compliance are defined: A Zilch compliance resolver can handle SIG, KEY, and NXD RRs when they are explicitly requested. It is believed that current resolvers are Zilch compliant. A fully compliant resolver understands KEY, SIG, and NXD RRs, maintains appropriate information in its local caches and database to indicate which RRs have been authenticated and to what extent they have been authenticated, and performs additional queries as necessary to obtain KEY, SIG, or NXD RRs from non-security aware servers. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 31] INTERNET-DRAFT DNS Protocol Security Extensions 9. Security Considerations This document concerns technical details of extensions to the Domain Name System (DNS) protocol to provide data integrity and data origin authentication, public key distribution, and optional transaction security. If should be noted that, at most, these extensions guarantee the validity of resource records, including KEY resource records, retrieved from the DNS. They do not magically solve other security problems. For example, using secure DNS you can have high confidence in the IP address you retrieve for a host; however, this does not stop someone for substituting an unauthorized host at that address or capturing packets sent to that address and responding with packets apparently from that address. Any reasonably complete security system will require the protection of many other facets of the Internet. References [PKCS1] - PKCS #1: RSA Encryption Standard, RSA Data Security, Inc., 3 June 1991, Version 1.4. [RFC1032] - Domain Administrators Guide, M. Stahl, November 1987 [RFC1033] - Domain Administrators Operations Guide, M. Lottor, November 1987 [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris, November 1987 [RFC1035] - Domain Names - Implementation and Specifications [RFC1321] - The MD5 Message-Digest Algorithm, R. Rivest, April 16 1992. [RSA FAQ] - RSADSI Frequently Asked Questions periodic posting. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 32] INTERNET-DRAFT DNS Protocol Security Extensions Authors Addresses Donald E. Eastlake 3rd Digital Equipment Corporation 550 King Street, LKG2-1/BB3 Littleton, MA 01460 Telephone: +1 508 486 6577(w) +1 508 287 4877(h) EMail: dee@lkg.dec.com Charles W. Kaufman Iris Associates Telephone: +1 508-392-5276 EMail: charlie_kaufman@iris.com Expiration and File Name This draft expires 19 May 1995. Its file name is draft-ietf-dnssec-secext-02.txt. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 33]   Received: from sol.tis.com by magellan.TIS.COM id aa22410; 21 Nov 94 4:51 EST Received: from mitsou.inria.fr(138.96.24.84) by relay via smap (V1.3) id sma015843; Mon Nov 21 04:52:21 1994 Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA12595; Mon, 21 Nov 1994 10:50:06 +0100 Message-Id: <199411210950.AA12595@mitsou.inria.fr> To: "Donald E. Eastlake 3rd (Beast)" Cc: dns-security@tis.com Subject: Re: draft-ietf-dnssec-as-map-01.txt In-Reply-To: Your message of "Mon, 21 Nov 1994 02:55:51 EST." <9411210755.AA25638@skidrow.tay.dec.com> Date: Mon, 21 Nov 1994 10:50:06 +0100 From: Christian Huitema Donald, Did you consider the mapping of autonomous system numbers in the IPv4 address space already used by SDRP? They needed to specify source routes "through an AS", so they represent the AS cloud by the IP address "128.0.x.y", where the last two bytes encode an Autonomous System number. This usage would translate in a prefix of "0.128.in-addr.arpa". Christian Huitema   Received: from sol.tis.com by magellan.TIS.COM id aa25278; 21 Nov 94 9:51 EST Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3) id sma019080; Mon Nov 21 09:51:30 1994 Received: from skidrow.tay.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA05411; Mon, 21 Nov 94 06:44:03 -0800 Received: by skidrow.tay.dec.com (5.65/MS-081993); id AA05679; Mon, 21 Nov 1994 09:48:30 -0500 Message-Id: <9411211448.AA05679@skidrow.tay.dec.com> To: Christian Huitema Cc: "Donald E. Eastlake 3rd (Beast)" , dns-security@tis.com Subject: Re: draft-ietf-dnssec-as-map-01.txt In-Reply-To: Your message of "Mon, 21 Nov 94 10:50:06 +0100." <199411210950.AA12595@mitsou.inria.fr> Date: Mon, 21 Nov 94 09:48:30 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Christian, No, I hadn't considered that. If there is already a convenient encoding of AS numbers into DNS and no conflicts on the use of RRs at that name, then there is no particular reason to invent a new mapping... Donald From: Christian Huitema To: "Donald E. Eastlake 3rd (Beast)" Cc: dns-security@tis.com In-Reply-To: Your message of "Mon, 21 Nov 1994 02:55:51 EST." <9411210755.AA25638@skidrow.tay.dec.com> >Donald, > >Did you consider the mapping of autonomous system numbers in the IPv4 address >space already used by SDRP? They needed to specify source routes "through an >AS", so they represent the AS cloud by the IP address "128.0.x.y", where the >last two bytes encode an Autonomous System number. This usage would translate >in a prefix of "0.128.in-addr.arpa". > >Christian Huitema   Received: from sol.tis.com by magellan.TIS.COM id aa06259; 22 Nov 94 20:08 EST Received: from ietf.cnri.reston.va.us(132.151.1.35) by relay via smap (V1.3) id sma015155; Tue Nov 22 20:10:17 1994 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09404; 22 Nov 94 14:50 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@magellan.TIS.COM MMDF-Warning: Parse error in original version of preceding line at magellan.TIS.COM Cc: dns-security@tis.com From: Internet-Drafts@cnri.reston.va.us Reply-To: Internet-Drafts@cnri.reston.va.us Subject: I-D ACTION:draft-ietf-dnssec-secext-02.txt Date: Tue, 22 Nov 94 14:50:36 -0500 Sender: cclark@cnri.reston.va.us Message-Id: <9411221450.aa09404@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Security Working Group of the IETF. Title : Domain Name System Protocol Security Extensions Author(s) : D. Eastlake, C. Kaufman Filename : draft-ietf-dnssec-secext-02.txt Pages : 33 Date : 11/21/1994 The Domain Name System (DNS) has become a critical operational part of the Internet infrastructure yet it has no strong security mechanisms to assure data integrity or authentication. Extensions to the DNS are described in detail that provide these services to security aware resolvers or applications through the use of cryptographic digital signatures. These digital signatures are included in secured zones as resource records. Security can still be provided even through non-security aware DNS servers. A explanatory overview of the proposed extensions appears in draft-ietf-dnssec-over-*.txt. The extensions also provide for the storage of authenticated keys in the DNS for DNS use and to support a general public key distribution service. The stored keys enable security aware resolvers to learn the authenticating key of zones in addition to keys for which they are initially configured. Keys associated with DNS names can be retrieved to support other protocols. Provision is made for a variety of key types and algorithms. In addition, the security extensions provide for the optional authentication of DNS protocol transactions. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnssec-secext-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-secext-02.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dnssec-secext-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19941121132011.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-secext-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-secext-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19941121132011.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart--   Received: from sol.tis.com by magellan.TIS.COM id aa17910; 26 Nov 94 22:34 EST Received: from unknown(131.112.32.132) by relay via smap (V1.3) id sma018001; Sat Nov 26 22:35:31 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sun, 27 Nov 94 12:26:54 +0859 From: Masataka Ohta Return-Path: Message-Id: <9411270327.AA06407@necom830.cc.titech.ac.jp> Subject: revised draft-ohta-simple-dns To: dns-security@tis.com Date: Sun, 27 Nov 94 12:26:53 JST Cc: dns-security@tis.com X-Mailer: ELM [version 2.3 PL11] Dear DNSSEC members; I have just posted the following revised internet draft. It's a little more simplified and a lot more compatible with the existing DNS than the previous version. Optional cross authentication scheme is also added. Masataka Ohta ------------------------------------------------------------------------ INTERNET DRAFT M. Ohta draft-ohta-simple-dns-01.txt Tokyo Institute of Technology November 1994 Simple Secure DNS Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au. Abstract An extension to DNS is proposed to make answers from it authenticated. The extension is designed to be minimal, which will be useful as a framework to make applications provide required level of authentication and/or confidentiality. The changes to the existing architecture of DNS is also minimized. 1. Introduction The purpose of the secure DNS protocol extension is to make data from DNS authenticated. In general, security has two aspects, authentication to make data unforgable and confidentiality to make data secret. As the fundamental role of DNS is to make its database available all around the world, no confidentiality is considered in this document. IQUERY, an optional feature of DNS, is inherently insecure, and not considered in this document. This document is written with the assumption that readers thoroughly understand the existing DNS described in RFC 1034 and RFC 1035. On the other hand, little knowledge on cryptography is assumed. M. Ohta Expires on June 1, 1995 [Page 1] INTERNET DRAFT Simple Secure DNS November 1994 To make DNS secure, two cryptographic mechanisms: digesting and signature, are combined. Digesting is the mechanism to compute a short digest of a byte stream. The mechanism should be complex enough so that, given a digest value of some byte stream, it should be practically impossible to forge a different byte stream which has the same digest value. The other is the mechanism to give signature to a byte stream with some secret information. The mechanism should be complex enough so that, given a signature value of some data and the original data itself, it should be practically impossible to guess the secret information. The signature can be verified by sharing secret information between related parties or by using private/public key technology. This document does not specify the actual mechanisms to generate digests and signatures. As long as the above two basic authentication mechanisms are reliable, secure DNS is designed to be reliable against all forms of attacks save the denial of service attacks of the most basic form, which is least harmful. That is, the secure DNS may report a temporal failure against some form of denial of service attacks. But all the answers other than the temporal failure is reliable to the extent that the basic authentication mechanisms up to the root or other locally reliable zones are reliable. For example, if a resolver can communicate with no name servers because of some attack such as unplugging of cables, the only thing the resolver can do is to report the temporal failure, which is one of the most basic form of a denial of service attack. On the other hand, secure DNS can securely report negative answers that a node does not exists or that an RR type does not exist for a given node. Authentication is provided zone wise. A secure zone is a zone whose authentication is provided by the protocol whereas a secure node is a node authoritatively belongs to a secure zone. A secure zone has its own secret information to generate signatures for secure nodes in the zone. For the maximum security, both the secret information and the signature generation mechanism of a zone should be kept off-line. In this case, even if on-line name servers of the zone is compromised, security on the DNS information of the zone is not compromised. In cases where frequent and/or automatic update of a zone is desired, it is necessary to make signature generation mechanism of the zone accessible on-line. Still, it is worthwhile to keep the secret information and secure time stamping mechanism of the zone off-line. To make it easier, the protocol is designed to let signed information have the consistent format about time stamping and signature generation. Then, after the security of the signature generation mechanism is restored, signatures using the same secret information become reliable again. M. Ohta Expires on June 1, 1995 [Page 2] INTERNET DRAFT Simple Secure DNS November 1994 Though the secure DNS can be an authenticated source of information to establish secure communication between hosts, such as distribution of host's public keys, it is out of the scope of this document and a separate document should be provided. A security aware name server is a name server which supports queries for the new RR types in this document with required additional section processing. For more protection against some denial service type attack, additional authentication mechanism may be supported for secure zone transfer. A security aware recursive resolver is a resolver which can perform authenticated retrieval of DNS data in secure zones. From several seed zones, DNS tree is recursively traversed with authentication to get the final authenticated answer. A security aware recursive resolver is configured with static information to confirm that data from name servers of some seed zones are actually secure. A security aware stub resolver is a resolver which can perform authenticated communication with a recursive resolver. A stub resolver may be configured with static information to authenticate communication between recursive resolvers. The recursive and stub resolvers may be colocated on the same host and communicate securely though some operating system mechanism, for example, UNIX domain sockets, or they may be located on different hosts. So, how the recursive and stub resolvers securely communicate is out of scope of this document. But, it is suggested that a security aware stub resolver communicate with a security aware recursive resolver colocated with name server through normal DNS query through secure IP [SECIP] protocol. In this case, secure IP can not use DNS to establish security relationship so that some static configuration is necessary. The protocol in this document is carefully designed so that existing name servers can cooperate with security aware resolvers and name servers. 2. Changes to the Previous Version and to the Existing Mechanism A lot of simplification is performed to the previous version of the draft: "draft-ohta-simple-dns-00.txt. First, protocol in this document, now, introduces no important changes to the existing DNS architecture. That is: No new OPCODE, NCQUERY, is added. Some query types for authentication matches its own RR type and CNAME. The M. Ohta Expires on June 1, 1995 [Page 3] INTERNET DRAFT Simple Secure DNS November 1994 impossibility of the current DNS to have CNAME only zone is left untouched. SD (Security Desired) bit is not added. As the desire needs to be expressed only for the secure communication between recursive and stub resolvers, it's out of the scope of this document. If secure IP protocol is used for the communication the fact that the secure IP protocol is used itself shows that the security is desired. SA (Security Assured) bit is not added. Instead, if secure communication channel to stub resolvers is used, secure recursive resolver must assure RRs that the answer section contains authenticated data only. Meaning of MINTTL field of SOA RRs is untouched, though it is widely known that using it as negative caching period is inappropriate. Cases of domain names are not canonicalized. They are canonicalized only when digest value is computed. To NSIG RR, field is added. Optional resolver operation mode for cross authentication is added. 3. New Data Types New data types: RRD, NSIG and are added to secure nodes. ZA, ZSIG and ZL are added to secure zones. Actual RR type names or values for the data and their syntax may vary according to specific authentication algorithm. Detailed explanation, including the actual RR type values for new data types, are not given in this document. Square bracketed notation "[RR]" is used to designate a instance of a new data type "RR". In general, data size for authentication is often as large as of 100 bytes or more. So, it is a bad idea to share a single RR type value between different authentication mechanisms, because querying them all will often break 512 byte limit of UDP query. So, authentication algorithms are distinguished by RR type values, not by something like an algorithm type field. Binary format of each RRs are arranged with the byte sex of bigendean in the same order as the textual format. When RR types are used as query type, RRD and NSIG query matches a CNAME record too. M. Ohta Expires on June 1, 1995 [Page 4] INTERNET DRAFT Simple Secure DNS November 1994 RRD (RR Digest) Digest value of all the data with a certain RR type in a secure node. [RRD] RRs have the following syntax ( and are omitted throughout the document): [RRD] where [RRD] is the RR name of RRD, is the digest of all the resource records of type of node . is the original TTL value of the records. is a 16 bit quantity, is a 32 bit quantity, is of variable length. When computing , records are represented in binary form in DNS packet with the following canonicalization: No domain name compression is performed. Upper case letters in domain names are converted to the corresponding lower case letters. If there are multiple records of the same , they are sorted with dictionary order, comparing the first bytes first with unsigned arithmetic. For example, four strings "AB", "AC", "BA" and "ABC" are sorted as ["AB", "ABC", "AC", "BA"]. When verifying the digest of received data in resolvers and name servers, TTL field of the records, which should be decreased already, should be replaced with the (original TTL) field of the RRD record. When caching authenticated data, name servers and resolvers should confirm that the TTL in the answer packet does not exceed the value in RRD data. A node, in general, has multiple [RRD] records for each RR type the node has. But, it is impossible and unnecessary to cover s of RRD, NSIG and ZSIG with digest. Still, it is necessary to have RRD of such s as protection against denial service attacks, that is, to authenticate negative response of non existing RR types. An [RRD] record for [NSIG] or [ZSIG] RR has the field of length zero. To compute of [RRD] RR type itself, the field of the record itself is first considered to have zero length (including length field of the record) and later replaced with the actual digest length and value. M. Ohta Expires on June 1, 1995 [Page 5] INTERNET DRAFT Simple Secure DNS November 1994 NSIG (Node SIGnature) Signature on RRD computed using secret information of the zone, added to secure nodes. [NSIG] RRs have the following syntax: [NSIG] where [NSIG] is the RR name of NSIG (such as ELGAMAL640, RSA or KERBEROS), is a domain name of a zone who signs [ZA] and is the time when the signature is computed. is the number of seconds the signature will be valid after . and are 32 bit quantities. is of variable length. Throughout the document, time is a 32 bit quantity, unless otherwise specified. Absolute time is counted by the number of seconds from 00:00:00 GMT, Jan. 1st. 1970 A.D. and wraps around after 2^32 seconds (about 136 years). As the 32 bit time value circulates, zone's secret information should be changed at least once per 50 years. Otherwise, stale data signed 136 years ago may be distributed with a valid signature. When computing ; , and of [RRD] are serialized with the byte order used in DNS packets and the resulting byte stream is signed by the zone's signature mechanism(s). No NSIG records are provided for non-authoritative data for a zone such as referral information. Thus, if a name server is compromised or its IP address is used by an attacker, it is possible to implant false referral information to a resolver. Still, as child zones have its own information, ZSIG (Zone SIGnature) described later, to authenticate themselves, the attacked resolver can detect that the referral information is bogus. The result is no worse than a simple denial of service attack by compromising name servers of the parent zone. That is, it is not necessary nor meaningful to try to authenticate referral NSes or glue A records for child zones. ZA (Zone Authenticator) Data added to a secure zone to specify how to verify NSIGs of nodes within the zone. [ZA] RRs have the following syntax: M. Ohta Expires on June 1, 1995 [Page 6] INTERNET DRAFT Simple Secure DNS November 1994 [ZA] where [ZA] is the RR name of ZA, is the time from when the is used. is 32 bit absolute time. is of variable length. The actual content of varies by the authentication algorithm. It may be a public key of the zone or IP addresses of authentication centers of the zone which maintains secret information of related parties. field is useful to smoothly change zone's secret information. Usually, a zone has only one record of [ZA] type. But, a zone may have two such records when zone's secret information is being changed. Otherwise, authentication of RRs signed before the change fails with a new . If multiple [ZA]s exist during the transition, field of NSIG is compared to the fields in [ZA]s to select the RR actually used for the signature. Older RR should disappear after all the signature signed with it is assured to have expired. ZSIG (Zone SIGnature) Data added to a secure zone to specify how to verify ZA of the zone. ZSIG data contains a signature of digest of the zone's ZA signed by other secure zones, typically its parent zone. [ZSIG] RRs have the following syntax. [ZSIG] <[NSIG]> where [ZSIG] is the RR name of ZSIG data, is a domain name of a zone who signs [ZA], <[NSIG]> is the methods used for signature (represented in RR type) used by the . , and are the same as that of [NSIG] except that the signature covers the sequence of , where is the field of [RRD] of [ZA] of a signed zone. In general, only a who is a parent or an ancestor of the signed zone or the root zone should be considered to be secure, though local administrator may add or remove reliable s according to their local security policy. If multiple ZSIG RRs of different [ZSIG] values exist, the most preferable one is chosen by the resolver's local security policy. For the root zone or M. Ohta Expires on June 1, 1995 [Page 7] INTERNET DRAFT Simple Secure DNS November 1994 locally reliable zones, name servers should be statically configured with information to authenticate [ZSIG]. ZL (Zone List) data used to store sorted list of all the nodes in a zone. The information is necessary for protection against denial of service attacks, that is, if a node does not appear in certain ZLs, a negative response that a queried node does not exist is authenticated. The simplest way to authenticate negative answer that some data does not exist is to have an authenticated list of all the existing data. But, unless the number of existing data is expected to be small, as in the case with [RRD], listing up is inefficient. Especially, for a very large zone such as "com.", the size of the list is impractically large. So, existing data are sorted in a certain order and segmented appropriately into multiple ZL records. To authenticate the non-existence of a node, only a ZL RR containing the node (according to the sorting order) needs to be returned. To not to cause UDP size overflow, ZL RRs are intended to be returned as a partial RR in the additional section of a negative answer with truncation bit set. To authenticate a partial ZL RR, it is necessary to attach authentication signatures to individual ZL RRs. With wildcarding, actual authentication is a little more complicated and is discussed in section 5.3: "Resolver Algorithm". ZL will have the following syntax. [ZL] ... where [ZL] is the RR name of ZL data, is the number of seconds appropriate for negative caching, is the number of domains covered by the record. The record contains all the domain names of the zone (including the top level nodes of child zones but excluding the zone name itself) after (or including) and before sorted with dictionary order. Cases of characters in , ... must be canonicalized to lower cases. and is merely a separator and should not be interpreted that such a node exists unless explicitly listed as . Comparison is performed first label by label. Top level labels are compared first and the leaf labels are compared last, which makes domain name compression work quite well. Within labels, comparison are by dictionary oder, that is, first bytes are compared first. For example, "a.b.c.", "a.c.b.", "a.c.", "ab.c.", "ac.b." and "c." are ordered as "ac.b.", "a.c.b.", "c.", "a.c.", "ab.c." and "a.b.c.". M. Ohta Expires on June 1, 1995 [Page 8] INTERNET DRAFT Simple Secure DNS November 1994 Thus, the name of the zone is ordered before all the other names in the domain. For the comparison purpose, when the name of the zone itself appears as , it is considered to be ordered after all the other names in the domain. For example, [ZL] 0 represents a zone consisting of only a single node. and are two byte integers. , , , ..., have the syntax of domain names. To make an authenticated response of non existent node resides within 512 byte UDP packet, it is recommeded that the length of a single [ZL] record be shorter than 400 bytes, after limited domain name compression (those information available within the record itself only, may be shared for compression). , and are the same as that of [NSIG] except that the signature covers the byte stream of the sequence of ... contained in the [ZL] record itself. 4. Name Server Operation Changes to the operation of name servers is minimal. A primary name server of a zone has access to signature mechanisms of the zone and derives authenticated data from them. A secondary name server is configured with IP addresses of other name servers from which zone information is transferred. Secure zone transfer, protected by zone's key, may be used to detect that the primary server compromised and continue operation with older but secure data. The section "4.3.2. Algorithm" of RFC 1034 must be replaced with the following description: The actual algorithm used by the secure name server will depend on the local OS and data structures used to store RRs. The following algorithm assumes that the RRs are organized in several tree structures, one for each zone, and another for the cache: 1. Set or clear the value of recursion available in the response depending on whether the name server is willing to M. Ohta Expires on June 1, 1995 [Page 9] INTERNET DRAFT Simple Secure DNS November 1994 provide recursive service. If recursive service is available and requested via the RD bit in the query, go to step 5, otherwise step 2. 2. Search the available zones for the zone which is the nearest ancestor to QNAME. If such a zone is found, go to step 3, otherwise step 4. 3. Start matching down, label by label, in the zone. The matching process can terminate several ways: a. If the whole of QNAME is matched, we have found the node. If the data at the node contains a CNAME, and QTYPE doesn't match CNAME, copy the CNAME RR into the answer section of the response, change QNAME to the canonical name in the CNAME RR, and go back to step 1. Otherwise, copy all RRs which match QTYPE into the answer section and go to step 6. b. If a match would take us out of the authoritative data, we have a referral. This happens when we encounter a node with NS RRs marking cuts along the bottom of a zone. Copy the NS RRs for the subzone into the authority section of the reply. Put authenticated addresses available from authoritative data or the cache. If they are unavailable, use glue RRs, if they exists. Go to step 4. c. If at some label, a match is impossible (i.e., the corresponding label does not exist), look to see if a "*" label exists. If the "*" label does not exist, check whether the name we are looking for is the original QNAME in the query or a name we have followed due to a CNAME. If the name is original, set an authoritative name error in the response. Put at least one RR of ZL data containing the name being looked for in the additional section. If there are a lot of ZL data, truncation is expected. Exit. If the "*" label does exist, match RRs at that node against QTYPE. If any match, copy them into the M. Ohta Expires on June 1, 1995 [Page 10] INTERNET DRAFT Simple Secure DNS November 1994 answer section, but set the owner of the RR to be QNAME, and not the node with the "*" label unless the query type is of RRD. Put at least one RR of ZL data containing the name being looked for in the additional section. If there are a lot of ZL data, truncation is expected. Go to step 6. 4. Start matching down in the cache. If QNAME is found in the cache, copy all the RRs attached to it that match QTYPE into the answer section. If there was no delegation from authoritative data at 3.b, look for the best one from the cache, and put it in the authority section. Go to step 6. 5. Using the local resolver or a copy of its algorithm (see resolver section of this document) answer the query. Store the results, including any intermediate CNAMEs, in the answer section of the response. 6. Using local data only, attempt to add other RRs which may be useful to the additional section of the query. Exit. For secure zone transfer, new query types [SXFR] are added. The actual name and value of [SXFR] depends on the authentication mechanism used. It is assumed that each secondary server is statically configured with digest of ZA of a zone it serves. The TCP transport of a secure zone transfer meessage has the following structure. +------------------+ ^ | length | |d +------------------+ |i | | |g | | |e | zone message | |s | | |t | | |e +------------------+ vd ^ | timestamp | |s +------------------+ |i | expire | |g +------------------+ |n | digest | |e +------------------+ vd | signature | +------------------+ The secondary server extract [ZA] records which is just transferred, verify it with statically configured digest, and authenticate the M. Ohta Expires on June 1, 1995 [Page 11] INTERNET DRAFT Simple Secure DNS November 1994 signature of the transferred zone. Unlike AXFER, [SXFR] uses four bytes for zone data length to transfer large zones such as "com.". 5. Resolver 5.1 Client-Resolver Interface Client programs tells security requirements to the resolver. The requirement includes whether they need security or not and which digesting or signature mechanism they consider reliable. 5.2. Data Structures The resolver algorithm in the next subsection assumes that all functions have been converted to a general lookup function, and uses the following data structures to represent the state of a request in progress in the resolver: SNAME the domain name we are searching for. STYPE the QTYPE of the search request. SCLASS the QCLASS of the search request. SLIST a structure which describes the name servers and the zone which the resolver is currently trying to query. This structure keeps track of the resolver's current best guess about which name servers hold the desired information; it is updated when arriving information changes the guess. This structure includes the equivalent of a zone name, the known name servers for the zone, the known addresses for the name servers, [ZA] and [ZSIG] of the zone if the zone is secure, and history information which can be used to suggest which server is likely to be the best one to try next. The zone name equivalent is a match count of the number of labels from the root down which SNAME has in common with the zone being queried; this is used as a measure of how "close" the resolver is to SNAME. SBELT a "safety belt" structure of the same form as SLIST, which is initialized from a configuration file, and lists servers which should be used when the resolver doesn't have any local information to guide name server selection. The configuration file also contains information of ZA RRs the SBELT servers serves. The match count will be -1 to indicate that M. Ohta Expires on June 1, 1995 [Page 12] INTERNET DRAFT Simple Secure DNS November 1994 no labels are known to match. CACHE A structure which stores the results from previous responses. Since resolvers are responsible for discarding old RRs whose TTL has expired, most implementations convert the interval specified in arriving RRs to some sort of absolute time when the RR is stored in the cache. Instead of counting the TTLs down individually, the resolver just ignores or discards old RRs when it runs across them in the course of a search, or discards them during periodic sweeps to reclaim the memory consumed by old RRs. TTL for secure data should be shortened not to exceed its authenticated period. Data in the cache also contains a bit telling whether the resolver think the data is secure or not. In the CACHE, authenticated RR has precedence over unauthenticated RR. During authentication, data should be stored in the cache as unauthenticated. Later, if the data is proven to be secure, the bit is flagged. If the data is proven to be insecure, the data is flushed. 5.3 Resolver Algorithm Stub resolvers believes anything recursive resolvers returns through secure communication channel. For recursive resolvers, the four step algorithm in the section "5.3.3. Algorithm" of RFC 1034 must be replaced with the following: The top level algorithm has four steps: 1. See if the answer is in local secure information, and if so return it to the client. 2. Find the best servers to ask. 3. Send them queries until one returns a response. 4. Analyze the response, either: a. if the response answers the question or contains a name error, try to authenticate it, cache the data and other authentication information as well as returning the answer back to the client. b. if the response contains a better delegation to other servers, try to retrieve and authenticate ZSIG and ZA M. Ohta Expires on June 1, 1995 [Page 13] INTERNET DRAFT Simple Secure DNS November 1994 of the delegated zone. If the delegation information is authenticated, put it to local cache and go to step 2. c. if the response shows a CNAME and that is not the answer itself, try to authenticate the CNAME, cache the CNAME and other authentication information, change the SNAME to the canonical name in the CNAME RR and go to step 1. d. if the response shows a servers failure, an authentication failure or other bizarre contents, delete the server from the SLIST and go back to step 3. Authentication by resolvers are done as follows: 1. if the answer is in the authoritative data of a secure zone of a name server co-located with the resolver, no further authentication is necessary. 2. To authenticate RRD of ZA, use ZSIG and authenticated ZA of zone. 3. To authenticate ZA, use RRD of ZA. 4. To authenticate ZL, use authenticated ZA. 5. To authenticate RRD, use NSIG and authenticated ZA. 6. To authenticate other data types, use authenticated RRD. If the query for RRD returns wildcard, it should also be confirmed that there is no nodes exists to make the wildcard matching impossible. For example, if "a.b.c.d." matches "*.c.d." it should be confirmed that nodes "a.b.c.d." nor "b.c.d." does not exit but a wild card "*.c.d." exists. ZL which exists in the additional section should give the required authentication for non-existent nodes. 7. if the response is a name error, that is, a node which matches query does not exist, confirm it by authenticating ZL data in the additional section of the response. For example, to authenticate that data matching "a.b.c.d." dose not exist in a zone "c.d.", it should be confirmed that nodes "a.b.c.d." and "*.b.c.d" do not exist but "b.c.d." does exist. Depending on the zone's structure (whether "b.c.d." exists or not), the same thing may be confirmed by the fact that nodes "a.b.c.d.", "*.b.c.d", "b.c.d" and M. Ohta Expires on June 1, 1995 [Page 14] INTERNET DRAFT Simple Secure DNS November 1994 "*.c.d" do not exist. 8. if the response is a data not found error, that is, the query does not match any RR type of the node, retrieve all the authenticated RRD type records of the node and confirm that they don't contain RR types which matches the query. Authentication chains between zones have the following structure: digest ZA of well known signer zone------>digest value statically | configured in name | servers | signature ZSIG<---------RRD of ZA of signer zone | | | signature ZSIG<---------RRD of ZA of signer zone | | | signature ZSIG<----------RRD of ZA Figure 1. Authentication Chains of Zone Data Authentication chains within a zone have the following structure: ZA of the Node's Zone | | | signature NSIG<---------RRD of RR type RRD ^ |digest | RRD of RR type ^ |digest | RR with RR type M. Ohta Expires on June 1, 1995 [Page 15] INTERNET DRAFT Simple Secure DNS November 1994 other than RRD nor NSIG Figure 2. Authentication Chain of Node Data 5.4 Resolver Algorithm for Cross Authentication (Optional) Usually, recursive resolver traverses DNS tree in top down manner from the nearest ancestor (often, the root node) of the sought node down toward the leaf direction. The selection corresponds to the step 2. 2. Find the best server to ask. of the top level resolver algorithm in section 5.3. By introducing a new RR type: XSIG, it is possible to find the best server in a bottom up manner. XSIG has the following format: XSIG <[ZA]> where, is the variable length digest of <[ZA]> RR of zone. The value of XSIG is . Usually, is an ancestor of . Then, if a resolver is configured with static authentication information of , the resolver can reliably know the [ZA] information of zone. If zone also has XSIG, authentication may be chained up to the root zone. During the up sequence of authentication, XSIG may, only once, traverse the DNS tree, after which only the down sequence through NSIG (as described in step 4.b in section 5.3) is allowed. The algorithm to find the best server with terminology of the section 5.2 is as follows: 1. Start from a zone served by SBELT name servers. 2. If the zone has XSIG record with of the ancestor of the SNAME, the search has finished. 3. If the zone has XSIG record with of the ancestor of the zone itself, up the zone hierarchy and recursively continue the search at step 2. 4. If none of the conditions are met, try the next zone in the M. Ohta Expires on June 1, 1995 [Page 16] INTERNET DRAFT Simple Secure DNS November 1994 SBELT. If no zones are remaining, the search has failed. The use of the cross authentication scheme introduce some vulnerability but removes some, discussion on which is quite complex. There are also complex performance trade-offs. For example, even if an ancestor zone of SNAME is found in cache, the above steps must always be performed to find the nearest ancestor of SNAME, which is necessary for the security property of the cross authentication scheme. So, in this document, it's use is completely optional. 6. Secure Time and Secure DNS DNS is designed to be highly fault tolerant. That is, if a secondary server can't communicate with other servers, the secondary server can behave as authoritative until SOA period is reached. Thus, until a resolver securely knows that period has passed, a name server may give old but authenticated answer to a query whose node does not exist. Thus, period should be minimized. Moreover, clocks of signers and resolvers should be accurate enough. It is recommended that signers clock should have maximum allowable error of /20. When resolvers caching information, it should be confirmed that cached period is shorter than and *19/20 fractions rounded down minus the expected maximum error of the resolvers' clocks. Due to clock skew, a resolver may receive a dated in the future. The data should be relied if the error is below /10 fractions rounded down plus the expected maximum error of the resolver's clocks. To have an Internet wide upper bound on the life time of stale data, longer than a week should be shortened to a week. 7. Secure DNS and Additional Section Processing To authenticate DNS reply on a certain node, a lot of information about the node is necessary. Such information may be provided in the additional section. On the other hand, though the existing DNS suggests to add various information in the additional section, data on nodes which is not queried needs, such as additional As for MX, are not so useful if they can't be authenticated. Thus, for secure DNS, it is recommended to add additional information with the following preference as long as the addition won't make the M. Ohta Expires on June 1, 1995 [Page 17] INTERNET DRAFT Simple Secure DNS November 1994 reply longer than 512 bytes. [ZL] data for protection against denial of service attacks. glue A records for referral. additional information on the queried node. other additional information. 8. Specification of a Secure DNS Architecture To specify secure DNS, a standard track RFC(s) must be provided which specify a mechanism for digesting a mechanism for signature RR type values for [RRD], [NSIG], [ZA], [ZSIG], [ZL], [ZA], [ZSIG] and [SXFR] [RRD], [NSIG], [ZA], [ZSIG], [ZL] and [SXFR] sharing the same value of X form a single set of specification. Even if two specifications share the same digesting or signature mechanism, they have different [RRD] or [NSIG] values. 9. References [RFC1034] [RFC1035] [SECIP] Security Considerations The entire document is devoted on a security issue to make answers from DNS authenticated over unreliable transport mechanisms. No confidentiality is considered. Author's Address Masataka Ohta Computer Center Tokyo Institute of Technology M. Ohta Expires on June 1, 1995 [Page 18] INTERNET DRAFT Simple Secure DNS November 1994 2-12-1, O-okayama, Meguro-ku Tokyo 152, JAPAN Phone: +81-3-5734-3299 Fax: +81-3-5734-3415 EMail: mohta@necom830.cc.titech.ac.jp M. Ohta Expires on June 1, 1995 [Page 19]