Received: from sol.tis.com by magellan.TIS.COM id aa17271; 2 May 94 13:37 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA04920; Mon, 2 May 94 13:36:44 EDT Received: by relay.tis.com; id AA11260; Mon, 2 May 94 13:38:06 EDT Received: from atc.boeing.com(130.42.28.80) by relay via smap (V1.3mjr) id sma011245; Mon May 2 13:37:17 1994 Received: by atc.boeing.com (5.57) id AA28916; Mon, 2 May 94 10:38:17 -0700 Received: from commanche.ca.boeing.com by splinter.boeing.com with SMTP (16.6/16.2) id AA01274; Mon, 2 May 94 10:38:03 -0700 Received: by commanche.ca.boeing.com (AIX 3.2/UCB 5.64/4.03.TLDavis.AIX_3.2.5) id AA25873; Mon, 2 May 1994 10:36:13 -0700 Message-Id: <9405021736.AA25873@commanche.ca.boeing.com> To: dee@skidrow.lkg.dec.com Cc: dns-security@tis.com Subject: Re: SIPP Routing Header & security & Re: DNS security draft In-Reply-To: (Your message of Wed, 27 Apr 94 17:15:20 D.) <9404272115.AA04728@skidrow.lkg.dec.com> Date: Mon, 02 May 94 10:36:13 -0800 From: "Terry L. Davis P.E., Boeing Computer Services, Bellevue, WA" Donald Donald you responded: > >> Whatever algoritm is chosen, the people who want to interoperate will > >> all have to speak it. Everyone knows you will need a method to roll > >> over to a new algorithm when / if that is necessary. > >> > >As I responded to "Ted Ts'o", I have no problem with a "default > >algorithm", but I see no way to incorporate any alternative algorithm > >into DNS or to "roll over to a new algorithm" as the draft is currently > >written. > > I'll fix that. > Many thanks, that meets my concerns! Take care | Terry L. Davis | Boeing Computer Services, Bellevue, WA | | 206-957-5325 | BOEING EMAIL: tld5032@commanche.ca.boeing.com. | | INTERNET EMAIL: tld5032@atc.boeing.com. | --------------- Monday May 02,1994 10:35 AM PDT ------------- == As always, the above cannot be construed as representing BOEING, == == the thoughts, comments, and ideas contained herein are mine alone! ==   Received: from sol.tis.com by magellan.TIS.COM id aa15018; 5 May 94 13:29 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA19521; Thu, 5 May 94 13:28:31 EDT Received: by relay.tis.com id AA06764; Thu, 5 May 94 13:29:07 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma006759; Thu May 5 13:28:56 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA18409; Thu, 5 May 94 10:24:58 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA03019; Thu, 5 May 1994 13:26:50 -0400 Message-Id: <9405051726.AA03019@skidrow.lkg.dec.com> To: dns-security@tis.com Subject: Re: DNS security draft In-Reply-To: Your message of "Sat, 23 Apr 94 00:08:31 +0200." <9404221508.AA20758@necom830.cc.titech.ac.jp> Date: Thu, 05 May 94 13:26:50 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: Masataka Ohta To: mohta@necom830.cc.titech.ac.jp (Masataka Ohta) Cc: dee, dns-security@tis.com In-Reply-To: <9404221355.AA20519@necom830.cc.titech.ac.jp>; from "Masataka Ohta" at Apr 22, 94 10:54 pm >A minor improvement. MD5 signature of the zone's public key is enough >for boot files and for referral information. > Masataka Ohta > >PS > >May we assume MD5 is unforgeable forever? I don't think so. That's why the original proposal was for the Secure Hash Algorithm which produces a 160 bit hash and when the Working Group decided to cut back to MD5, Charlie and I strengthened the hashes inside the SIG by making them change more often. If the US NSA thinks 160 bits are needed, I would hesitate to contradict them in such a narrow technical matter. By the way, you should note that the US NIST has recently announced that a flaw was found in SHA making it weaker than originally thought. The will be announcing a new hash function at some point. That it took NSA this long to find this flaw in SHA certainly implies there could be lurking problem in any of the MD* algorithms. Donald   Received: from sol.tis.com by magellan.TIS.COM id aa25531; 7 May 94 14:19 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA00488; Sat, 7 May 94 14:03:01 EDT Received: by relay.tis.com id AA00212; Sat, 7 May 94 14:03:40 EDT Received: from unknown(144.110.16.11) by relay via smap (V1.3mjr) id sma000200; Sat May 7 14:03:21 1994 Received: from squid.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA19429 (5.65c/IDA-1.4.4/DIT-1.3 for dns-security@tis.com); Sat, 7 May 1994 22:13:24 +1000 Message-Id: <199405071213.AA19429@shark.mel.dit.csiro.au> To: dns-security@tis.com Subject: Thoughts on DNS security draft: Multi-key domains Date: Sat, 07 May 1994 22:13:03 +1000 From: Bob Smart There seem to be two reasons why a zone or domain might want to have more than one key at a given point of time. 1. We are changing from an old key to a new one (perhaps bigger) and we want both to be valid for a while. 2. We want to have two keys which are administered separately and valid records will be signed by both. The simple way to handle this is to add an extra field for the RR saying how many signatures are necessary for validity. To take the most confusing case: a.b.c. IN RSA 1 xxx... (old key, still valid with one sig) IN RSA 2 yyy... (new key now valid but not alone) IN RSA 2 zzz... (other new key must be used with the yyy key for validity). Written signatures for organizations and for important functions within organizations frequently require multiple signatures and we should allow for this with digital signatures. For example we could then set it up so that the root zone is not dependant on the security of one person/organization/location. Bob Smart   Received: from sol.tis.com by magellan.TIS.COM id aa25537; 7 May 94 14:19 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA00476; Sat, 7 May 94 14:02:01 EDT Received: by relay.tis.com id AA00203; Sat, 7 May 94 14:02:40 EDT Received: from unknown(144.110.16.11) by relay via smap (V1.3mjr) id sma000193; Sat May 7 14:01:41 1994 Received: from squid.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA19877 (5.65c/IDA-1.4.4/DIT-1.3 for dns-security@tis.com); Sat, 7 May 1994 23:12:28 +1000 Message-Id: <199405071312.AA19877@shark.mel.dit.csiro.au> To: dns-security@tis.com Subject: Thoughts on DNS security draft: new protocol? Date: Sat, 07 May 1994 23:12:10 +1000 From: Bob Smart The DNS security draft is a brilliant application of public key cryptography. However it is rather complex. I have the vague feeling that things would be a lot simpler if secure access to the DNS was a different protocol. The DNS and secure-DNS would return the same information. However there would be no SIG RRs. Secure-DNS would only work for the parts of the DNS that have keys and it would always return everything either signed or packed within a signature as in the current clever proposal. There is no problem deciding which protocol to use. For example if we want to query the NS that is responsible for xyz.com.au then we know whether we can use secure-DNS by whether the com.au domain has an RSA key for xyz.com.au. [It seems natural for parent zones to include the RSA RRs of subordinate domains since the parent domain has to sign those keys.] The secure-DNS protocol could have some new desirable features: 1. Use a reliable query-response protocol like Prospero's ARDP, or the proposed compacted TCP. 2. Have the ability to return a signed list of all the immediate sub-domains of a domain to allow a cached and secure NXDOMAIN. 3. Use expiration times instead of TTLs. The last implies a secure time service but we depend on that anyway. Bob Smart   Received: from sol.tis.com by magellan.TIS.COM id aa27368; 8 May 94 9:18 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA16163; Sun, 8 May 94 09:17:31 EDT Received: by relay.tis.com id AA01924; Sun, 8 May 94 09:18:11 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma001922; Sun May 8 09:17:36 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sun, 8 May 94 22:11:37 +0900 From: Masataka Ohta Return-Path: Message-Id: <9405081311.AA01464@necom830.cc.titech.ac.jp> Subject: Re: DNS security draft To: "Donald E. Eastlake 3rd" Date: Sun, 8 May 94 22:11:35 JST Cc: dns-security@tis.com In-Reply-To: <9405051726.AA03019@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at May 5, 94 1:26 pm X-Mailer: ELM [version 2.3 PL11] >A minor improvement. MD5 signature of the zone's public key is enough >for boot files and for referral information. During the 10 days of vacation, I have reread RFC 103[45]. I now better understand DNS and noticed that we don't have to modify referral information. Doing so won't make DNS any more secure. It is quite natural that protection of non-authoritative data of a zone is not necessary. I have also find a difficulty of handling CNAME. Currently, it is not possible to have a node which has both CNAME and other RR type. But, the only natural way to make CNAME secure, it seems to me, is to add some signature information to the node of CNAME. So, I think we need a new OPCODE (RD=0 is useless) to suppress CNAME processing. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa27420; 8 May 94 9:45 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA16349; Sun, 8 May 94 09:44:31 EDT Received: by relay.tis.com id AA01997; Sun, 8 May 94 09:45:12 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3mjr) id sma001995; Sun May 8 09:45:04 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sun, 8 May 94 22:39:20 +0900 From: Masataka Ohta Return-Path: Message-Id: <9405081339.AA01709@necom830.cc.titech.ac.jp> Subject: Re: SIPP Routing Header & security & Re: DNS security draft To: Greg Minshall Date: Sun, 8 May 94 22:39:18 JST Cc: dns-security@tis.com In-Reply-To: <9404281544.AB14056@WC.Novell.COM>; from "Greg Minshall" at Apr 28, 94 8:44 am X-Mailer: ELM [version 2.3 PL11] > >Secure DNS is now being deeveloped so that a zone, not a host in general, > >will have a key. > > The Eastlake/Kaufmann scheme allows zones, hosts, even users, to have > (public) keys. So? What Teodole said was: : With RSA, the keys that are used for secure DNS can also be used to : establish secure data exchange keys for encryption purposes. We are talking about actual key values, not the way to specify them. It is, of course, crazy to share a secret key of a zone by all the hosts in the zone. > >I know. But it will expire 1997, much earlier than 2000. > > Three years == (approximately) three days, in my humble opinion, in this > area. (Words of the form likely to come back and haunt one...) Three days is much shorter and, thus, better than three years, isn't it? Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa00461; 9 May 94 9:05 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA08089; Mon, 9 May 94 09:05:06 EDT Received: by relay.tis.com id AA04017; Mon, 9 May 94 09:05:48 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma004015; Mon May 9 09:05:43 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA26012; Mon, 9 May 94 06:00:50 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA23779; Mon, 9 May 1994 09:02:45 -0400 Message-Id: <9405091302.AA23779@skidrow.lkg.dec.com> To: Bob Smart Cc: dns-security@tis.com Subject: Re: Thoughts on DNS security draft: new protocol? Multi-key domains In-Reply-To: Your message of "Sat, 07 May 94 23:12:10 +1000." <199405071312.AA19877@shark.mel.dit.csiro.au> Date: Mon, 09 May 94 09:02:45 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Bob, From: Bob Smart To: dns-security@tis.com >The DNS security draft is a brilliant application of public >key cryptography. However it is rather complex. I'm beginning to feel that some of the complexity may not be necessary. Perhaps, as suggested by Ohta-san, being able to split a set of direct RR signets across multiple SIG RR's isn't important enough for the complexity it adds. But in Seattle, the working group wanted that left in until there is real operational experience, so I plan to leave it there for the time being. >I have the vague feeling that things would be a lot simpler >if secure access to the DNS was a different protocol. The >DNS and secure-DNS would return the same information. However >there would be no SIG RRs. The world is always much simpler if you can ignore the installed base. If you design a new protocol you are throwing away the enormous installed base of DNS servers. The basic features of the secure dns proposal permit it to be deployed with only minor modifications to primaries, so they can read in the new RR's. No change at all are needed in secondaries or caching servers. And only those resolvers and applications that want to be security aware need be modified. Second, if you are going to the upheaval of a new protocol, there are a *lot* of things you want to do, including greater flexibility and options, stuff related to larger UDP packets, incremental zone transfer, dynamic update, etc. (See draft-ietf-dns-ixfr-*.txt and my moderately recent message to the Namedroppers mailing list and other discussion there.) A new protocol framework to provide for this would be great but dns security is needed yesterday and I don't think it should wait for upgrading all servers that might serve up a secured zone. >Secure-DNS would only work for the parts of the DNS that >have keys and it would always return everything either signed >or packed within a signature as in the current clever proposal. > >There is no problem deciding which protocol to use. For example >if we want to query the NS that is responsible for xyz.com.au >then we know whether we can use secure-DNS by whether the com.au >domain has an RSA key for xyz.com.au. [It seems natural for >parent zones to include the RSA RRs of subordinate domains >since the parent domain has to sign those keys.] [In the next version of the draft, I plan to rename the RSA RR to be the KEY RR.] You can't actually tell if a zone is secure without looking at the mode bits in the KEY RR which is in it's superzone (or some local configuration information). That KEY RR could be missing or could say the inferior zone has no key or could say that it has a key and might optionally be using it or could say that it has a key and will always use it. Only in the last case do you know the zone is secure. But: What is this "the NS responsible for ...". Zones have multiple name servers plus sometimes unregistered secondaries. Knowing that a zone is secure in the current proposal has nothing to do with whether all of its servers are security aware and even its primary need only be minimally compliant. In some environments, a security aware resolver or application may not be able to get at any of the NS's for a zone and have to depend on local non-security aware caching servers, etc. How is that going to work unless all these are replaced with servers speaking your new protocol? >The secure-DNS protocol could have some new desirable features: > > 1. Use a reliable query-response protocol like Prospero's ARDP, > or the proposed compacted TCP. There is usually a *lot* of overhead associated with reliability. I don't know about ARDP or compacted TCP but just going to regular TCP *triples* the number of packets and is unacceptable to high volume DNS servers. The resources used at the servers, the additional delay in getting answer, etc., all speak strongly against using a reliable transport. > 2. Have the ability to return a signed list of all the immediate > sub-domains of a domain to allow a cached and secure NXDOMAIN. See following messages res NX... > 3. Use expiration times instead of TTLs. Yes, if you are going to a new protocol, you could drop TTLs and could provide the same facilities with times. >The last implies a secure time service but we depend on that >anyway. > >Bob Smart To: Bob Smart cc: dns-security@tis.com Subject: Re: Thoughts on DNS security draft: Multi-key domains In-reply-to: Your message of "Sat, 07 May 94 22:13:03 +1000." <199405071213.AA19429@shark.mel.dit.csiro.au> -------- From: Bob Smart To: dns-security@tis.com >There seem to be two reasons why a zone or domain might >want to have more than one key at a given point of time. > >1. We are changing from an old key to a new one (perhaps > bigger) and we want both to be valid for a while. > >2. We want to have two keys which are administered separately > and valid records will be signed by both. > >The simple way to handle this is to add an extra field for >the RR saying how many signatures are necessary for validity. >To take the most confusing case: > > a.b.c. IN RSA 1 xxx... (old key, still valid with one sig) > IN RSA 2 yyy... (new key now valid but not alone) > IN RSA 2 zzz... (other new key must be used with > the yyy key for validity). [In the next draft I plan to rename RSA RR to be KEY RR.] This is an interesting idea. And I don't think adding a byte for this to the KEY RR would cost that much. But it does add significant complexity to any security aware resolver. The DNS organization, with a single primary per zone, would seem somewhat philosophically opposed to this. I'm inclined to think the additional complexity would not be worth it. >Written signatures for organizations and for important functions >within organizations frequently require multiple signatures and >we should allow for this with digital signatures. For example we >could then set it up so that the root zone is not dependent on >the security of one person/organization/location. Well, I'm not sure that going to two signatures would help all that much. Who would the two signnatories for root be? And going for more than two will quickly lead to UDP packet overflow with medium size keys. Even two signatures can easily cause UDP overflow with big keys. >Bob Smart Donald   Received: from sol.tis.com by magellan.TIS.COM id aa00642; 9 May 94 11:12 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13514; Mon, 9 May 94 11:12:13 EDT Received: by relay.tis.com id AA04553; Mon, 9 May 94 11:12:55 EDT Received: from mitsou.inria.fr(138.96.24.84) by relay via smap (V1.3mjr) id sma004546; Mon May 9 11:12:24 1994 Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA24836; Mon, 9 May 1994 17:09:48 +0200 Message-Id: <199405091509.AA24836@mitsou.inria.fr> To: "Donald E. Eastlake 3rd (Beast)" Cc: Bob Smart , dns-security@tis.com Subject: Re: Thoughts on DNS security draft: new protocol? Multi-key domains In-Reply-To: Your message of "Mon, 09 May 1994 09:02:45 EDT." <9405091302.AA23779@skidrow.lkg.dec.com> Date: Mon, 09 May 1994 17:09:48 +0200 From: Christian Huitema Donald, It have waited quite a long time before mixing in this discussion. Please find enclosed my comments on your draft. The current draft places the signatures in a "SIG" record, which is stored under the entry itself in the "Internet" class. A SIG RR contains "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), some flags, and an RSA (Rivest, Shamir, and Adelman [RSA]) signature." The scheme used for associating the actual record with its signature is not excatly simple - using the term "convoluted" would not be excessive. The RSA encrypted data may contain: * either the "RR" itself (but then, how is it keyed?) * or a message digest of the resource record. One may note a small problem with this scheme: there is no way to get the exact SIG associated to a particular RR through the "normal" DNS access procedure. One will have to retrieve all SIGs, decode the RSA data, perform a pattern matching... not a very desirable procedure. This leads the DNS-SEC authors to design an "updated" or "security conscious" version of the DNS protocol, that use some internal magic to keep the association between data and signatures. I propose to use the "class" mechanism to overcome this problem. The normal insecure data will be store as usual as IN (Internet) class records. The corresponding signatures will be signed as parallel records in a new class, says INSECT (Internet security). A standard DNS query in class IN for a record type A will get all type A RRs; a standard DNS query in class INSECT for a record type A will get the signature of these records, as well as the record value in the "additional" section if that is necessary. The RSA/KEY record will remain in the IN domain. A corresponding signature will be placed in the SIG domain. The format of the signatures should be independant of the particular record type. In fact, one could very much use your current specification. I would just add a more precise definition of the hashing function, so that one could parameter one of the following: 1) Hash with MD5 2) Hash with something else 3) Don't hash, the data are passed in the clear as a succession of RVALUEs Plus also an ordering of the RR values, e.g. by ascending binary order. That way you will keep your possibility of not sending the clear text if "RSA" is used in conjunction with "don't hash". But you will also always guarantee that all RR are signed with exactly one signature. If we are space conscious, we may want to make the signer's ID optional in the SIG. Maybe define a "potential signer" RR that has a 32 bits ID + a name, and only repeat the 32 bits ID in the message. Or provide a default encoding for "the entry itself", "the zone owner"... Christian Huitema   Received: from sol.tis.com by magellan.TIS.COM id aa01585; 9 May 94 14:57 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13741; Mon, 9 May 94 14:57:34 EDT Received: by relay.tis.com id AA06190; Mon, 9 May 94 14:58:16 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma006186; Mon May 9 14:57:29 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA20099; Mon, 9 May 94 11:51:39 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA06054; Mon, 9 May 1994 14:53:35 -0400 Message-Id: <9405091853.AA06054@skidrow.lkg.dec.com> To: Masataka Ohta Cc: dns-security@tis.com Subject: Re: Authenticated NXDOMAIN response In-Reply-To: Your message of "Fri, 22 Apr 94 21:44:55 +0200." <9404221245.AA20257@necom830.cc.titech.ac.jp> Date: Mon, 09 May 94 14:53:35 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Ohta-san, Charlie and I talked a little be about this sort of thing but at the time it seemed a bit too complicated and it didn't seem worth it to block this particular denial of service attack when there were various other denial of service problems that you couldn't fix. But I've been thinking about this more, prompted by your message. There are a variety of ways you could add authenticated NX information to secure DNS. Taking the current dns security proposal as the most lax of these (no NX name info), you could go all the way to one that comletely mapped just what combinations of name and type did or didn't exist. However to be very stringent would be more complicated and tend to block some types of dynamic update. Still it would be very nice to be able to authoritatively know in, for example, the .com domain, that some name definitely existed or didn't exist. Thinking about all this also lead me to the conclusion that a little more is necessary to do right by wildcard RRs. Anyway, right after this message, I'll post a separate message with my current thoughts on NX & wildcard. From: Masataka Ohta To: dns-security@tis.com X-Mailer: ELM [version 2.3 PL11] >If a list of all the names in a zone is available, authenticated NXDOMAIN >is easy. But it is unrealistic to extract such lengthy information. > >So, how is the following idea to make NXDOMAIN response authenticated? > >Have the following new RR type: XD (eXisting Domains) > > XD ... > >where is the neggative cache period, , ... are >all the domain names within the zone (including the toplevel name of child >zones) which is located between and with some dictionary >order. covers the data of the record (not all the XD records) >signed by the zone's key. > >Then, to authenticate that some domain does not exist, an XD (not >necessarily all the XDs) containing the queried domain between >and should be added in the additional section. I don't like having these RRs all dangle out of the zone name or that that individual XD RRs could be huge. >As there should be a lot of XD, the additional section should almost >always be truncated, even if the query is by TCP. > >For example, if "com." zone contains only the following three domains >beginning with "b": > > bar.com. > bizzare.com. > buzz.com. > >XD for them will be > >com. XD 3600 b.com. c.com. bar.com. bizzare.com. buzz.com. > >Then, a query for "best.com." will fail with authentication. > >To authenticate "foo.bar.com." does not exist, it is further necessary >to confirm NS for "bar.com" does not exist. > > Masataka Ohta Donald   Received: from sol.tis.com by magellan.TIS.COM id aa01587; 9 May 94 14:57 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13740; Mon, 9 May 94 14:57:34 EDT Received: by relay.tis.com id AA06191; Mon, 9 May 94 14:58:15 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma006187; Mon May 9 14:57:38 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA20241; Mon, 9 May 94 11:53:47 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA06141; Mon, 9 May 1994 14:55:43 -0400 Message-Id: <9405091855.AA06141@skidrow.lkg.dec.com> To: dns-security@tis.com Subject: Thought on non-existant and wildcarded names Date: Mon, 09 May 94 14:55:42 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp This is what I came up with and am thinking of merging into the next draft: INTERNET-DRAFT DNS Protocol Security Extensions Domain Name Protocol Security Extensions W. Special Handling of Wildcard Matches and Non-existence DNS security provides the means for establishing integrity and data origin authenticity. However, this applies only to actual RRs in a secured zone. There are two places where would be insufficient without some additional steps. The first case is securely indicating the absence of data. The other is the that of wildcard RRs. Wildcard RRs have node names whose first label is an asterisk ("*"). These act as instructions for synthesizing RRs not actually present. Since there are an enormous number of possible DNS names, it is impossible to create and sign separate existence RRs for all possible wildcard matches or denial RRs for all possible queries for non-existent data. These are handled securely as described below. The following example zone is used in this section: FOO. IN SOA QQ.FOO. admin.QQ.FOO. ( 60 ; serial 7200 ; refresh 600 ; retry 1000000 ; expire 60 ; minimum ) NS QQ NS X.BAR MX 10 A1 MX 99 QQ A1 A 192.0.2.252 A 192.245.52.250 MX 10 A1 MX 99 QQ X.BAR A 192.0.2.253 A 192.245.52.249 MX 10 X.BAR MX 80 Y.Z.BAR Y.Z.BAR A 192.245.52.248 MX 10 Y.Z.BAR MX 80 Z.BAR Donald E. Eastlake 3rd & Charles W. Kaufman [Page 1] INTERNET-DRAFT DNS Protocol Security Extensions *.BAR MX 10 Y.Z.BAR MX 80 X.BAR QQ A 192.0.2.254 MX 10 QQ MX 50 A1 W.1 Wildcard RR Matches The Domain Name System contains a provision for RRs that match any name below a point in the name tree unless a more specific name matches. (See section 4.3.3 in RFC 1034.) For example, in zone FOO, there is an RRs named *.BAR.FOO and also more specifiec RRs with names X.BAR.FOO and Y.Z.BAR.FOO. The wildcard RRs with name *.BAR.FOO can be though of as instructions for synthesizing RRs with matching names and the same class, type, TTL, and RDATA, when a matching query arrives. If a type MX query is made to zone FOO as above for Z.BAR.FOO, it will match the wildcard RR and not any of the more specific RRs. So a response will be made with the queried name (Z.BAR.FOO) substituted for the wildcard name (*.BAR.FOO). On the other hand, a query for X.BAR.FOO or Z.BAR.FOO or anything below them will ignore the wildcard and either respond with the specific RR or a non-existent name response. Queries for xx.FOO, where xx is any label but BAR, will be unaffected by the wildcard. A wildcard is frequently used for such purposes as causing mail to a large class of name to be sent to a particular set of mail gateways by using wildcard MX RRs. Wildcard RRs are signed by SIG RRs with the same wildcard name and the signature is based on the wildcard name. To make it possible to verify the signature, the SIG RR has a LABELS field which gives the number of actual labels in its name, above the wildcard *, if there is one, not counting the null label for root. If the actual number of labels present in the RR name equals the LABELS field, then no wildcard is involved. If the actual number of labels present is larger, then an * can be temporarily substituted for the synthesized part of the name to verify the signature. If a wildcard RR has been supressed because it appears inside a SIG on a request for a security aware resolver to a security aware server, the resolver has to do the wildcard expansion. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 2] INTERNET-DRAFT DNS Protocol Security Extensions W.2 Non-existent Types When a secure query is made for a name and class that exist is a zone, but for an RR type that does not exist, there needs to be a secure way to know that the type does not exist. This can be determined by retrieving and examining all the SIG RRs. All types will be indicated within the SIGs and the partial RR set signets in the SIGs can be used to assure that a complete set of SIGs has been retrieved. Thus a query from a security aware resolver for a name that exists for some RR in a zone but not as the owner of any RR of the requested type should be answered by a security aware server with the usual error but with all the SIGs for that name as additional information. W.3 Nonexistent Names The nonexistence of a name in a zone is indicates by the NX resource RR for a name interval containing the nonexistent name. An NX RR is returned in the additional information section, along with the error, if the client is security aware. NX RRs can also be returned if an explicit query is made for the NX type. The existence of NX records means that any query for any name to a security aware server serving a secure zone should result in an reply containing at least one signed RR. W.3.1 The NX Resource Record The NX resource record is used to securely indicate that no RRs with an owner name in a certain name interval exist in a domain (or that any specific names in that interval are masked by a wildcard). The owner name of the NX RR is an existing name in the zone. It's RDATA is another existing name in the zone. The presence of the NX 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. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 3] INTERNET-DRAFT DNS Protocol Security Extensions There is a slight problem with the last NX in a zone as it wants to have an owner name which is the last existing name is 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 NX. There are additional complexities due to interaction with wildcards as explained below. The NX RRs for a zone can be automatically calculated and added to the zone by the same recommended off-line process that signs the zone. The NX RRs TTL should not exceed the zone minimum TTL. The type number for the NX RR is xxx. W.3.2 NX RDATA format The RDATA for an NX 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 / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ W.3.3 Interaction of NX RRs and Wildcard RRs As a wildcard RR causes all possible names in an interval to exist, there should not be an NX record that would cover any part of this interval. Thus if *.X.ZONE exists you would expect an NX 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 NX for the interval following is simply given the owner name *.X.zone. This "*" type name is not expanded when the NX is returned as additional information in connection with a query for a non-existent name. If there could be any wildcard RRs in a zone and thus wildcard NXs, care must be taken in interpreting the results of explicit NX 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 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 4] INTERNET-DRAFT DNS Protocol Security Extensions in the internal. The server can just falsely return the wildcard match instead of the more specificly named RRs. If there is a zone wide wildcard, there will be only one NX 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 NX 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 very difficult. See Section xxx. Below is the sample zone given above with NX RRs added. FOO. IN SOA QQ.FOO. admin.QQ.FOO. ( 60 ; serial 7200 ; refresh 600 ; retry 1000000 ; expire 60 ; minimum ) NS QQ NS X.BAR MX 10 A1 MX 99 QQ NX A1 A1 A 192.0.2.252 A 192.245.52.250 MX 10 A1 MX 99 QQ NX BAR X.BAR A 192.0.2.253 A 192.245.52.249 MX 10 X.BAR MX 80 Y.Z.BAR ; no NX, covered by *.BAR Y.Z.BAR A 192.245.52.248 MX 10 Y.Z.BAR MX 80 Z.BAR ; no NX, covered by *.BAR *.BAR MX 10 Y.Z.BAR MX 80 X.BAR NX QQ QQ A 192.0.2.254 MX 10 QQ MX 50 A1 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 5] INTERNET-DRAFT DNS Protocol Security Extensions NX FOO. W.3.4 Blocking NX Pseudo-Zone Transfers In a secure zone, a resolver can query for the initial NX associated with the zone name. Using the RDATA field from that RR, it can query for the next NX RR. By repeating this, it can walk through all the NXs 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 NX 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. If it is desired to block NX 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 NX 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 NX 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 6]   Received: from sol.tis.com by magellan.TIS.COM id aa01808; 9 May 94 15:44 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA18593; Mon, 9 May 94 15:44:38 EDT Received: by relay.tis.com id AA06717; Mon, 9 May 94 15:45:20 EDT Received: from fnal.fnal.gov(131.225.9.1) by relay via smap (V1.3mjr) id sma006715; Mon May 9 15:44:24 1994 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HC50KOA72O001DYE@FNAL.FNAL.GOV>; Mon, 9 May 1994 14:44:06 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1) id AA03684; Mon, 9 May 94 14:43:15 CDT Date: Mon, 09 May 1994 14:43:15 -0500 From: Matt Crawford Subject: Re: Thoughts on DNS security draft: new protocol? Multi-key domains In-Reply-To: Your message of Mon, 09 May 94 17:09:48 +0100. <199405091509.AA24836@mitsou.inria.fr> To: dns-security@tis.com Message-Id: <9405091943.AA03684@munin.fnal.gov> Content-Transfer-Encoding: 7BIT Christian Huitema says: > I propose to use the "class" mechanism to overcome this problem. The > normal insecure data will be store as usual as IN (Internet) class > records. The corresponding signatures will be signed as parallel records > in a new class, says INSECT (Internet security). The fact that different classes are delegated independently has some interesting implications. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab   Received: from sol.tis.com by magellan.TIS.COM id aa02587; 9 May 94 18:30 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA02087; Mon, 9 May 94 18:30:52 EDT Received: by relay.tis.com id AA08201; Mon, 9 May 94 18:31:35 EDT Received: from decvax.zk3.dec.com(16.140.0.3) by relay via smap (V1.3mjr) id sma008197; Mon May 9 18:31:22 1994 Received: from alpha.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA24794; Mon, 9 May 1994 18:31:11 -0400 Received: from localhost by alpha.zk3.dec.com; (5.65/1.1.8.2/05May94-1225PM) id AA01213; Mon, 9 May 1994 18:31:10 -0400 Message-Id: <9405092231.AA01213@alpha.zk3.dec.com> To: smart@mel.dit.csiro.au Cc: dns-security@tis.com, kaufman@zk3.dec.com Subject: Re: Thoughts on DNS security draft: Multi-key domains Date: Mon, 09 May 94 18:31:09 -0400 From: kaufman@zk3.dec.com X-Mts: smtp >2. We want to have two keys which are administered separately > and valid records will be signed by both. > >The simple way to handle this is to add an extra field for >the RR saying how many signatures are necessary for validity. >To take the most confusing case: Generally, I'm concerned that this proposal costs code in all resolvers for a scenario that is extremely unlikely. But the proposal led me to think of a hack that I couldn't resist sharing. [And I confess I could have the cryptographic details wrong and if so I'm sure someone out there will embarrass me]. RSA is generally used with two keys: a public key and a private key. Each key consists of an exponent and a (shared) modulus. If you can factor the modulus, you can compute one exponent from the other. Otherwise you can't. It would be possible to do RSA using three keys: two private keys and a public key. The operation of the private keys (in either order) would reverse the operation of the public key, so both private keys would be needed to compute signatures and both would be needed to decrypt data. [You just need to find d, d', and e such that d*d'*e = 1 mod((p-1)*(q-1)).] This means that you might be able to implement the "dual controls" you want above with no changes to the DNS syntax at all! (Which I'll confess is the reason it appeals to me). The public key operates no differently than any other RSA public key. I believe it could even be extended to handle "this key or these two or these three may sign", though I'd want to review the literature before promising that feat. The only real problem is that there is an exposure at key generation time where d and d' will be known by a single entity. This information could exist only for a short time in a controlled environment and destroyed. It also means that the signing operation could not be as fast, but performance is not likely to be crucial in an environment this paranoid. --Charlie (kaufman@zk3.dec.com)   Received: from sol.tis.com by magellan.TIS.COM id aa03126; 10 May 94 4:38 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA09214; Tue, 10 May 94 04:38:14 EDT Received: by relay.tis.com id AA09719; Tue, 10 May 94 04:38:57 EDT Received: from unknown(131.112.4.4) by relay via smap (V1.3mjr) id sma009717; Tue May 10 04:38:38 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 10 May 94 17:31:22 +0900 From: Masataka Ohta Return-Path: Message-Id: <9405100831.AA08326@necom830.cc.titech.ac.jp> Subject: Re: Thought on non-existant and wildcarded names To: "Donald E. Eastlake 3rd" Date: Tue, 10 May 94 17:31:20 JST Cc: dns-security@tis.com In-Reply-To: <9405091855.AA06141@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at May 9, 94 2:55 pm X-Mailer: ELM [version 2.3 PL11] > This is what I came up with and am thinking of merging into the next draft: > W. Special Handling of Wildcard Matches and Non-existence Handling of wildcards are surely an issue to be protected against denial of service attack. > W.3 Nonexistent Names > > The nonexistence of a name in a zone is indicates by the NX resource RR > for a name interval containing the nonexistent name. Unlike EXD, your scheme with NX is not appropriate for referral. > 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 > instead of the more specificly named RRs. If there is a zone wide > wildcard, there will be only one NX 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 NX feature, taking into account the types of RRs that did > not exist in a name interval, and the like, which would eliminate this > possibility. I'm afraid you don't understand scope rules of wildcards. It has nothing to do with RR types. To securely claim that aaa.xxx.yyy.zzz.com. matches a wildcard "*.com", it is necessary and sufficient to securely prove that the zone does not contain nodes: zzz.com. yyy.zzz.com. xxx.yyy.zzz.com. aaa.xxx.yyy.zzz.com. > But it would be more complex and would be so constraining > as to make any future dynamic update feature very difficult. See > Section xxx. It has nothing to do with dynamic update. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa04912; 10 May 94 13:23 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA01879; Tue, 10 May 94 13:23:41 EDT Received: by relay.tis.com id AA11763; Tue, 10 May 94 13:24:24 EDT Message-Id: <9405101724.AA11763@relay.tis.com> Received: from labs-n.bbn.com(128.89.0.100) by relay via smap (V1.3mjr) id sma011760; Tue May 10 13:24:02 1994 To: Noel Chiappa Cc: big-internet@munnari.oz.au, dns-security@tis.com, sipp@sunroof2.eng.sun.com Subject: Re: SIPP Routing Header & security & Re: DNS security draft In-Reply-To: Your message of Mon, 25 Apr 94 16:00:11 -0400. <9404252000.AA28202@ginger.lcs.mit.edu> Date: Tue, 10 May 94 13:22:07 -0400 From: Steve Kent Noel, I thought of another motivation for requiring the dns-security mechanisms algorithm independent. The DoD makes extensive use of TCP/IP and it is a market into which many vendors probably want to be able to continue to sell. However, the crypto algorithms used in DoD networks are often different from those employed in the open Internet. It behooves us to adopt security standards that are algorithm independent whenever we would like the DoD to be able to use the same protocols but with different crypto algorithms. In circumstances where the DoD enclaves are isolated from the open Internet, there is no need for commonality of algorithm, but commonality of protocol still allows for DoD use of COTS products. Steve   Received: from sol.tis.com by magellan.TIS.COM id aa05102; 10 May 94 14:48 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA08146; Tue, 10 May 94 14:48:49 EDT Received: by relay.tis.com id AA12552; Tue, 10 May 94 14:49:33 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3mjr) id sma012542; Tue May 10 14:49:12 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA25368; Tue, 10 May 94 11:41:55 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA25410; Tue, 10 May 1994 14:43:51 -0400 Message-Id: <9405101843.AA25410@skidrow.lkg.dec.com> To: big-internet@munnari.oz.au, dns-security@tis.com, sipp@sunroof2.eng.sun.com Subject: Re: SIPP Routing Header & security & Re: DNS security draft In-Reply-To: Your message of "Tue, 10 May 94 13:22:07 EDT." <9405101723.AA21814@Sun.COM> Date: Tue, 10 May 94 14:43:51 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Steve, As I have said, the next version of the dnssec-secext draft will have provisions for algorithms versions. From: Steve Kent To: Noel Chiappa Cc: big-internet@munnari.oz.au, dns-security@tis.com, sipp@sunroof2.Eng.Sun.COM In-Reply-To: Your message of Mon, 25 Apr 94 16:00:11 -0400. <9404252000.AA28202@ginger.lcs.mit.edu> Sender: sipp-request@sunroof.Eng.Sun.COM >Noel, > > I thought of another motivation for requiring the dns-security >mechanisms algorithm independent. The DoD makes extensive use of >TCP/IP and it is a market into which many vendors probably want to be >able to continue to sell. However, the crypto algorithms used in >DoD networks are often different from those employed in the open >Internet. It behooves us to adopt security standards that are >algorithm independent whenever we would like the DoD to be able to use >the same protocols but with different crypto algorithms. In The DoD spectre has already been rasied by others. Personally, I really don't care whether the DoD can use the same protocols with different crypto algorithms. The success of the Internet is based on good engineering for the Internet environment, rather than trying for bureaucratic correctness. When Internet standards have followed such outside non-technical forces, such as the adoption of ASN.1 for SNMP, it has been regretted. A clear provision for at least rolling over to future algorithm sets in needed in dns-security because it is good engineering. And once you have an algorithm version field, its trivial to provide a systematic way for private algorithms to be identified. The details of the construction of SIG RRs and their use in authentiction are part of the algorithm set, not part of the protocol. >circumstances where the DoD enclaves are isolated from the open >Internet, there is no need for commonality of algorithm, but >commonality of protocol still allows for DoD use of COTS products. You can't use COTS products with different algorithms unless you add your (for the DoD probably classified secret) algorithms. If you consider proper algorithms to be (1) taking one piece of data and a key and calculating a SIG for it and (2) taking one piece of data, a key, and a SIG and saying if that SIG authenticates the data, then the current protocol is algorithm dependent. However, if you consider an algorithm to be (1) taking a set of data elements and a key and calculating one or more SIGs and (2) taking one or more data elements, a key, and one or more SIGs and saying if those SIG(s) authentic that data, then the current protocol is totally algorithm independent. (Yes, there are some simplicifcations in my descriptions of both points of view, for brevity, such as only considering the minimally compliant server, but I could construct a parallel set of complete descriptions which would demonstrate the same point.) >Steve Donald   Received: from sol.tis.com by magellan.TIS.COM id aa05270; 10 May 94 16:41 EDT Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA16824; Tue, 10 May 94 16:40:58 EDT Received: by relay.tis.com id AA13450; Tue, 10 May 94 16:41:41 EDT Message-Id: <9405102041.AA13450@relay.tis.com> Received: from labs-n.bbn.com(128.89.0.100) by relay via smap (V1.3mjr) id sma013443; Tue May 10 16:40:52 1994 To: "Donald E. Eastlake 3rd (Beast)" Cc: big-internet@munnari.oz.au, dns-security@tis.com, sipp@sunroof2.eng.sun.com Subject: Re: SIPP Routing Header & security & Re: DNS security draft In-Reply-To: Your message of Tue, 10 May 94 14:43:51 -0400. <9405101843.AA25410@skidrow.lkg.dec.com> Date: Tue, 10 May 94 16:34:10 -0400 From: Steve Kent Donald, I'm glad to hear that the next version of the proposal will carry algortihm identifiers, and I hope it will be algorithm independent too. In the case of signatures, algorithm independence would require that we not rely on the reversability of RSA signatures, i.e., the ability to revover the signed data from the signature value. A generic signature validation mechanism begins by (locally) computing the hash on the (purportedly) signed data. That input, the public key and any algorithm parameters of the signer, plus the signature value itself is input to a signature verification routine. The routine then outputs true or false, i.e., the signature is valid or invalid. Steve   Received: from sol.tis.com by magellan.TIS.COM id aa24145; 7 Jun 94 8:54 EDT Received: by relay.tis.com id AA11146; Tue, 7 Jun 94 08:51:45 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3) id sma011136; Tue Jun 7 08:50:46 1994 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA29584; Tue, 7 Jun 94 08:54:40 EDT Received: by relay.tis.com id AA11133; Tue, 7 Jun 94 08:50:44 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3) id sma011124; Tue Jun 7 08:49:49 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/27May94) id AA17575; Tue, 7 Jun 94 05:45:22 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA21968; Tue, 7 Jun 1994 08:47:40 -0400 Message-Id: <9406071247.AA21968@skidrow.lkg.dec.com> To: dns-security@tis.com Subject: Re: Algorithms ( was Re: Security AD's assesment re RSAREF licensing ) Date: Tue, 07 Jun 94 08:47:40 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: Steve Kent To: "Donald E. Eastlake 3rd (Beast)" Cc: big-internet@munnari.oz.au, dns-security@tis.com, sipp@sunroof2.Eng.Sun.COM In-Reply-To: Your message of Tue, 10 May 94 14:43:51 -0400. <9405101843.AA25410@skidrow.lkg.dec.com> Sender: sipp-request@sunroof.Eng.Sun.COM >Donald, > > I'm glad to hear that the next version of the proposal will >carry algortihm identifiers, and I hope it will be algorithm >independent too. In the case of signatures, algorithm independence >would require that we not rely on the reversability of RSA signatures, >i.e., the ability to recover the signed data from the signature value. >A generic signature validation mechanism begins by (locally) computing >the hash on the (purportedly) signed data. That input, the public key >and any algorithm parameters of the signer, plus the signature value >itself is input to a signature verification routine. The routine then >outputs true or false, i.e., the signature is valid or invalid. After much though, I have decided that I agree that it should be possible to use non-reversible signature schemes and the next draft will explain how. But I don't see any reason to throw away the factor or two or more space efficiency made possible by exploiting the invertibility of RSA signatures. I reject your insistance that the piece of the algorithmic ensemble which changes with the algorithm version must be limited to the small part having the input/output characteristics you describe. >Steve Donald From: Masataka Ohta To: "Donald E. Eastlake 3rd" Cc: kent@bbn.com, dns-security@tis.com In-Reply-To: <9404260237.AA17332@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Apr 25, 94 10: 37 pm >> > For exmaple, ElGamal is an alternative signature algorithm >> >which is not itself patented, but which is embraced by the fundamental >> >Diffie-Hellman public key patent that expires in 1997 (I believe). >> >ElGamal is not very efficient, but it is an alternative that has a >> >shorter duration patent status relative to RSA. >> >> Looks to me like ElGamal would produce signatures that were twice as >> big > >Wrong. > >Agaist the simple enumeration attack, ElGamal with a 512 bit prime which >requires a 1024 bit signature is just as secure as RSA with two 512 bit >primes which also requires a 1024 bit signature. My point was that you can only sign something half as big with ElGamal. I.E., about 512 bits as opposed to 1024 in this case >> and took at least a *hundred* and in some cases over a *thousand* >> times more computation effort to verify than profiled RSA. > >That's true. But, in the security conscious enviroment where secure >DNS is required, we need to compute a lot of on-line signature outside >of DNS. Generation of RSA signature is almost as slow as generation >of signature and verification of ElGamal. > >So, if ElGamal is unusably slow, RSA is also unusable, isn't it? No at all. The point is that with DNS there will be zillions of signature *verifications*. With RSA you can control whether signing or verification is more computation intensive. With El Gamal you are stuck with expensive verification. With a small bounded public exponent RSA, the cost of verification goes up only with the square of the modulus size. (The cost of signing goes up with the cube and the cost of key generation goes up with the fourth power.) With El Gamal, verification will go up with the third power of the key (not the third power of the key length!). This is a huge difference. >Fortunately, the working set of the computation is quite small and >completely included in on-chip cache. That is, signature computation >speed is assured to become faster and faster as CPU speed increases. Yes, but by the time CPU speed has increased enough to overcome such large multiple-orders-of-magnitude speed differences, the patent will have expired anyway so the whole point of going to El Gamal goes away. >... > Masataka Ohta Donald   Received: from sol.tis.com by magellan.TIS.COM id aa24711; 7 Jun 94 10:46 EDT Received: by relay.tis.com id AA12606; Tue, 7 Jun 94 10:43:23 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3) id sma012599; Tue Jun 7 10:42:24 1994 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA06643; Tue, 7 Jun 94 10:46:21 EDT Received: by relay.tis.com id AA12596; Tue, 7 Jun 94 10:42:23 EDT Received: from necom830.cc.titech.ac.jp(131.112.4.4) by relay via smap (V1.3) id sma012576; Tue Jun 7 10:41:46 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 7 Jun 94 23:38:47 +0859 From: Masataka Ohta Return-Path: Message-Id: <9406071439.AA16645@necom830.cc.titech.ac.jp> Subject: Re: Algorithms ( was Re: Security AD's assesment re RSAREF licensing ) To: "Donald E. Eastlake 3rd" Date: Tue, 7 Jun 94 23:38:45 JST Cc: dns-security@tis.com In-Reply-To: <9406071247.AA21968@skidrow.lkg.dec.com>; from "Donald E. Eastlake 3rd" at Jun 7, 94 8:47 am X-Mailer: ELM [version 2.3 PL11] > >> Looks to me like ElGamal would produce signatures that were twice as > >> big > >Wrong. > My point was that you can only sign something half as big with ElGamal. > I.E., about 512 bits as opposed to 1024 in this case Yes, your point was valid when you were insisting to have reversible sign on raw data with RSA. When signing a single MD5 signature, ElGamal is as compact as RSA. > >So, if ElGamal is unusably slow, RSA is also unusable, isn't it? > > No at all. The point is that with DNS there will be zillions of > signature *verifications*. Your point is well taken. My point is that, in the age when DNS needs zillions of signature verifications, systems outside of DNS should need zillions of signature generations. > With RSA you can control whether signing > or verification is more computation intensive. With El Gamal you are > stuck with expensive verification. True. > With a small bounded public exponent RSA, the cost of verification > goes up only with the square of the modulus size. (The cost of > signing goes up with the cube and the cost of key generation goes up > with the fourth power.) OK. Without Strassen-Shoenhage, computation of the exponential for signature generation takes the third power of the modulus' length (= the signature's length). > With El Gamal, verification will go up with > the third power of the key (not the third power of the key length!). What? My understanding is that: ElGamal verification consists of three exponentials, one multiplication and one comparison with some prime modulus. Computation of the exponentials takes the third power of the prime's length (= half the signature's length). So, how can you say that the time complexity is of the third power of the key? > This is a huge difference. If it were "the third power of the key" or even "square root of the key", I agree. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa21125; 12 Jun 94 12:36 EDT Received: by relay.tis.com id AA02974; Sun, 12 Jun 94 12:30:17 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3) id sma002959; Sun Jun 12 12:29:21 1994 Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA10583; Sun, 12 Jun 94 12:36:20 EDT Received: by relay.tis.com id AA02954; Sun, 12 Jun 94 12:29:16 EDT Received: from necom830.cc.titech.ac.jp(131.112.32.132) by relay via smap (V1.3) id sma002942; Sun Jun 12 12:28:49 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 13 Jun 94 01:29:13 +0900 From: Masataka Ohta Return-Path: Message-Id: <9406121629.AA10641@necom830.cc.titech.ac.jp> Subject: Another Draft To: dns-security@tis.com Date: Mon, 13 Jun 94 1:29:11 JST X-Mailer: ELM [version 2.3 PL11] The draft below is on another framework of secure DNS, which is designed to be, as I promised, perfectly royal to the existing DNS architecture. For example, referral mechanism is no different from the current one. It is algorithm independent. It is simple, that is, contains no flag bits. It contains suggestion on how dynamic update and secure DNS should interact. Any comments? Masataka Ohta ------------------------------------------------------------------------ DNS Protocol Extension for Security 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. 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 June 13, 1994 [Page 1] - 2 - 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. Though the secure DNS can be a authenticated source of information to establish secure communication between hosts, 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 can perform authenticated communication between security aware name servers and resolvers in a way specified in this document. A security aware resolver is a resolver which can retrieve authenticated DNS data in secure zones. A security aware resolver is configured with a list of security aware name servers which is considered to be reliable. The resolver also has information to make authenticated communication with the reliable name servers, whose actual mechanism should be identical or parallel to secure IP and is not discussed in this document. 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 Existing Mechanism Important changes to the existing DNS architecture described in RFC 1034 and RFC 1035 are: A new OPCODE, NCQUERY, is added to retrieve authentication information of a node containing CNAME. As authentication information on a node of CNAME is added as other records of the node, it is necessary to have an opcode to suppress CNAME processing. As a side effect, it is now possible to have a zone which consists of a single CNAME node, which also have SOA and NS June 13, 1994 [Page 2] - 3 - records. [Note: Though it is possible to add new query types which matches CNAME and other RRs in the node, it is not so clean. Moreover, as authentication data is usually large, it may cause UDP packetsize overflow]. SD (Security Desired) bit is added to DNS packets for query. Though a name server is free to ignore the bit, the secure resolvers expects their reliable name servers return secure answer. The bit may also affect additional section processing. SA (Security Assured) bit is added to DNS packets for answer, which means that a name server who answers the question assures that all the data in the answer section is secure. MINTTL fields of SOA RRs no longer mean the actual minimal TTLs nor negative caching periods. They, instead, mean default TTLs. 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. 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. June 13, 1994 [Page 3] - 4 - 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 without domain name compression. If there are multiple records of the same , they are sorted with dictionary order, comparing the first bytes first with unsigned arithmetic. 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 (original TTL). 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] record for each RR type the node has. But, it is impossible and unnecessary to cover s of [RRD] [NSIG] and [ZSIG]. 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. 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 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. June 13, 1994 [Page 4] - 5 - 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: [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 [ZA] actually used for the signature. Older [ZA] 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. June 13, 1994 [Page 5] - 6 - 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] a signed zone. 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]. ZL (Zone List) data used to list all the nodes in a zone with small authentication granulity. 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. 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. 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. Within labels, first bytes are compared first. Thus, the name of the June 13, 1994 [Page 6] - 7 - 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. It also have digest of ZA to authenticate zone transfers. So, if the primary server is compromised, secondary servers can detect it and reject bogus zone transfers and can continue operation with older information. 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: 0. If SD bit is not set, use the original algorithm in RFC June 13, 1994 [Page 7] - 8 - 1034. Otherwise, set SA bit. 1. Set or clear the value of recursion available in the response depending on whether the name server is willing to 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 secure 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 and OPCODE is not NCQUERY, 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 June 13, 1994 [Page 8] - 9 - 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 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]. Go to step 6. 4. Start matching down in the cache. If authenticated QNAME is found in the cache, copy all authenticated RRs attached to it that match QTYPE into the answer section. If there was no delegation from authoritative data, 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 and set or reset SA bit appropriately. 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 [SXFER] 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. A secure zone transfer is a byte stream with the following structure. +------------------+ ^ | length | |d +------------------+ |i | | |g | | |e | zone data | |s | | |t | | |e +------------------+ vd ^ | timestamp | |s +------------------+ |i | expire | |g +------------------+ |n | digest | |e +------------------+ vd | signature | +------------------+ June 13, 1994 [Page 9] - 10 - The secondary server extract [ZA] records which is just transferred, verify it with statically configured digest, and authenticate the signature of the transferred zone. Unlike AXFER, [SXFER] 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 resolver thinks those name June 13, 1994 [Page 10] - 11 - servers reliable. The configuration file also contains information, such as shared secret or digest of public key, for authenticated communication to the reliable name servers. The match count will be -1 to indicate that 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. The cache also contains information whether the RR is considered to be authenticated by the resolver. In the CACHE, authenticated RR has precedence over unauthenticated RR. 5.3 Resolver Algorithm 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 with SD bit set 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 of the delegated zone. If the delegation information is authenticated, put it to local cache and go to step 2. June 13, 1994 [Page 11] - 12 - 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 obtained from one of the trusted name servers through authenticated communication channel and SA bit is set, or if the answer is in the authoritative data of the name server co-located with the resolver, no authentication is necessary. 2. For NSIG or ZSIG, no authentication check is necessary, though authentication failure with cached NSIG or ZSIG should invalidate the cached information. 3. To authenticate RRD, use NSIG and authenticated ZA. 4. To authenticate ZL, use authenticated ZA. 5. To authenticate ZA, use RRD of ZA and ZSIG. 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, the queried node does not exist, confirm it by authenticating ZL data in the additional section of the response. 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: June 13, 1994 [Page 12] - 13 - 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 other than RRD nor NSIG Figure 2. Authentication Chain of Node Data 5. 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, June 13, 1994 [Page 13] - 14 - 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 minus the expected maximum error of the resolvers' clocks fractions rounded down. Due to clock skew, a resolver may receive a dated in the future. The data should be relied if the error is below /10 plus the expected maximum error of the resolvers' clocks fractions rounded down. 6. 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 reply longer than 512 bytes. [ZL] data for protection against denial of service attacks. glue A records for referral. the node of the added information is same as the nodes of the query. other additional information. 7. Specification of a Secure DNS Architecture To specify secure DNS, a standard track RFC(s) must be provided which specify a mechanism for digesting June 13, 1994 [Page 14] - 15 - a mechanism for signature RR type values for [RRD], [NSIG], [ZA], [ZSIG], [ZL], [ZA], [ZSIG] and [SXFR] Ranges of 256 RR type values are reserved by IANA for the actual values of [RRD], [NSIG], [ZA], [ZSIG], [ZL] and [SXFR] as follows: [RRD] X [NSIG] X+256 [ZA] X+512 [ZSIG] X+768 [ZL] X+1024 [SXFR] X+1280 where X is between Y and Y+255 (Y is to be determined by IANA). [RRD], [NSIG], [ZA], [ZSIG], [ZL] and [SXFR] sharing the same value of X forms a single set of specification. Even if two specifications share the same digesting mechanism, it has different [RRD] values. June 13, 1994 [Page 15]   Received: from sol.tis.com by magellan.TIS.COM id aa12404; 13 Jul 94 13:16 EDT Received: from quern.epilogue.com(128.224.1.136) by relay via smap (V1.3) id sma006515; Wed Jul 13 13:14:30 1994 Received: from sra.worf.epilogue.com with DMSP Date: 13 Jul 1994 12:13:48 -0500 From: Rob Austein Sender: sra@worf.epilogue.com To: dns-security@tis.com Subject: Re: Another Draft Repository: quern.epilogue.com Originating-Client: worf.epilogue.com Message-Id: <9407131315.aa22954@quern.epilogue.com> Ok, I read Ohta-san's draft. On the whole, I liked it, the mechanism is more in keeping with "traditional DNS" than Donald and Charlie's (no offense, guys), and it doesn't have the dependency on RSA that seems to worry so many people. The section on the ZL RR type(s) needs some work. I *think* I get it after having read it four times, but I'm still not sure.... In several places the draft refers to "dictionary order". Does this mean case-insensitive lexiographic order, or case-sensitive lexiographic order, or what? Since DNS name lookups have this weird property of preserving but ignoring case of alphabetic characters, the draft needs to be more explicit about how alphabetic case is handled. I can see two possibilties: 1) We continue the DNS model of preserved-but-ignored case. I think this means we chose to live with some spurious authentication failures due to case differences. 2) We pick a canonical case (upper or lower, I don't care) and do all digesting in canonical case. Last, I would like to hear feedback from other members of the DNSSEC WG. Is Ohta-san's proposal a good idea? Is it flawed in some obvious way that I've missed due to insufficient coffee? Is everybody just tired of this subject? --Rob Austein   Received: from sol.tis.com by magellan.TIS.COM id aa20046; 14 Jul 94 10:31 EDT Received: from necom830.cc.titech.ac.jp(131.112.32.132) by relay via smap (V1.3) id sma015828; Thu Jul 14 10:12:33 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 14 Jul 94 23:06:10 +0900 From: Masataka Ohta Return-Path: Message-Id: <9407141406.AA18047@necom830.cc.titech.ac.jp> Subject: Re: Another Draft To: Rob Austein Date: Thu, 14 Jul 94 23:06:09 JST Cc: dns-security@tis.com In-Reply-To: <9407131315.aa22954@quern.epilogue.com>; from "Rob Austein" at Jul 13, 94 12:13 pm X-Mailer: ELM [version 2.3 PL11] > The section on the ZL RR type(s) needs some work. I *think* I get it > after having read it four times, but I'm still not sure.... OK, I'll try. > Since DNS name lookups have this weird property of preserving but > ignoring case of alphabetic characters, the draft needs to be more > explicit about how alphabetic case is handled. I can see two > possibilties: > 1) We continue the DNS model of preserved-but-ignored case. I > think this means we chose to live with some spurious > authentication failures due to case differences. Good point. So, we should make all domain names have the canonical case. > 2) We pick a canonical case (upper or lower, I don't care) and do > all digesting in canonical case. Or, we may change the DNS model to preserved-and-sensitive, which needs three non-overlapping stages for the smooth conversion: a) make all primaries produce canonical case answer b) make all nameservers, resolvers and hostname comparison routines preserve-and-sensitive c) make all primaries preserve case that I don't think it's worth doing (unless we want to support non-ASCII characters, where there is no proper case insensitivity definable). Considering that 2) is identical to a), 2) should be the way to go at least for the time being. Masataka Ohta   Received: from sol.tis.com by magellan.TIS.COM id aa09434; 20 Jul 94 8:54 EDT Received: from necom830.cc.titech.ac.jp(131.112.32.132) by relay via smap (V1.3) id sma019888; Wed Jul 20 08:51:09 1994 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 20 Jul 94 21:45:46 +0859 From: Masataka Ohta Return-Path: Message-Id: <9407201246.AA17508@necom830.cc.titech.ac.jp> Subject: Re: Another Draft (revised) To: dns-security@tis.com Date: Wed, 20 Jul 94 21:45:44 JST X-Mailer: ELM [version 2.3 PL11] According to Rob's suggeestion, I have revised my proposal. Important changes are: Canonical case> Added explanation on ZL Standard upper limit of one week on Any comments? Masataka Ohta ------------------------------------------------------------------------ DNS Protocol Extension for Security 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. 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 July 20, 1994 [Page 1] - 2 - 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. Though the secure DNS can be a authenticated source of information to establish secure communication between hosts, 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 can perform authenticated communication between security aware name servers and resolvers in a way specified in this document. A security aware resolver is a resolver which can retrieve authenticated DNS data in secure zones. A security aware resolver is configured with a list of security aware name servers which is considered to be reliable. The actual mechanism for the communication between a security aware resolver and relied name server should be identical or parallel to secure IP and its detail is not discussed in this document. The problem is that security aware resolver can not rely on secure DNS. So, if secure IP relies on secure DNS, the security aware resolver should use statically configured information, instead. 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 Existing Mechanism Important changes to the existing DNS architecture described in RFC 1034 and RFC 1035 are: A new OPCODE, NCQUERY, is added to retrieve authentication information of a node containing CNAME. As authentication information on a node of CNAME is added as other records of the July 20, 1994 [Page 2] - 3 - node, it is necessary to have an opcode to suppress CNAME processing. As a side effect, it is now possible to have a zone which consists of a single CNAME node, which also have SOA and NS records. [Note: Though it is possible to add new query types which matches CNAME and other RRs in the node, it is not so clean. Moreover, as authentication data is usually large, it may cause UDP packetsize overflow]. SD (Security Desired) bit is added to DNS packets for query. Though a name server is free to ignore the bit, the secure resolvers expects their reliable name servers return secure answer. The bit may also affect additional section processing. SA (Security Assured) bit is added to DNS packets for answer, which means that a name server who answers the question assures that all the data in the answer section is secure. MINTTL fields of SOA RRs no longer mean the actual minimal TTLs nor negative caching periods. They, instead, mean default TTLs. Cases are canonicalized to use only upper case characters. Lower case characters are converted to upper case in primary servers. The canonicalization is necessary to compute a consistent signature or digest value. 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. 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 July 20, 1994 [Page 3] - 4 - 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 without domain name compression. If there are multiple records of the same , they are sorted with dictionary order, comparing the first bytes first with unsigned arithmetic. 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 (original TTL). 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] record for each RR type the node has. But, it is impossible and unnecessary to cover s of [RRD] [NSIG] and [ZSIG]. 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. 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 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 July 20, 1994 [Page 4] - 5 - 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: [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 July 20, 1994 [Page 5] - 6 - NSIG is compared to the fields in [ZA]s to select the [ZA] actually used for the signature. Older [ZA] 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] a signed zone. 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]. 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) July 20, 1994 [Page 6] - 7 - 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. 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, first bytes are compared first. 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. It also have digest of ZA to authenticate zone transfers. So, if the primary server is compromised, secondary servers can detect it and reject bogus zone transfers and can continue operation with older information. 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: 0. If SD bit is not set, use the original algorithm in RFC 1034. Otherwise, set SA bit. 1. Set or clear the value of recursion available in the response depending on whether the name server is willing to 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 secure 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 and OPCODE is not NCQUERY, copy the CNAME RR into the answer section of the response, change QNAME to the canonical name in the CNAME RR, July 20, 1994 [Page 8] - 9 - 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 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]. Go to step 6. 4. Start matching down in the cache. If authenticated QNAME is found in the cache, copy all authenticated RRs attached to it that match QTYPE into the answer section. If there was no delegation from authoritative data, 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 and set or reset SA bit appropriately. Store the results, including any intermediate CNAMEs, in the answer section of the response. July 20, 1994 [Page 9] - 10 - 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 [SXFER] 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. A secure zone transfer is a byte stream with the following structure. +------------------+ ^ | length | |d +------------------+ |i | | |g | | |e | zone data | |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 signature of the transferred zone. Unlike AXFER, [SXFER] 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. July 20, 1994 [Page 10] - 11 - 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 resolver thinks those name servers reliable. The configuration file also contains information, such as shared secret or digest of public key, for authenticated communication to the reliable name servers. The match count will be -1 to indicate that 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. The cache also contains information whether the RR is considered to be authenticated by the resolver. In the CACHE, authenticated RR has precedence over unauthenticated RR. 5.3 Resolver Algorithm July 20, 1994 [Page 11] - 12 - 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 with SD bit set 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 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 obtained from one of the trusted name servers through authenticated communication channel and SA bit is set, or if the answer is in the authoritative data of the name server co-located with the resolver, no authentication is necessary. 2. For NSIG or ZSIG, no authentication check is necessary, though authentication failure with cached NSIG or ZSIG should invalidate the cached information. July 20, 1994 [Page 12] - 13 - 3. To authenticate RRD, use NSIG and authenticated ZA. 4. To authenticate ZL, use authenticated ZA. 5. To authenticate ZA, use RRD of ZA and ZSIG. 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 "*.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 | | July 20, 1994 [Page 13] - 14 - | 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 other than RRD nor NSIG Figure 2. Authentication Chain of Node Data 5. 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 July 20, 1994 [Page 14] - 15 - 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. 6. 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 reply longer than 512 bytes. [ZL] data for protection against denial of service attacks. glue A records for referral. the node of the added information is same as the nodes of the query. other additional information. 7. 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] Ranges of 256 RR type values are reserved by IANA for the actual values of [RRD], [NSIG], [ZA], [ZSIG], [ZL] and [SXFR] as follows: [RRD] X [NSIG] X+256 [ZA] X+512 July 20, 1994 [Page 15] - 16 - [ZSIG] X+768 [ZL] X+1024 [SXFR] X+1280 where X is between Y and Y+255 (Y is to be determined by IANA). [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 mechanism, it has different [RRD] values. July 20, 1994 [Page 16]   Received: from sol.tis.com by magellan.TIS.COM id aa27348; 21 Jul 94 16:31 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3) id sma002513; Thu Jul 21 16:29:19 1994 Received: from magellan.tis.com by tis.com (4.1/SUN-5.64) id AA08788; Thu, 21 Jul 94 16:31:02 EDT Message-Id: <9407212031.AA08788@tis.com> Reply-To: James M Galvin To: dns-security@tis.com Subject: Agenda for Toronto IETF Date: Thu, 21 Jul 1994 16:31:08 -0400 From: James M Galvin The DNS Security Working Group has a meeting scheduled for Wednesday, July 27, 1994, at 9:30am. There are at least 4 items on the agenda: o report on implementation by Jim Galvin o presentation by Masataka Ohta on his proposal and how it differs from Eastlake/Kaufman (I invited this presentation) o comments from Donald Eastlake/Charlie Kaufman (I haven't asked you guys yet about this but I figured you should have an opportunity to comment on presentations thus far if you want it) o identifying the proposal to follow through with from this point With respect to the fourth item, our Charter says that we will submit a proposal for security enhancements after this meeting. This proposal is subject to review until the next IETF in November at which time we'll submit it to the IESG. Since we now have two proposals on the table we need to discuss them with the objective of choosing one of or merging them into one proposal. Should the working group decide that neither is satisfactory, we'll need to be prepared to defend that position and have a specific and precise statement of exactly what we need in the next proposal. See you in Toronto, Jim Chair of the DNS Security Working Group   Received: from sol.tis.com by magellan.TIS.COM id aa04538; 25 Jul 94 16:56 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3) id sma028813; Mon Jul 25 16:55:49 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/27May94) id AA08433; Mon, 25 Jul 94 13:42:08 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA18776; Mon, 25 Jul 1994 16:45:01 -0400 Message-Id: <9407252045.AA18776@skidrow.lkg.dec.com> To: dns-security@tis.com Cc: Charlie Kaufman Subject: draft-ietf-dnssec-as-map-00.txt Date: Mon, 25 Jul 94 16:45:01 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp INTERNET-DRAFT Mapping A.S. Number into the DNS 25 July 1994 Expires 26 January 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-00.txt, is intended to be become an informational RFC. [Or should it be standards track if it is a significant part of 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 draft-ietf-dnssec- secext-*.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 significant contributions of the following persons to this draft are gratefully acknowledged: Ran Atkinson. 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 Autonimous 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 draft-ietf-dnssec-secext-*.txt). All that is required is a mapping of Autonimous 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. Autonimous 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. This could be .int or .# or whatever.] [I choose hex digits to provide a slightly finer subdivision than the traditional decimally represented bytes. If there is really lots of CIDR like sub-allocation of power of two groups of A.S. numbers and having to sometimes have multiple designations and zones for what should logically be a single zone is considered too ugly, you could go to all "1" and "0" labels are write it as the reversed binary. But didn't seem worth it to me. Even if its a bit ugly, few people will ever see it.] 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 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 A.S. name mean 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. 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 [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris, November 1987 [RFC1035] - Domain Names - Implementation and Specifications 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 26 January 1995 Its file name is draft-ietf-dnssec-as-map-00.txt. Donald E. Eastlake 3rd [Page 8]   Received: from sol.tis.com by magellan.TIS.COM id aa04569; 25 Jul 94 17:07 EDT Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3) id sma029000; Mon Jul 25 17:06:54 1994 Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/27May94) id AA08947; Mon, 25 Jul 94 13:53:40 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA18988; Mon, 25 Jul 1994 16:56:34 -0400 Message-Id: <9407252056.AA18988@skidrow.lkg.dec.com> To: dns-security@tis.com Cc: Charlie Kaufman Subject: draft-ietf-dnssec-secext-02.txt Date: Mon, 25 Jul 94 16:56:34 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Hello: I guess this is better late than not at all. I don't plan to actually send this to Internet-drafts until after IETF so feedback can be incorporated. I will not be attending but Charlie Kaufman will. Donald INTERNET-DRAFT DNS Protocol Security Extensions 25 July 1994 Expires 26 January 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 data origin 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 secondary or caching 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 those 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: James M. Galvin, Masataka Ohta, Jeff Schiller. [This list is probably incomplete. Anyone else who feels they should be included should contact the authors.] 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...................................7 2.2.2 The SIG Resource Record..............................7 2.2.3 The NXD Resource Record..............................8 2.2.4 Signers Other Than The Zone..........................8 2.2.5 Special Problems With Time-to-Live...................8 2.2.6 Improved Performance Mode............................9 2.3 DNS Transaction Authentication.........................9 3. The Security Desired & Security Available Bits.........11 4. The KEY Resource Record................................12 4.1 KEY RDATA format......................................12 4.2 Object Types and DNS Names and Keys...................13 4.3 The KEY RR Flag Octets................................13 4.4 KEY RRs in the Construction of Responses..............15 4.5 File Representation of KEY RRs........................15 5. The SIG Resource Record................................17 5.1 SIG RDATA Format......................................17 5.1.1 SIG Flag Bits.......................................18 5.1.2 Signature Format....................................19 5.1.3 Signet Format.......................................20 5.1.3.1 Direct Resource Record Signets....................21 5.1.3.2 Direct Glue Record Signet.........................22 5.1.3.3 Hashed Resource Record(s) Signet..................23 5.1.3.4 Partial RR Set Flag Signet........................24 5.1.3.5 Partial SIG Set Flag Signet.......................24 5.1.3.6 AXFR Signets......................................25 5.1.3.7 Message Hashed Signets............................25 5.1.3.8 Reserved Signet Prefixes..........................26 5.2 SIG RRs in the Construction of Responses..............26 5.3 Processing Responses with SIG RRs.....................27 5.4 File Representation of SIG RRs........................28 5.4.1 Size of Data........................................28 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 3] INTERNET-DRAFT DNS Protocol Security Extensions 5.4.2 Resource Record Numbering...........................29 5.4.3 SIG RR Scope........................................29 5.4.4 RRs Supressed by a SIG RR...........................30 6. Non-exitent Names and Types............................31 6.1 Nonexistent Names.....................................31 6.1.1 The NXD Resource Record.............................31 6.1.2 NXD RDATA format....................................32 6.1.3 Interaction of NXD RRs and Wildcard RRs.............32 6.1.4 Blocking NXD Pseudo-Zone Transfers..................33 6.2 Non-existent Types....................................33 7. How to Resolve Securely................................35 7.1 Boot File Format......................................35 7.2 Chaining Through Zones................................36 7.3 Secure Time...........................................37 8. Operational Considerations.............................38 8.1 Key Size Considerations...............................38 8.2 Key Storage...........................................39 8.3 Key Generation........................................39 8.4 Key Lifetimes.........................................39 8.5 Key Revocation........................................40 8.6 Root..................................................41 9. Conformance............................................42 9.1 Server Conformance....................................42 9.2 Resolver Conformance..................................42 10. Security Considerations...............................43 References................................................43 Authors Addresses.........................................44 Expiration and File Name..................................44 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 security and 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 a variety keys with DNS names. This permits the DNS to be used as a general public key distribution mechanism in support of 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 4. It includes the name of the entity the key is associated with (usually but not always the KEY RR owner name), an algorithm identifier, a number of 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 There are two distinct aspects to the data origin authentication service. The purpose of the first is to add security; the purpose of the second is to improve performance when the first is used. Adding security requires no changes 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-exitence 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 retrieved and verified when retrieving the information they authenticate, there will be more trips to the server and performance will suffer. The revisions to the DNS wire protocol for security aware servers mitigate that degradation by automatically sending exactly the signatures needed and by skipping the sending of the data if it can be derived from the signature. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 6] INTERNET-DRAFT DNS Protocol Security Extensions 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, 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 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 having it manually configured or by reading it from DNS. 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. 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 5. It includes 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), some flags, the cryptographic algorithm in use, and the actual signature. Every name in a zone supporting signed data will have associated with it one or more SIG resource records - as many as required with the algorithm(s) in use to sign all of the authenticated resource records. A security aware server supporting the performance enhanced version of the DNS protocol security extensions will return with all records retrieved the corresponding SIG records. If a server does not support the protocol, the resolver must retrieve all the SIG records for a name, verify them all, and find the one or ones that sign the resource records that resolver is interested in. As a further optimization, a server supporting the performance enhanced version of the protocol will return only the signature - and skip the Donald E. Eastlake 3rd & Charles W. Kaufman [Page 7] INTERNET-DRAFT DNS Protocol Security Extensions requested RRs - in the case where the signature contains enough information to reconstruct the data in full. Because of this, in some cases the authenticated data being sent via SIG records can be shorter than the plain data would have been. 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 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 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 RRs 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 fail to decrement time to live, but they cannot increase it beyond its original 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. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 8] INTERNET-DRAFT DNS Protocol Security Extensions In order to keep the data as compressed as possible, we don't want to have to include the original TTL for every resource record included in a SIG when usually they are all the same. We therefore assume that the original TTL is equal to the original TTL of the SIG resource record (which is sent for every SIG resource record), and in the rare case where the TTL on the other resource record differs we permit it to be explicitly included. 2.2.6 Improved Performance Mode To run the high performance version of the protocol, the server should remember for each resource record: (1) which SIG record includes the signature for that record and (2) whether the SIG record contains the resource record in full or in digested form. When the server is responding to a request, it should for each record requested return the corresponding SIG (removing duplicates) and also it should suppress the sending of the record itself if it is present in the signature in undigested form. Since a resolver running the secure protocol will not believe any record that is not signed, there would be no point in returning the record without the SIG. And if the resolver is going to see the RR in full in the SIG there is no point in wasting bandwidth by sending the RR being authenticated. The high performance version of the protocol can only be used if both resolver and server understand it. Negotiation is done via DNS message header bits we believe that existing servers will ignore and existing resolvers will not set. If signature verification is not done by the DNS resolver code but rather by some application that is retrieving resource records through that resolver, the standard protocol must be used. 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 diddled in transit. This is accomplished by adding a SIG resource record to end of the reply which digitally signs the message by the server and includes a Donald E. Eastlake 3rd & Charles W. Kaufman [Page 9] INTERNET-DRAFT DNS Protocol Security Extensions hash code of the 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 rudamentary 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 10] INTERNET-DRAFT DNS Protocol Security Extensions 3. The Security Desired & Security Available Bits The header section of DNS messages is modified to define bits 9 and 10 in the second word (fourth octet). These were formerly the top two bits of the Z field defined as "Reserved for future use." [RFC1035] These bits are defined as security desired, labeled SD, and security available, labeled SA. With the definition of these bits, the header looks like the following: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | ID | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | QR| Opcode | AA| TC| RD| RA| SD| SA| Z | RCODE | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | QDCOUNT | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | ANCOUNT | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | NSCOUNT | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | ARCOUNT | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ All fields are as before except that the Z field is reduced to one bit and SD and SA are defined as follows: SD Security Desired - this bit may be set in a query. If the server to which the query is sent does not support the DNS security protocol, the bit should be ignored except that it may be copied into the response. If the server does support this protocol, the bit MUST copied into the response and, if the bit is set, the server MUST provide any SIG and RSA RRs as described in the sections below concerning these RRs. SA Security Available - this is to be set or cleared in a response. If set, it indicates that the server fully supports this security protocol. [It is not clear that the above will really work due to DNS implementations which blindly include header bits in forwarded queries.] Donald E. Eastlake 3rd & Charles W. Kaufman [Page 11] INTERNET-DRAFT DNS Protocol Security Extensions 4. 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 each type associated with a name. The type number for the KEY RR is 25. 4.1 KEY RDATA format The RDATA for a KEY RR consists of an object name, flags (which include an algorithm identifier, and the parameters needed for that algorithm's public keys. For the RSA algirthm, 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 +---------------+ / | flags1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | flags2 | public key exponent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | modulus length| | +---------------+ public key modulus -+ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The object name, and the flags octets are described in Sections 4.2 and 4.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 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, they can be represented by using leading zeros. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 12] INTERNET-DRAFT DNS Protocol Security Extensions 4.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 "mandatory" bit, and the "signatory" bit, as described in 4.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. 4.3 The KEY RR Flag Octets In the "flags1" field: Bit 0 is the "no key" bit. If this bit is on, there is no key information other flag1 bits can be ignored. Bits 1-3 are reserved and must be zero. If any is found to be non-zero, the KEY RR must be ignored. Bits 4 to 7 are the algorithm version number parallel to the same field for the SIG resource. The RSA algorithm described in this draft is version zero. Version numbers 1 through 14 are available for assignment should sufficient reason arise. 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 15 is reserved for private use and will never be assigned a specific algorithm. For version 15, the combined "public exponent", "modulus length" and "modulus" area shown above will actually begin with an Object Identifier (OID) indicating the Donald E. Eastlake 3rd & Charles W. Kaufman [Page 13] INTERNET-DRAFT DNS Protocol Security Extensions private algorithm in use and the remainder of the combined area is whatever is required by that algorithm. In the "flags2" field: Bits 0 is the "mandatory" bit. Keys may be associated with zones or entities for experimental, trial, or optional use, in which case this bit will be zero. If this bit is a one, it means that the use or availability of security based on the key is "mandatory". Thus, if this bit is on 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 on 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 zero, the host might very well sometimes operate in a secure mode and at other times operate without the availability of IP-security. The mandatory bit, like all other aspects of the KEY RR, is only effective if the KEY RR is appropriately signed by a SIG RR. 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 mandatory bit, like all other aspects of the KEY RR, is only effective if the KEY RR is appropriately signed by a SIG RR. Bits 2-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 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. Bit 6 on indicates that this is a key associated with the end 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 transaction authentication service defined in this draft. It could also be used in an IP-security protocol where authentication of a host was desired. This type of key might also be useful in IP or other security for host level services such as DNS, NTP, routing, etc. Bit 7 on indicates that this is a key associated with a "user" or "account" at an end entity, usually a host. The coding of the Donald E. Eastlake 3rd & Charles W. Kaufman [Page 14] INTERNET-DRAFT DNS Protocol Security Extensions 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. 4.4 KEY RRs in the Construction of Responses A request for KEY RRs does not cause any special additional information processing except, of course, for SIG RRs if security is requested and available. Security aware DNS servers will include KEY RRs as additional information in responses where security is requested under appropriate conditions 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. On any retrieval with security requested and available from a zone, revoked KEYs in that zone that fit with their revoking SIG will be included as additional information with low priority. 4.5 File Representation of KEY RRs KEY RRs may appear as lines in a zone data file. The object name appears first. Each flag field is then represented as an unsigned integer; however, if the "no key" flag is on in the first field, nothing appears after the second flag byte. If the algorithm specified is the RSA algoithm, 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 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 15] INTERNET-DRAFT DNS Protocol Security Extensions 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. If an algorithm from 1 through 14 is specified, the public key parameters required by that algorithm are given. If the algorithm specified is number 15, then an OID appears followed by whatever is requiired for the private algorithm. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 16] INTERNET-DRAFT DNS Protocol Security Extensions 5. 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 binds one or more other RRs to a time and the signer's fully qualified domain name using cryptographic techniques and the signer's private key. The signer is usually the owner of the zone from which the RR originated. 5.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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | signer's name | / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | original TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | time signed | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | signature expiration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | key footprint | flags | labels | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sig length | signature | +---------------+ / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The value of the SIG type is 24. 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 "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. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 17] INTERNET-DRAFT DNS Protocol Security Extensions The "time signed" field is an unsigned number of seconds since the start of 1 January 1970. The SIG is valid until the signature expiration time which is a field of the same format as the time signed. The "key footprint" 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. In cases where multiple keys may be applicable, it can be used to efficiently pick the right one in most cases. The "flags" octet is as described in Section 5.1.1 below and includes an algorithm version field. The "labels" octet is an unsigned count of how many labels there are in the original SIG RR owner name not counting the null lable 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. 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 expaned to 255 labels. The "sig length" field is an unsigned 8 bit count of the number of octets in the signature field minus 64. The structured of the "signature" field depends on the algorithm chosen and is described below. 5.1.1 SIG Flag Bits Bit 0 (the most significant bit) a zero means the SIG RR asserts the validity of the RRs it signs from the start to the end time, inclusive. If it is a one, the RSA RR is a revocation of the RRs as above. Bits 1 to 3 are reserved and must be zero. If a SIG RR is retrieved with these bits non-zero by a resolver that does not understand them, the SIG RR should be discarded. Bits 4 to 7 are the algorithm version number. The RSA algorithm described in this draft is version zero. Version numbers 1 through 14 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 15 is reserved for private use and will never be assigned a specific algorithm. For Donald E. Eastlake 3rd & Charles W. Kaufman [Page 18] INTERNET-DRAFT DNS Protocol Security Extensions version 15, the combined "sig length" and "signature" area shown above will actually begin with an Object Identified (OID) indicating the private algorithm in use and the remainder of the combined area is whatever is required by that algorithm. 5.1.2 Signature Format The actual signature portion of the SIG RR binds the owner, signer, class, original TTL, time signed, key footprint, flags, and expiration time of the RR to one or more RRs being authenticated. To accomplish this, a set of one or more "signet" sequences is constructed to cover the RRs being signed. A "self hash" field is then calculated covering the owner, signer, etc., as listed above. The structure of signets is described in section 5.1.3 below. The hash algorithm(s) used and the maximum signet sequence size depend on the algorithm identier and the key being used. Each signet sequence and self hash is then coverted in to a SIG RR. For any non-invertible signature algorithms, a hash of the signet sequence and self hash will be calculated, then a signature of that hash will be formed and the signature prepended to the signet sequence. For any invertible algorithsm, such as the RSA algorith described in detail in this draft, the signet sequence and self hash are directly signed and the result is the signature portion of the SIG RR. In that case, there is no need for the signet sequence to be present in plain text. For the RSA algorithm, the signature is as follows s = ( 01 | FF* | 00 | signets | self-hash ) ** e (mod n) where "|" is concatenation. "signets" is the concatenation of the signets included in this signature. "self-hash" is the 16 octet hash using the MD5 [RFC1351] of the SIG RR name, class, signer name, original TTL, time signed, expiration time, key footprint, and flags. "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 less than the value of n. No FF octets need occur if "signets" is long enough. The order of the signets is not significant. 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. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 19] INTERNET-DRAFT DNS Protocol Security Extensions The above specifications are similar to PKCS #1 [PKCS1] except that, under most circumstances, one additional octet of data is allowed. (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.) 5.1.3 Signet Format Each signet consists of a prefix octet, with which the length of the signet can be unambiguously determined, followed by the signet data. Signet's are of three basic types: direct, hashed, and flag. A direct signet includes all of the data it covers. Some of the data may be implicit or compressed but it is all unambiguously recoverable. If a direct signet is present covering an RR, then that RR SHOULD be supressed from the reply message if the SD bit is on in the query and the server is security aware. A hashed signet consists of the prefix octet, some additional data, and a 16 octet hash of the data covered. For the RSA algorith, MD5 is used as the hash algorithm. Since hash algorithms are not invertible, the data, such as RRs, covered by a hashed signet must also be included in the reply to a query if it was requested. [The following text assumes the possibility of having multiple direct signets of the same type split over more than one signet sequnece (ie, SIG RR). This complexity has been retained because at the DNS SEC meeting at the Seattle IETF, the consensus was to retain it until operational experience had been gained. The authors of this draft feel that this possibility should be dropped and that multiple direct signets of the same type should be restricted to a single signet sequence (ie, SIG RR) thus eliminating the partial RR set flag signet.] Flag signets occur with direct signets and multiple SIG RRs. They are used to determine if a complete set of RRs of a particular variety are present. Signet prefix octets in binary are as follows: 0000000* Illegal 0LLLLLLL Direct Resource Record - type & rdata Donald E. Eastlake 3rd & Charles W. Kaufman [Page 20] INTERNET-DRAFT DNS Protocol Security Extensions 10****** (reserved) 110***** (reserved) 1110**** (reserved) 11110NHT Hashed RR(s) - N, type, T, & hash 11111000 Partial SIG Set Flag 11111001 Partial RR Set Flag 11111010 Hashed query message (see Sec. 5.2) 11111011 Hashed response message (see Sec. 5.2) 11111100 Direct Glue Record - name & rdata 11111101 (reserved) 1111111* Illegal In the above table, "*" represents 0 or 1 and L, N, H, and T are bits whose meaning is defined in the signet descriptions below. The illegal prefixes should never occur. Any signature that appears to include one should be considered invalid. 5.1.3.1 Direct Resource Record Signets This signet is an actual RR but with some fields supressed. RRs directly represented by this variety of signet are compressed by omitting their name, class, TTL, and RDLENGTH fields. Only the type, and RDATA are present and the LLLLLLL field is their length. This can be done because, in order to avoid inconsistencies, all RRs of the same type and class have to have the same TTL, at least for currently defined RRs. SIG RRs need not survive beyond the RRs they authenticate but must live as long as the covered RRs do. Thus SIG RRs may be constrained to having the same TTL as the RRs they cover in most cases. The SIG RR will always have the same class and name as the RRs it covers (except for glue RRs as described in 5.1.3.2 and 5.1.3.3 below). Finally, the signet data length in the prefix octet can be used to calculate the RDSIZE. For example, the direct signet for a type A record in the IN (Internet) class would be seven octets as follows: 06 00 01 xx yy zz ww where 06 is the prefix indicating a direct RR signet with six data octets, 00 01 is hex for the type code for type A, and xx yy zz ww is the 32 bit IP address from the RR. These 7 octets in a SIG RR completely represent the 15+ (1+ name, 2 type, 2 class, 4 TTL, 2 rdlength, 4 ip address) octets of the original type A RR. The class, name, and TTL are all recoverable from the same fields of the SIG RR whose signature field includes this signet. Thus the original type A RR can be supressed from the answer if given to a security aware resolver. Note that up to three class IN type A RRs can be directly included as Donald E. Eastlake 3rd & Charles W. Kaufman [Page 21] INTERNET-DRAFT DNS Protocol Security Extensions signets in fewer octets than a single hashed signet. This sort of data compression is particularly valuable with the current limitation on DNS UDP reply size. Note that any names in the RDATA area of this type of signet can not be abbreviated by pointers outside of the SIG RR. That is because the RR and its signets are frozen at the time the signature is encrypted under the signer's private key and this frozen SIG RR may then be used in a variety of DNS messages. The RDATA area may, however, have names abbreviated by references to earlier names within the SIG RR including RRS reconstructed from the signet sequence. The direct representation of RRs makes maximum use of the space available in SIG RRs and the supression of hte signet sequence outside of invertible signatures, such as the RSA digital signatures described, results in further space savings. The direct representation also avoids the computational effort of calculating a hash code. Because the original RR's type field must always be present, the minimum length of the data after this type of signet prefix is 2, thus prefixes of 00 and 01 hex are illegal. The maximum size direct RR signet is 128 octets. After the prefix (not counted) and type (2 octets), this allows 126 octets of RDATA. All RRs need not be included within a signature using this direct signet. If the data portion of a direct RR signet exceeds 22 octets (i.e., a total signet size of 23 octets including the prefix count octet), space inside the signature can be saved by going to the hashed RR signet described below. If an RR compressed for a direct signet exceeds 127 octets or the amount of space available for signets in the signature part of a SIG RR, then it must appear separately and be authenticated by a hashed RR signet. 5.1.3.2 Direct Glue Record Signet Glue records must be handled a little differently. These are type A records with a name which isn't in the zone being handled. The direct glue record signet is just like the direct resource record signet described above except that the name is included right after the prefix and the type is not included as it must be type A. If the Glue Record signet won't fit, a hashed RR signet, described below, must be used. Note that names in the DNS can be up to 256 octets long which would not fit inside a SIG RR signature field. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 22] INTERNET-DRAFT DNS Protocol Security Extensions 5.1.3.3 Hashed Resource Record(s) Signet RRs can also be protected by a signet with a hash code. If a hashed signet is used, all RRs of the same name, type, class, and TTL MUST be hashed into a single signet. To avoid inconsistencies, RRs of the same name, type, class, and TTL must either all be present or all be absent. Thus a single hash code covering such multiple RRs is all that is required. The signet is then formed by a single octet 11110NHT (binary) prefix followed by a possible name field depending on "N" and "H" as described below, the two octet type for the RRs covered, a possible TTL field depending on the values of "T" described below, and then the 16 octet hash code. The hash is calculated by concatenating the full RRs, with all names fully expanded and any required RDLENGTH adjustments made, in a canonical order, then appending the self-hash field from the SIG under construcation and applying the hash algorithm. 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. Thus the hex sequences FE 01 02, 07, FF 03, FE FD, FF, and 01 01 01 01 would sort and be concatenated into the sequence 01 01 01 01 07 FE 01 02 FE FD FF FF 03. The self-hash is included to force the hash code to change every time the zone is signed as the self-hash includes the time signed. This gives an adversary less time to search for a false hash match which could enable them to forge apparently authentic data. The "N" bit in the prefix stands for Name. It is normally zero because almost all RRs associated with a name in a zone have that name. The exception is glue records. These are type A recores with owner names outside the zone. To be able to cover these in a SIG for a different name where they cannot be included as a direct glue record signet as discussed above, the N bit makes it possible to include the different name in the signet immediately after the prefix. If the N bit is a one but the H bit is zero, the name is included in full. Because names in DNS can be up to 256 octets long, the hash of the full name with the self-hash field appended, using the hash algorithm, can be used instead of the actual name and is indicated by turning on the H (or "hash") bit. To match this against RRs in the reply, their names must be hashed and compared. The "T" bit in the prefix stands for TTL. It is normally zero. For the presently defined RRs, all RRs of the same type, class, and name should have the same TTL. Future RRs may be defined for which it is useful for such RRs to have different TTL's. In that case the T bit must be one in the signet prefix octet, and the TTL of the hashed RR(s) included after the two octet type and before the hash code. If both the N and T bits are on, the name appears immediately after Donald E. Eastlake 3rd & Charles W. Kaufman [Page 23] INTERNET-DRAFT DNS Protocol Security Extensions the prefix octet followed by the type, then the TTL, then the hash code. This is the standard order for these fields in an RR. 5.1.3.4 Partial RR Set Flag Signet [See square bracketed note above about the proposed elimination of this flag signet.] Verification of a hashed RR signet against the RRs included in the hash provides a guarantee that none have been omitted. The same assurance is not provided by the direct RR signet unless all of the direct RR signets of the same type and class are included in one SIG RR. If direct RR signets are split over more than one RR, they MUST be covered by a partial RR set flag signet in each RR. The partial RR set flag signet is indicated by a hex F8 prefix followed a two octet type and then by a count octet. The most significant 4 bits (nibble) of this count octet indicates one less than the total number of SIG RRs that include all of the direct signets for the variety of RRs in question. The least significant nibble is used to distinguish the different SIG RRs required and varies from zero through the value of the first nibble. It is permissible, but unnecessary, to include a partial RR set flag signet prefix followed by the type and a zero octet (i.e., 1 of 1) in the SIG RR containing direct signets for all RRs of a particular varient. For example, an signet of F8000131 (hex) means the SIG RR is the 2nd of the 4 SIG RRs covering A type RRs. Should there be a case where more than 16 SIG RRs could be required to hold the direct signets for a particular variety of RR, direct signets may not be used. The RRs must appear directly in the DNS answer and a hashed signet must be used for authentication. 5.1.3.5 Partial SIG Set Flag Signet Since the SIG RRs for an owner name are not in themselves covered by yet another SIG (except for the case of zone transfers), a malicious server might choose to provide only some of them in response to a query for SIG RRs. The partial RR set flag signet defined above is not guaranteed to help here. The signet prefix of hex F9 is followed by an unsigned octet which is one less than the total number of SIG RRs associated with the name and a second unsigned octet which varies from zero through the value of the first octet. It is permissible, but unnecessary, to include a Donald E. Eastlake 3rd & Charles W. Kaufman [Page 24] INTERNET-DRAFT DNS Protocol Security Extensions partial SIG set flag signet prefix followed by two zero octets (i.e, 1 of 1) if only one SIG RR is associated with a name. More than 256 SIGs many not be associated with the same name and class. 5.1.3.6 AXFR Signets To secure zone transfers, a SIG under the zone name will have a hashed RR signet with the AXFR type. 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 5.1.3.3 and the self-hash of the SIG under construction appended. 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. It can contain non-AXFR signets, be numbered with the partial SIG set flag signet along with other zone level SIGs, if any, etc. 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 4.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. 5.1.3.7 Message Hashed Signets The response message signet consists of the FA (hex) prefix followed by the hash of the entire response message before the SIG, including the header. The query message signet consists of the FB (hex) prefix followed by the hash of the entire query that produced this response, including the query's header. Verification of the transaction authentication SIG, which is signed by the server host key, not the zone key, and the response and query message signets within it by the requesting resolver show that the query and response were not tampered with in transit, that the response corresponds to the intended query. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 25] INTERNET-DRAFT DNS Protocol Security Extensions 5.1.3.8 Reserved Signet Prefixes A number of signet prefixes are reserved for future allocation by the Internet Assigned Numbers Authority (IANA). All such signets will have an unsigned length octet immediately following their prefix code. This will be the length of the signet data not including the prefix or length octets. Thus their length can be unambiguously determined. Such signets are not to be generated by any implementation except for a use for which they have been allocated by IANA. Such signets are to be ignored on receipt by any implementation which does not understand them. 5.2 SIG RRs in the Construction of Responses SIG RRs MUST NOT be sent in response to a query where the SD header bit is clear unless the query specifically requests the SIG type. When the SD header bit is set, the DNS server 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. Furthermore, this automatic inclusion of SIGs in a response is NOT additional information RR processing. 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 in the answer section. If it covers an RR that would appear in the authority section and does not cover any answer section RR, its automatic inclusion MUST be in the authority section. If it covers an RR that would appear in the additional information section and does not cover any answer or authority section RR, it MUST appear in the additional information section. In many cases the full authenticated RR will be included inside the SIG RR. In such cases, the DNS server SHOULD send only the SIG and supress the directly requested RR. The server should assume that the inquirer has the necessary public key to authenticate RRs with the SIG and that, in general, an RR not covered by a SIG may be considered worthless by the inquirer. However, if a SIG including a full RR or an RR and its authenticating SIG will not fit in a response, but the RR alone will, a server SHOULD send the unauthenticated RR notwithstanding the set SD bit in Donald E. Eastlake 3rd & Charles W. Kaufman [Page 26] INTERNET-DRAFT DNS Protocol Security Extensions the query header. The resolver can always do another query to get the SIG. Optionally, DNS transactions may be authenticated by a SIG RR at the end of the response in the additional information section. Such SIG RRs are signed by the DNS server originating the response. The transaction authentication SIG contains a response message hashed signet and a query message hashed signet. Although the signer field must be the name of the originating server host, the name, class, TTL, and original TTL, are meaningless. To save space, the name should be root (a single zero octet) and the class and TTL fields can be zero. [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. If a server is no security aware, then an attempt to retrieve a SIG RR to authenticate a CNAME RR or an NXD to authenticate the non-exitence of a name could result in a non- security aware server doing CNAME processing and not returning the SIG or NXD asscoiated with the CNAME's owner name. The solution to this problem would be to define a new Class, INSEC, which would be used for SIG and NXD RRs that sign IN Class RRs only. Then a security aware resolver talking to a non-security aware server would simply use that class when retrieving SIGs for authentication. It is not clear that this is needed for KEY RRs but similar SIG/NXD holding classes might be needed for any other DNS classes in use such as the HS class.] 5.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 and the data coded into the signature should be carefully examined. If the message or decoded signature can not be parsed or the self hash check fails, 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 range authenticated TTL. The contents of the one or more direct, hashed, or flag signets present should be examined. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 27] INTERNET-DRAFT DNS Protocol Security Extensions For all direct RR signets, the original RR should be reconstructed if they are of a type that should have been retrieved by the query. If they are of another type, they can be optionally reconstructed or ignored. For all reconstructed RRs, there must be a complete set of partial set flag signets or all must be included in one SIG. For hashed RR signets, the hash should be computed from RRs present in the response and compared for authentication. Hashed RR signets for a type not requested in the query must be ignored. If the SIG RR is the last RR in a response in the additional information section, it may contain hashed response and query message signets covering the preceding data in the response and the query that produced the response. These may be checked and the message rejected if the checks fails. But even it the check succeeds, 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 all reasonable checks indicate that the SIG RR is valid then RRs reconstructed or verified by hash should be considered authenticated and all other RRs in the response should be considered with suspicion. The probability that an RSA SIG RR that has been tampered with (without knowledge of the secret key) will pass reasonable checks is vanishingly small (less than 1 in 2**120). 5.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.) 5.4.1 Size of Data There is no particular problem with the signer 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 flags fields appears as unsigned integers. The "labels" field does not appear in the file representation as it can be calculated from the owner name. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 28] INTERNET-DRAFT DNS Protocol Security Extensions The key footprint appears as an eight digit unsigned hexadecimal number. However, the signature itself can be 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 be split between lines using the standard parenthesis. 5.4.2 Resource Record Numbering A SIG RR stored in a zone file covers and in some cases supresses a number of resource records via one or more direct or hashed signets. In order to represent this, RRs can be numbered by an integer field enclosed in curly braces "{}". For compatibility with earlier DNS zone file implementations, this field can occur after all data fields but before any comments, and can be optionally preceded by a single pound sign ("#") immediately before the open curly brace ("{"). This "#" will cause the RR number to be treated as a comment by non- security aware servers but the "#{ number }" will be recognized by security aware servers. [example] Actually, the RR number is the first subfield of three within the curly braces. As described below additional fields can occur separated by semi-colons (";"). 5.4.3 SIG RR Scope The RRs that are covered by a SIG RR are represented by a second sub-field inside the curly brace field which must be present for SIG RRs. This subfield consists of a comma and/or white space separated list of RR numbers, or ranges of the form n-m to indicates all integers from n through m inclusive. As an abbreviation, an asterisk ("*") appearing in this subfield means all RRs appearing before the SIG RR in the zone file back to but not including the immediately previous SIG RR or the beginning of the file, whether or not such covered RRs are numbered. The SIG RR should also be considered to cover any RRs that it supresses as explained in the section below. The SIG RR itself need not be numbered unless it needs to be referred to. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 29] INTERNET-DRAFT DNS Protocol Security Extensions For example [examples] 5.4.4 RRs Supressed by a SIG RR Where a SIG RR includes direct RR signets, the RRs being authenticated should be supressed when the SIG RR appears in a security aware response. This is indicated in the zone data file by a third sub-field inside the curly brace field that may be present with SIG RRs and must be present if they have direct RR signets. As with the scope subfield, this subfield consists of a comma and/or white space separated list of RR numbers or ranges of the form n-m to indicate all integers from n through m inclusive. As an abbreviation, an asterisk ("*") appearing in this subfield means all RRs appearing before the SIG RR in the zone file back to but not include the immediately previous SIG RR or the beginning of the file, whether or not such supressed RRs are numbered. An RR that is supressed is implicitly covered and may, but need not, also be listed in the scope sub-field described in 5.4.3. [example] Donald E. Eastlake 3rd & Charles W. Kaufman [Page 30] INTERNET-DRAFT DNS Protocol Security Extensions 6. Non-exitent Names and Types The SIG RR mechanism described in section 5 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 or deny the existence of a particular type of RR for an existing name. How to securely acomplish these denials is described below. 6.1 Nonexistent Names 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 is returned in the additional information section, along with the error, if the client 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. 6.1.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 domain. 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 is 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 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 31] INTERNET-DRAFT DNS Protocol Security Extensions 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 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. 6.1.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 / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.1.3 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 NX 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 security aware query for a non- existent name. 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 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 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 32] INTERNET-DRAFT DNS Protocol Security Extensions 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 4.2). 6.1.4 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 tedious trial and error. 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. 6.2 Non-existent Types When a secure query is made for a name and class that exist is a zone, but for an RR type that does not exist, there needs to be a secure way to know that the type does not exist. This can be determined by retrieving and examining all the SIG RRs. All types will be indicated within the SIGs and the partial SIG set signets in the SIGs can be used to assure that a complete set of SIGs has been retrieved. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 33] INTERNET-DRAFT DNS Protocol Security Extensions Thus a query from a security aware resolver for a name that exists for some RR in a zone but not as the owner of any RR of the requested type should be answered by a security aware server with the usual error but with all the SIGs for that name as additional information. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 34] INTERNET-DRAFT DNS Protocol Security Extensions 7. 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 7.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. 7.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 zero is the RSA algorithm and 15 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 algirithm, 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. And furthermore, some organizations may explicitly wish their "interior" DNS implementations to trust only their own zone. These interior resolvers can then go through the organization's zone server to access data outsize the organization's domain. 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 35] INTERNET-DRAFT DNS Protocol Security Extensions 7.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 optionally 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 without the mandatory 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. Never the less, 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 three hops. 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 the be prefered to a hierarhcially dervied key obtained by climbing to root and descending? This is a matter of resolver policy. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 36] INTERNET-DRAFT DNS Protocol Security Extensions 7.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 RRs ("A" records for example) which were valid but no longer are. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 37] INTERNET-DRAFT DNS Protocol Security Extensions 8. Operational Considerations This section discusses a variety of considerations in secure operation of DNS using these proposed protocol extensions. 8.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 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 increases the verification time by a factor of 4 but vastly increases the work factor of breaking the key. [RSA FAQ] 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.) Using the RSA algorithm, this protocol packs information inside an RSA signature, so larger moduluses may increase the efficiency of use of space with SIG RRs. There is a 22 octet overhead (prefix and self hash) within the signature plus all the SIG RR fields outside of the signature. However, larger moduluses also lead to larger SIG RRs which may lead to lower packing density of SIG RRs in a maximum length DNS UDP packet (currently 512 bytes). With RSA and the minimum modulus size required by this protocol, the signature before RSA encoding is 80 octets (usually resulting in 81 octets after encoding). After deducting 2 octets for the minimum 01 00 signature prefix and 20 octets for a hashed self signet, 56 octets would be available for other signets. With the maximum modulus size permitted by this protocol, the signature is usually 255 octets which leaves 233 octets for other signets. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 38] INTERNET-DRAFT DNS Protocol Security Extensions Zones may wish to adopt policies on the size of keys stored within them such that the KEY RRs for these keys will fit within a zone signed RSA algorithm SIG for efficiency or to meet other objectives. 8.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 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 also 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. 8.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 8.2). 8.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 DNS security extensions key should have a lifetime significantly over five years. The recommended maximum lifetime for zone keys that Donald E. Eastlake 3rd & Charles W. Kaufman [Page 39] INTERNET-DRAFT DNS Protocol Security Extensions are kept off-line and carefully guarded is 13 months with the intent that they be replaced every year. The recommended maximum lifetime for host keys that are used for IP-security or the like and are kept on line is 35 days with the intent that they be replaced monthly or more often. In some cases, a host key lifetime of a little over a day may be reasonable. 8.5 Key Revocation In cases where an erroneous signed key exists in the DNS system, it is useful to be able to propagate a revocation. In most cases, the natural refresh processes of DNS will eventually obtain valid, up to date key information for secondaries. However, there could be stale information out in caching servers or the like for a long time, particularly since accident or malicious action could have cause RRs, including SIGs, KEYs, etc., with very long TTLs and/or distant end- times to be distributed. There are limits to how much can be done about this problem. The DNS security extensions provide for revocation of keys. The revocation information is provided when current key information is retrieved. In addition, security aware servers opportunisticly flood revocation information by including it with low priority in the additional information section of any retrieval from the zone containing the revoked key. It is a matter of server policy how to choose which extra revocations to include as additional information. Some revocations may be "more important" than others or it may be best to simply pick at random as much as will fit. On receipt of an authenticated revocation, a resolver should expunge all RRs authenticated by the revoked key. It is a matter of resolver policy what revocations, if any, to cache and for how long. Resolvers can not keep an indefinite number of revocations for an indefinite time. The possibility of denial of service attacks based on fabricating many revocations must be considered. It should be noted that, like assertions, revocations have start and end times. Thus, for example, a valid key validly generated but accidentally given an excessive lifetime in a SIG can be revoked for just the later part of that lifetime by setting appropriate times in the revocation SIG RR. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 40] INTERNET-DRAFT DNS Protocol Security Extensions 8.6 Root The root zone key is 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 41] INTERNET-DRAFT DNS Protocol Security Extensions 9. Conformance Several levels of server and resolver conformance are defined. 9.1 Server Conformance Security aware servers MUST respond normally to requests that do not have the Security Desired bit set. Three levels of server conformance are defined as follows: Zilch server compliance is (1) the ability to ignore the Security Requested bit in queries, (2) ability to store and retrieve (incluidng zone transfer) SIG, KEY, and NXD RRs, and (3 clearing the Security Available bit in responses. It is believed that almost all 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 handle the Security Desired bit in inquiries, automatically including SIG, KEY, and NXD RRs in responses as appropriate, as well as meeting the minimal compliance except that only item 2 of zilch criteria should be met. In addition, fully compliant servers MUST turn on the Security Available bit in responses. 9.2 Resolver Conformance Two levels of resolver compliance are defined: A Zilch compliance resolver ignores the Security Available bit in responses, does not set the Security Desired bit in queries, and 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 sets the Security Desired bit in its queries, maintains appropriate infomration in its local chaches 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 42] INTERNET-DRAFT DNS Protocol Security Extensions 10. 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 distibution, 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. 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 43] 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 Digital Equipment Corporation 110 Spit Brook Road, ZKO3-3/U14 Nashua, NH 03062 Telephone: +1 603-881-1495 EMail: kaufman@zk3.dec.com Expiration and File Name This draft expires 26 Janury 1995. Its file name is draft-ietf-dnssec-secext-02.txt. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 44]