From owner-dns-security Mon Jun 1 08:07:44 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA10216 for dns-security-outgoing; Mon, 1 Jun 1998 08:03:54 -0400 (EDT) To: dns-security@tis.com Subject: Re: AXFR & NS records at delegation points References: <3673.896473876@munnari.OZ.AU> From: Paul Vixie Date: 30 May 1998 23:43:37 -0700 In-Reply-To: kre@munnari.oz.au's message of 29 May 1998 13:48:09 -0700 Message-Id: Lines: 41 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-dns-security@ex.tis.com Precedence: bulk "mount-like semantics" as a phrase describing parent/child occlusion came out of a discussion i had with PVM a few years back. in my view before that meeting, a parent's glue (including the delegation NS RRset as well as any in-child A RRs needed to reach those nameservers) was really part of the child zone and if both were loaded in the same server and a zone transfer was done of the parent, it should stop at the delegation point and should use the NS RRset of the child's zone top. it comes as no surprise, i'm sure, that this is how BIND works. BIND is wrong. PVM straightened me out. a zone transfer of the parent zone should export exactly the data which was loaded from the master file or from the parent zone's incoming AXFR. if this means an AXFR will show data which the server (which in our example is authoritative for both the parent and child zones) would not answer with, then so be it. if RFC 2181 fails to make this entirely clear, then it should be changed. the next major release of BIND will work this way. microsoft's server already works this way. this is what "mount like semantics" means: # mkdir /mnt /mnt/foo # mount /dev/sd3c /mnt # mkdir /mnt/bar # dump 0f - / | restore tvf - | grep /mnt /mnt /mnt/foo # dump 0f - /mnt | restore tvf - / /bar # ls /mnt bar # umount /mnt # ls /mnt foo i hope this helps. i can probably find past namedroppers traffic to this same effect if anyone finds the above controversial. -- Paul Vixie La Honda, CA "Many NANOG members have been around pacbell!vixie!paul longer than most." --Jim Fleming From owner-dns-security Mon Jun 1 08:07:45 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA10215 for dns-security-outgoing; Mon, 1 Jun 1998 08:03:54 -0400 (EDT) To: dns-security@tis.com Subject: Re: AXFR & NS records at delegation points References: <7650.896485308@munnari.OZ.AU> From: Paul Vixie Date: 30 May 1998 23:34:26 -0700 In-Reply-To: kre@munnari.oz.au's message of 29 May 1998 16:54:44 -0700 Message-Id: Lines: 10 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-dns-security@ex.tis.com Precedence: bulk > In any case, having different NS records in the parent and child is a > config error, and I'm not sure that anything that could be specified here > can really cope with all such errors. The child is allowed by law to have a superset of the parent's NS records. -- Paul Vixie La Honda, CA "Many NANOG members have been around pacbell!vixie!paul longer than most." --Jim Fleming From owner-dns-security Fri Jun 5 09:49:36 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA29665 for dns-security-outgoing; Fri, 5 Jun 1998 09:40:53 -0400 (EDT) Date: Fri, 5 Jun 1998 09:57:21 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: namedroppers@internic.net cc: dns-security@tis.com Subject: Re: tsig-04 Time expire/Time Signed Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk (1) It's not 110 years, I get more like 136.099 years when I calculate it. (2) There isn't any problem with SIG. The text in the current draft says: "The SIG is valid from the "signature inception" time until the "signature expiration" time. Both are unsigned numbers of seconds since the start of 1 January 1970, GMT, ignoring leap seconds. Ring arithmetic is used as for DNS SOA serial numbers [RFC 1982] which means that these times can never be more than about 136.09 years in the future. A SIG RR may have an expiration time numerically less than the inception time if the expiration time is near the 32 bit wrap around point and/or the signature is long lived." (3) RFC 2065 specified to ignore leap seconds but does not include the ring arithemtic wording. But it is to be obsoleted by the current DNSSEC draft. (4) It seems easy enough to fix TSIG by adopting similar wording. Donald ===================================================================== Donald E. Eastlake 3rd +1 978-287-4877(tel) dee@cybercash.com 318 Acton Street +1 978-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.privacy.org/ipc Date: Sun, 31 May 1998 09:17:25 -0400 From: Tom Limoncelli To: Mark.Andrews@cmis.CSIRO.AU Cc: namedroppers@internic.net Subject: Re: tsig-04 Time expire/Time Signed Mark.Andrews@cmis.CSIRO.AU wrote: > > These fields are specified as unsigned 32 bit ints. Now these > have fields have a limited lifetime of ~110 years (with > potential implementation problems in 40 years time). Now while > most of us are unlikely to be around in 110 years that is a chance > that the TSIG will still be in use in 110 years time. Remeber lots > of current code is already ~40 years old and is still in use. > >Now SIG has a similar problem to this and I'm not sure what they >intended to do about this. I'm stating the obvious but... while other protocols come and go DNS is so ingrained in all code that preventing such time/date problems now is worth the problems we prevent in the future. I'm tempted to say that major DNS problems can only be fixed when we change IP stacks (IPv4 to IPv6, IPv6 to IPv7) but somehow I doubt even that is true. Could we change the resolution (multiple by 4 before using this value, divide by 4 before storing this value), add another 8 bits, or something? Either that or everyone on this mailing list has to promise to not have grandchildren. 1/2 :-) 110 years just isn't a long time. --Tom Date: Mon, 01 Jun 1998 00:15:07 +1000 From: Mark.Andrews@cmis.CSIRO.AU To: namedroppers@internic.net Subject: Re: tsig-04 Time expire/Time Signed We also need to specify which timescale which are using. The current draft only specifies one time scale UTC. Given most O/S actually return seconds singe Jan 1 1970 GMT - leap seconds it would be better to define these fields as such. On systems where it does return the correct number of seconds there are also the appropriate tables to make the correction. Mark -- Mark Andrews, CSIRO Mathematical and Information Sciences Locked Bag 17, North Ryde, NSW 1670, Australia. PHONE: +61 2 9325 3148 INTERNET: Mark.Andrews@cmis.csiro.au MOBIL: +61 41 442 9884 UUCP:....!uunet!cmis.csiro.au!mark.andrews From owner-dns-security Tue Jun 9 14:14:15 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA14812 for dns-security-outgoing; Tue, 9 Jun 1998 14:10:22 -0400 (EDT) Date: Tue, 9 Jun 1998 13:33:41 -0400 (EDT) From: Charlie ROOT To: dns-security@tis.com Subject: DNSSEC installation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk Hi, I installed the secure DNS implementation according to the directions in the INSTALL_SEC file. When I run the proposed tests, I do not the the results expected, for instance: ./dig @localhost snore.foo.bar -p 12345 gives me "Connection refused" message /named/make test returns a number of messages concerning the not found files and directories of .PARENT's Please let me know what I might be doing wrong. Thank you very much, Yuliya Katsnelson From owner-dns-security Tue Jun 16 11:07:28 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA10797 for dns-security-outgoing; Tue, 16 Jun 1998 11:01:17 -0400 (EDT) Date: Tue, 16 Jun 1998 11:17:12 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: Charlie ROOT cc: dns-security@tis.com Subject: Re: DNSSEC installation In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk Hi, I don't know if anyone has answered you but the email address for TIS Beta Implementation support is tisdnssec-suport@tis.com. See . Unless it effects thednssec protocol, this list is probably not the best place. Thanks, Donald On Tue, 9 Jun 1998, Charlie ROOT wrote: > Date: Tue, 9 Jun 1998 13:33:41 -0400 (EDT) > From: Charlie ROOT > To: dns-security@tis.com > Subject: DNSSEC installation > > Hi, > > I installed the secure DNS implementation according to the directions in > the INSTALL_SEC file. When I run the proposed tests, I do not the the > results expected, for instance: > > ./dig @localhost snore.foo.bar -p 12345 > > gives me "Connection refused" message > > /named/make test > > returns a number of messages concerning the not found files and > directories of .PARENT's > > Please let me know what I might be doing wrong. > > Thank you very much, > > Yuliya Katsnelson > > > > ===================================================================== Donald E. Eastlake 3rd +1 978-287-4877(tel) dee@cybercash.com 318 Acton Street +1 978-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.privacy.org/ipc From owner-dns-security Tue Jun 16 14:36:18 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA11772 for dns-security-outgoing; Tue, 16 Jun 1998 14:35:04 -0400 (EDT) Reply-To: James M Galvin From: James M Galvin To: Jeff Schiller , Marcus Leech cc: iesg-secretary@ietf.org, dns-security@ex.tis.com Subject: DNS Security to the IESG MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25283.898022989.1@elistx.com> Date: Tue, 16 Jun 1998 14:49:49 -0400 Message-ID: <9806161449.aa25287@one.eListX.com> Sender: owner-dns-security@ex.tis.com Precedence: bulk Let's try this again. I'm pretty sure I got it right this time, really! As Chair of the DNS Security Working Group with this message the working group is submitting the following documents to be considered for publication as Proposed Standards: draft-ietf-dnssec-secext2-05.txt draft-ietf-dnssec-dss-02.txt draft-ietf-dnssec-rsa-00.txt draft-ietf-dnssec-certs-02.txt draft-ietf-dnssec-dhk-02.txt The following documents are being submitted to be considered for publication as Experimental: draft-ietf-dnssec-indirect-key-01.txt draft-ietf-dnssec-ddi-05.txt The following document is being submitted to be considered for publication as Informational: draft-ietf-dnssec-secops-01.txt These documents represent consensus although not unanimity. Concerns fall in to the categories of specification clarity and lack of operational experience to be absolutely certain of a few technical choices. There are also some subjective concerns regarding the utility of a few functions and features. Nonetheless, it is my opinion these documents represent "as far as we are going to get" with respect to resolution. Further, it is my opinion that operational experience will present the necessary "clarity of opinion" to permit resolution of the concerns when the documents are eligible to be advanced to Draft Standard. Operational experience is problematic unless these documents are advanced as indicated. During your review please note that the first three documents are a logical set replacing RFC 2065. RFC 2065 is the current Proposed Standard for DNS Security. The technical changes between this version and that version require recycling at the Proposed Standard level. Note further that the first two documents are required to advance together according to IETF rules regarding encumbered technologies; the third is text split from RFC 2065 so as to permit the DNS Security extensions themselves to be algorithm independent. Finally, the last document was started with text from RFC 2065 and has grown based on the limited experience available from operating a secure DNS server. For context you may wish to note that it is the working group's ultimate objective that a revision to this document be advanced to BCP coincident with the DNS Security specification's ultimate advancement to an Internet Standard. Enjoy, Jim -- James M. Galvin Director, Electronic Commerce Technologies CommerceNet Consortium +1 410.549.5545 http://www.commerce.net +1 410.549.5546 FAX From owner-dns-security Tue Jun 23 14:26:42 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA00735 for dns-security-outgoing; Tue, 23 Jun 1998 14:20:53 -0400 (EDT) Date: Tue, 23 Jun 1998 14:38:27 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: dns-security@tis.com cc: namedroppers@internic.net Subject: Re: draft-lewis-dnskey-referral-00.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk My apologies for taking so long to getting around to reviewing this draft... And my apologies for the lack of clarity of the wording of section 2.3.4 of the current draft (draft-ietf-dnssec-secext2-05.txt) which probably contributed to a perceived need for a mechanism like that specified in this draft... > Domain Name System Security WG Edward Lewis > INTERNET DRAFT TIS Labs > Jerry Scharff > ISC > John Gilmore > > June 1, 1998 > > The Zone Referral Key > > > 0.0 Status of this Memo > > ... > > 1.0 Abstract > > ... > > 2.0 Introduction > > ... > > 2.1 Performance Issues > > A sample zone will be used to illustrate the problem. The > example will part from reality mostly in the length of zone > names, which changes the size of the owner and resource record > data fields. > > # $ORIGIN test. > # @ IN SOA > # IN SIG SOA > # IN KEY <1024 bit zone key> > # IN SIG KEY > # IN SIG KEY > # IN NS ns.test. > # IN SIG NS > # IN NXT my-org.test. NS SOA SIG KEY NXT > # IN SIG NXT > # > # my-org IN KEY <1024 bit zone key> > # IN KEY <1024 bit zone key> > # IN SIG KEY > # IN NS ns1.my-org.test. > # IN NS ns2.my-org.test. > # IN NXT them.test. NS SIG KEY NXT > # IN SIG NXT > # > # them IN KEY 0xC100 3 1 > # IN SIG KEY > # IN NS ns1.them.test. > # IN NS ns2.them.test. > # IN NXT test. NS SIG KEY NXT > # IN SIG NXT > > In this zone file fragment, "my-org" is a delegation point of > interest with two registered public keys. Presumably, one key > is for signatures generated currently and the other is for still > living and valid but older signatures. "them" is another > delegation point, with a NULL key. This signifies that this zone > is unsecured. > > To analyze the performance impact of the storing of keys, the > number of bytes used to represent the RRs in the procotol format > is used. The actual number of bytes stored will likely be > higher, accounting for data structure overhead and alignment. > The actual number of bytes transferred will be lower due to DNS > name compression. > > The number of bytes for my-org's two 1024-bit keys, two NS > records, NXT and the associated signatures is 526. The bytes > needed for them (with the NULL key) is 346. Currently, there Suggest putting quotation marks around every occurance of "them" or choosing a different name, otherwise it's very confusing. > are close to 2 million entries in com., so if we take my-org as > a typical domain, over 1GB on memory will be needed for com. I don't think this is true for a number of reasons. FIRST of all, it looks like I did a poor job in the wording of secext2 section 2.3.4, since for a secured child of a secure parent zone I meant it to say that it is permissible for the child KEY signed by the parent to appear only in the child zone. The only case in which the KEY for a child MUST appear in the parent would be a secure parent of an insecure child where, for some reason, the child zone can not have the NULL KEY with parent SIG added to it. The exact wording in the older RFC 2065 and newer draft-ietf-dnssec-secext2-05.txt is older RFC 2065, 2.3.4: In general, there must be a zone KEY RR for the subzone in the superzone and the copy signed in the superzone is controlling. For all but one other RR type that should appearing in both the superzone and subzone, the data from the subzone is more authoritative. To avoid conflicts, only the KEY RR in the superzone should be signed and the NS and any A (glue) RRs should only be signed in the subzone. The SOA and any other RRs that have the zone name as owner should appear only in the subzone and thus are signed there. The NXT RR type is an exceptional case that will always appear differently and authoritatively in both the superzone and subzone, if both are secure, as described in Section 5. newer draft-ietf-dnssec-secext2-05.txt, 2.3.4: There MUST be a zone KEY RR, signed by its superzone, for every subzone if the superzone is secure. In the case of an unsecured subzone which can not or will not be modified to add any security RRs, a KEY declaring the subzone to be unsecured MUST appear in and be signed by the superzone, if the superzone is secure. For all but one other RR type the data from the subzone is more authoritative so only the KEY RR in the superzone should be signed. The NS and any glue address RRs should only be signed in the subzone. The SOA and any other RRs that have the zone name as owner should appear only in the subzone and thus are signed only there. The NXT RR type is the exceptional case that will always appear differently and authoritatively in both the superzone and subzone, if both are secure, as described in Section 5. The new wording was supposed to permit the child KEY with parent signature to appear in the parent, in the child, or in both. Note the deletion of the first sentence in this section from RFC 2065. And I think that a careful reading of the first two sentences in draft-ietf-dnssec-secext2-05.txt, section 2.3.4, says that, especially since it says that the unmodifyable insecure child is the only case where the child KEY and parent SIG must be in the parent. Unfortunately, I failed to change the third sentence which somewhat contradicts the first two and seems to say that you can't have the parent SIG on the child KEY in the child zone. SECOND, it is unreasonable to assume that all children will have two zone KEYs. The TTL will probably be less than the key lifetime so there is no reason for successive generations of KEY to overlap by half their life. It is more plausible to assume something like 5% or 10% of the names have two keys. THIRD, 1024 is a pretty big KEY. draft-ietf-dnssec-secops-*.txt recommends 768 in most cases. Anyway, the really big thing is that it was intended that setext2 say that the child KEY with parent SIG may occur only in the child. > The zone keys used in the example are set to 1024 bits. This > number may range from as low as 512 bits upwards to over 3000 > bits. To scale the above numbers to a different key size, > multiply the difference in key sizes by 4 for my-org and by 2 > for them, and adjust the numbers accordingly. Suggest putting quotation marks around "them" or choosing a different name, otherwise it's very confusing. > The increased size of the data held for the zone cuts will have > two impacts at the transport and below layers. Bandwidth beyond > that currently needed will be used to carry the KEY records. > The inclusion of all of the child's keys will also push DNS over > the UDP size limit and start using TCP - which could cause > critical problems for current heavily used name servers, like > the roots. It was specifically the working group consensus not to worry too much about UDP overflow. As long as the most common case (one KEY) would usually fit, it was thought that other mechanisms, such as increased UDP size, would be in place for secure DNS servers and resolvers by the time the percentage of requests that overflowed due to security RRs was a problem. Of course, this working group decision can be revisited. And in any case, you still have these increases in data quantity for the child... > Another impact, not illustrated by the example, is the frequency > of updates. If each time a public key for my-org is added or > deleted, the SOA serial number will have to increase, and the > SOA signed again. If an average zone changes its keys(s) once > per month, there will be on average 45 updates per minute in a > zone of 2 million delegations. This seems like a red herring. A huge rapdily changing zone will, as a practical matter, have to batch changes. There are plenty of NS and glue A changes as well. I understand that .com has an update rate of well over 100,000 updates a month for changes to existing delegations. That's over two a minute without DNSSEC, less than 45 a minute but still very substantial. You may have a good arguement as to why large zone DNS dynamic update is problematical with the current DNS in some cases, but it has little to do with DNS security. And, actually, the SOA only needs to be changed if it can be seen. I.E., you could adopt a strategy of installing successive changes to a zone without updating the SOA serial number until an operation occurs which reads the SOA serial number and there has been a change since the previous read of the SOA. This conserves SOA serial number states. And, of course, this does not apply if the child KEY signed by the parent isn't in the parent zone at all. > 2.2 Security Incident Recovery (w/ respect to keys only) > > Once a zone administrator is alerted that any key's private > counterpart has been discovered (exposed), the first action to > be taken is to stop advertising the public key in DNS. This > doesn't end the availability of the key - it will be residing in > caches - but is the closest action resembling revokation > available in DNS. This assumes that both parent and child are secure and that the parent has chosen to include the child's KEY(s) signed by the parent in the parent zone. It is certainly desireable for the parent to stop advertising a public key if it has learned via a secure channel that is at least as secure as the child zone was that the child private key has been compromised. But this is just another service of the parent. One would assume that parent zone service contracts would specifically cover this for someone providing DNS services with DNSSEC. > Stopping the advertisement in the zone's name servers is as > quick as altering the master file and restarting the name > server. Having to do this in two places will will only delay > the time until the recovery is complete. As above, for secure children, you don't have to have their KEY in the parent zone, so you don't have to update it in two places. And, in a secure DNS environment, stopping the advertisement of a child KEY signed by the parent (regardless of whether it is in the child zone, parent zone or both) is tanamount to turning off service for the zone completely. New security aware resolvers coming along will refuse to answer questions concerning data in the zone. (In any case, you need to securely communicate the new child private key to the parent so the parent can sign it and you can start advertising the new child KEY signed by the child in the child zone. And how do you do that? PGP? Well then, what if your PGP key is compromised also? But if you can't communicate securely from the child to the parent then how was it that the parent was really sure that the claim that the child's key was compromised was genuine? This is a bit of a diversion, but it all comes down to who / what do you trust? Perhaps their should be a DNS operation to ask the parent to sign a new KEY. Seems like it would have the same data flow characteristics as update: you would want to send it to or have it forwarded to the primary server; if the parent private key was on line, you could get an answer in real time, otherwise you'd have to check back later...) > For example, a registrar of a top level domain has decided to > update its zone only on Mondays and Fridays due to the size of > the zone. A customer/delegatee is the victim of a break in, in > which one of the items taken is the file of private keys used to > sign DNS data. If this occurs on a Tuesday, the thief has until > Friday to use the keys before they disappear from the DNS, even > if the child stops publishing them immediately. As I say, someone running a secure zone and offering to sign child zone cutomer's KEYs and possibly store them in the parent zone will have covered all this by agreemnt. They KEY need not be in the parent zone. > If the public key set is in the parent zone, and the parent zone > is not able to make the change quickly, the public key cannot be > revoked quickly. If the parent only refers to there being a key > at the child zone, then the child has the agility to change the > keys - even issue a NULL key, which will force all signatures in > the zone to become suspect. The public key does not have to be in the parent zone. Yes, with what you seem to be implying a referral key is, the child can change keys, and so can a cracker since the referral key provides *no* cryptographic security for any data in the child. This "agility" is insecure. This whole concept of rapid key "revocation" in DNS is quite problematical depending on the threat model you are using. There is no true revocation in DNS and if there were, the bad guys could block it from at least some victims they were trying to spoof. For as long as the child key was valid at the time the compromise of the private key was discovered (i.e., the intersection of the validity periods of the child key, parent key, grandparents key, etc., up to root), the bad guy can still do spoofing. > 2.3 DNS Clarifications > > RFC 2181, section 6, clarifies the status of data appearing at a > zone cut. Data at a zone cut is served authoritatively from the > servers listed in the NS set present at the zone cut. The data > is not (necessarily) served authoritatively from the parent. > (The exception is in servers handling both the parent and child > zone.) Unqualified use of the word "authoritative" in connection with DNS RRs and DNSSEC almost always results in confusion. As I see it, there are three kinds of "authoritative": the common english language meaning, the cryptographic meaning, and the DNS term-of-art meaning. Assuming you want a cohesive root and interoperable naming and ignoring special cases of local knowledge and special cases of cross certification, then basicly all DNS reality flows down from the root zone. In the normal English language sense, root has all authority and subsets of authority get delegated down. The concept that, for example, there is one true "exxon.com", say, independent of what root and .com say is absurd. If you doubt this, consider that some random person got exxon.com and sold petrolium products from a web page, that Exxon sued them in US court and won, getting a court order saying they had a right to exxon.com but that the previous exxon.com entity and servers were pysically located in areas untouchable by the US court order. Can you really doubt that .com would be changed and that that change changes the real exxon.com for almost all the Internet? So obviously, .com has, from the DNS protocol point of view, absolute and totaly life and death authorithy over all second level domain names in it. Note that this is the English language sense of authority, not the DNS term of art. More or less the same is true of cryptogrphic security. Sure, you can have additional locally configured keys and cross certification, etc., but for the vast majority of secure resolvers the vast majority of the time, their belief in verified DNS reality will stem from a staticly configured root (actually meta-root) key. This type of cryptographic authority flows from root down wards. The signature on data and KEYs from the current zone key and the signatures on zone key by their parents are the important things. And cryptographcially it makes not the slightest difference where RRs are found. A KEY and a SIG on it printed on a muddy piece of paper lying the gutter and just a good as a retrieval from a primary server that is "authoritative" in the sense of the DNS term of art. And cryptographic "authority" is much, *much*, MUCH, *MUCH* better than DNS term of art "authority" in terms of resisting spoofing, which is why there is an DNSSEC effort. While you DNS term of art "authority" is basicly a hack. Maybe in the distant past where there was much less network abuse and conflict and much more trust in the entire Internet population, it was reasonable to just trust data that the sender had labeled as "authoritative" (along with trusting whatever they send as additional information). And maybe even now, with abuse and conflict more common, the DNS "authority" hack, when used with some paranoia and great care, makes some sense on balance as allowing the child administrator to make limited changes to the NS set of their zone (and long as at least one of the NSs still listed by the parent is up so you can get the updated child version) before the changes get into the parent. And maybe, to minimize changes and because DNSSEC makes no claims to stop denial of service, it is reasonable to stick with things working the DNS "authority" way (except for NXT). But, I think if DNS were being designed today from the ground up, RRs would be explicitly labeled with the zone they were from and most likely parental information would override child information. On way to view DNSSEC is as more or less operating on top of a resolver that works entirely according to the old DNS rules. The security layer does the verfication chains from one or more statcily configured trusted keys and issued addtiional retrieval requests for KEYs, SIGs, and NXTs. But, ignoring implementation difficulties, the optimium thing would be to keep around different RRsets from different sources while you were trying to cryptographcially verify them (instead of throwing away "DNS less authoritative" ones) and any that cryptographically verified should always win out over "DNS authoritative" ones that don't cryptographically verify because the cryptographic check is so many orders or magnitude stronger than the DNS authority hack. Only in the case of multiple RRsets with the same cryptographic verification status is it the best thing to select based on "DNS authoritativeness". > Section 6 also mentions that there are two exceptions created by > DNSSEC, the NXT single record set and the KEY set. This > proposal addresses the exception relating to the KEY set, > limiting its severity (but falling short of removing it > altogether). By limiting the exception, we will be simplifying > DNS. I dunno. IT seems to me that you are making DNS more complex by sometimes using the DNS special sense of "authoritative" to let a child KEY override the copy in the parent (if it happens to be the proposed "referral key") and sometimes not (for all of the current varieties of key). This adds more cases (in fact, more insecure cases) and thus makes DNS more complex, not simpler. If I was designing DNSSEC from scratch, I would use a different RR type for the NXT RR at a zone apex and perhaps require the child KEY signed by the parent to occur in the child zone for all cases except where the child is an unmodified insecure zone (in which case the NULL KEY signed by the parent must occur in the parent but there is no "DNS more authoritative" KEY in the child to override it anyway). There would be nothing wrong with optionally *also* putting the child KEY signed by the parent in the parent. At that point, DNSSEC would be closer to traditional DNS "authority" and RRset logic and I think it would be almost exactly on if the proposal to use the top bit of the type field to indicate signature RRs so there was a signature RR type for every regular RR type, but the WG consensus was not to use up halfe the RR type space like that... > 2.4 Liability > > Liability is a legal concept, so it is not wise to attempt an > engineering solution to it. However, the perceived liability > incurred in using DNSSEC by registrars may prevent the adoption > of DNSSEC. Hence DNSSEC should be engineered in such a away to > address the concern. > > One source of liability is the notion that by advertising a > public key for a child zone, a parent zone is providing a > service of security. With that comes responsibility. By having > the parent merely indicate that a child has a key (or has no > key), the parent is providing less in the way of security. If > the parent is wrong, the potential loss is less. Instead of > falsely authenticated data, configuration errors will be > apparent to the resolving client. I think the above is nonsense. Operators of zones provide data. In the normal case where they operate a cutpoint, they provide such data for the child that the child supplies. No doubt for gTLDs and the like, an agreement will be required limiting the liability of the parent. In its absence of such agreement, the parent will just use NULL KEYs and advertise that, as far as they are concerned, the child is insecure. The referral key is not substantially more secure than no security at all for the child (see further discussion below). >From what has been said so far, the referral key provides no cryptographic security for the child zone data whatsoever. If legal fears are going to stop zones managers from signing the KEYs of their child zones, then there won't be DNS security. The parents might just as well put in NULL KEYs for all their children or just plain run an insecure parent zone. And, in fact, where there is usually no organizational relationship between the parent and the child, as in .com, I strongly suspect the parent zone, when secured, will in fact put in NULL KEYs for all child zones that have not entered into clear binding liability limiting contracts. (With the interesting consequence that, if real KEYs and parent signature are only in the child, the parent zone gets *smaller* as more of its children are secured.) On the other hand, way below, there is a hint that even with the proposed "referral key", the parent still would sign the child KEY. *That* is the real security. Cryptograhic principles say to trust things based on signatures no matter where found. The only "security service" of importance the parent does is provide a signature. That is the real source of any liability. The parent signature has to be made available somehow but cryptographically, it make no difference where it is found. In some sense, everyone hosting secure web sites is providing a security service and you don't see them quaking in their boots or being sued just because they run a secure web server. > 3.0 The Proposal > > The proposal is to introduce a new key type which indicates > whether the delegated zone is running secured or not. Running > secured is either a zone signed with at least one key, an > experimental zone, or a zone with only NULL keys published. The paragraph above and below both seem to hint that the child KEY might only be signed by itself. That's an odd thing to call running secured if there is a parent the could have signed the child KEY but didn't. For most of the world (everyone but those with direct knowledge of the child public key), there is no way to authenticate the child data those way. And I really don't understand the last bit above about "only NULL keys published". There being only NULL KEYs for a zone is almost the definition of it being *insecure*. > The Zone Referral Key will resemble the NULL key in syntax. > There will be a flags field, an algorithm field, and a protocol > field, but no public key material. The Referral Key is signed > by the parent zone, as was the public key set in RFC 2065. > There is only one Referral Key RR present. > > The Referral Key flags field will have the following values: > Field Bit(s) Value Meaning > > A/C 0- 1 0b01 indicates a key will be found > 0b11 indicates a key will not be found > 0b?0 error (referral cannot encrypt) As I see it, this "referral key" is a sort of a special insecure restricted form of indirect key as specified in draft-ietf-dnssec-indirect-key-*.txt. As such, it makes more sense to me for the authentication use prohibited and confidentiality use prohibited bits (A/C) to refer to the key pointed to by the "referral key" rather than to the "referral key" itself. > XT 2 0 no extended flags are needed > Z 4- 5 0 must be zero for all keys > NAMTYP 6- 7 0b11 this is a referral to a zone key This field is name type. That is, it is the type of the RR owner name. The owner name of the proposed Referral Key is a zone. These bits should therefore have the zone name type value of 0b01. Using a value for this field for other than name type is a misuse of the field. > Z 8-11 0 must be zero for all keys > SIG 12-15 0 must be zero for a referral key > > The legal values of the flags field are (in summary): > > Hex Value Indicates > 0x4300 The delegation has a key record set > 0xC300 The delegation has no key record > > Other values are not valid for Referral Keys (but may be valid > for other keys). > > The Protocol field must be set to 3, the DNSSEC protocol value. I suppose you could require this protocol field value for the proposed "referral key" but since it is a zone key and should have NAMTYP of zone, the current secext2 draft permits that NAMTYP to be used to imply that the key can be used for DNS. > The Algorithm field must be set to 0. Since you shouldn't use the name type field to indicate this sort of indirect key, you need to use something else in the KEY RR. In draft-ietf-dnssec-indirect-key-*.txt, it proposes to use a special algorithm field value. Alternatively, you could use some other flag bit. > 3.1 Example > > The Referral key for my-org.test. and them.test. would appear as > the following in the zone master file: > > my-org.test. IN KEY 0x4300 3 0 > them.test. IN KEY 0xC300 3 0 > > In the example introduced earlier, the master file would change > to the following. > > # $ORIGIN test. > # @ IN SOA > # IN SIG SOA > # IN KEY <1024 bit zone key> > # IN SIG KEY > # IN SIG KEY > # IN NS ns.test. > # IN SIG NS > # IN NXT my-org.test. NS SOA SIG KEY NXT > # IN SIG NXT > # > # my-org IN KEY 0x4300 3 0 > # IN SIG KEY > # IN NS ns1.my-org.test. > # IN NS ns2.my-org.test. > # IN NXT them.test. NS SIG KEY NXT > # IN SIG NXT > # > # them IN KEY 0xC300 3 1 > # IN SIG KEY > # IN NS ns1.them.test. > # IN NS ns2.them.test. > # IN NXT test. NS SIG KEY NXT > # IN SIG NXT > > 4.0 Analysis > > By removing the public keys from the parent's master file, the > parent is no longer a road block during an emergency removal of > keys. A parent zone is unchanged as a zone changes from NULL > keys to experimental keys to fully signed. The parent is also > not providing a security service, other than to authentically > claim the existence of a KEY record set - akin to the "hints" of > the name servers. There is no need for the referral key to get the child public key out of the parent zone file. As mentioned above, this was intended to be permitted under draft-ietf-dnssec-secext2-05.txt. Just putting it in the child and leaving it out of the parent, when both are secure, has the virtue of retaining the data origin authentication that is the main goal of DNSSEC, as opposed to throwing it away which is what the referral key does. You also keep conveniently overlooking that the sort of insecure indirect key you propose *throws* *away* all cryptographic security for the data in the child. You not longer have data origin authentication. You no longer have integrity. You are now totally spoofable with only a tiny constant increment in effort over spoofing a child zone for which the parent has a NULL KEY. Sure, the parent is no longer performing the security service that was really important, signing the child KEY, so as a result, you don't have any security. > The change also improves the prospect for performance. The need > for multiple KEY RR's, each one on the order of 100 bytes, is > removed and replaced by a single KEY RR of the order of 25 > bytes. Saving bytes reduces the need to use TCP to avoid > truncated responses. Also, the need for updating the zone drops > - no longer will there be updates for each key change. Just leaving the zone KEY(s) out of the parent and leaving them in the child reduces the parent memory and transfer load even further. But neither that nor the proposed referral key has any effect on the memory and transfer load in the child. Nor, as I say above, is it clear that multiple KEY RRs will be that common. > As far as the statements by RFC 2181 conerning authority levels, > the Referral Key is not authortative and would be superseeded by > a verified set of the real zone keys. The only caveat is that > once the verified set of keys expire (assuming the parent has to > learn the keys from another server), the Referal Key must > reappear. This is an example of what has been labelled "mount- > like semantics." > > [No reference for mount-like semantics has yet been found.] How about the mount man page? > The last point is important. This requires the "mount-like > semantics" that have been discussed for the BIND name servers. > Once hints are overridden by learned, authorititative and > verified data, the hints are not discarded. Hints in this state > are stored and become visible when the learned data expires. I think that would be a good thing totally independent of anything to do with DNSSEC. > 5.0 IANA Considerations > > ... > > 6.0 Security Considerations > > There has been some debate about whether the Referral key should > be treated as a hint - just like the NS records. If so, then > there is no need to sign the Referral Key, and an unsigned > (hence non-authenticated) security record is of little value. > So, is the Referral Key even needed? What debate? I sure didn't see any. No, the Referral KEY is not needed. The signature of the parent on the child zone KEY is what is critial. And, under the general principles of cryptographic security, the best evidence is the authentication chain back to a known trusted public key. It really makes no difference to cryptographic veification where you find the child key signed by the parent (or by some other key your policy says you would trust in this instance). Finding it in the child zone or lying in a gutter somewhere are fine, from a cryptographic point of view. > Authentication in DNSSEC is done from the data "back" towards a > trusted point - e.g., "up" to the root. Since the > authentication is done by going repeatedly from child to parent, > why bother having the parent indicate the status of the child? It depends on your point of view which way this goes. > The answer is in the scenario in which a resolver somewhere has > obtained data which fails the verification process. Perhaps the > signature is wrong, a key in the chain of trust is unavailable, > the set should have had a signature, but none is found (or vice > versa), or the trail of signed-by names is not acceptable. In > this case, the resolver needs to find the authoritative zone, > its status and its name server set. > > If a zone is being attacked by a masquerader, and parents do not > make any statements about the security of child zones, then an > easy and successfull attack may occur. An attacker only needs > to supply either fake name server records or glue records to > redirect queries. Not particularly. If the parent is secure, the a secure resolver MUST find either a NULL KEY signed by the parent or a real KEY for an algorithm it trusts signed by the parent. If it can't find either of these, then it can never determine that the child data is either Authoritative or Insecure, instead the data will stay Pending and only be visible to requests that have the CD (Checking Disabled) bit on. While an attacker can re-direct queries, this is not logically different from seizing control of the server machine or of controlling net traffic and spoofing all replies from the server machine. All may be effective denial of service attacks (and DNSSEC explicitly disclaims any denial of service protection) but they can not lead to the acceptance of false child data (if the child and parent are secure). (This parent zone secure logic, of course, ultimately leads one back to root. I wanted to just declare that root always has to be secure but there were argument that a general secure resovler should just look at its staticly configured keys and if root is insecure there would be a staticly configured NULL KEY for it, in which case you would only have security for lower parts of the tree where a real apex KEY was staticly configured.) > While this attack will not be stopped as far as denial of > service, the masquerader can be stopped from being accepted as > an authoritative source if the parent of the zone claims the > child is secure and signs the public keys of the true child and > not the masquerader. Hold on here... this is the first time you have said *anything* about the parent signing the child's keys. That would make it a totally different story. As long as you require that, the proposed Referral Key becomes merely superfluous... But so much of the wording above talks about the parent just "authentically claim the existence of a KEY record set", rather than actually signing the child KEY RRset, that I'm not sure what was intended. If the parent only authentically says there are KEYs in the child but does not sign the child zone key, you have no security. > The masquerader cannot successfully claim that the zone is > unsigned, because it must have a zone key signed by the parent. > NULL or not, the key would not be trusted by the resolver, > assuming the parent has not also been duped. The resolver, > sensing this, should report an error or security incident, and > not accept data. Yes, if you require parent signature on the child KEY(s), which is the important parental security service. > 7.0 Author's addresses > > Edward Lewis Jerry Scharf John Gilmore > Sorry to go on so long... Thanks, Donald ===================================================================== Donald E. Eastlake 3rd +1 978-287-4877(tel) dee@cybercash.com 318 Acton Street +1 978-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.privacy.org/ipc From owner-dns-security Tue Jun 30 14:33:33 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA01485 for dns-security-outgoing; Tue, 30 Jun 1998 14:29:22 -0400 (EDT) Message-Id: <199806301845.LAA21244@bb.rc.vix.com> X-Mailer: exmh version 1.6.9 8/22/96 To: dns-security@tis.com cc: namedroppers@internic.net Subject: Re: draft-lewis-dnskey-referral-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 30 Jun 1998 11:45:10 -0700 From: Jerry Scharf Sender: owner-dns-security@ex.tis.com Precedence: bulk This is a response to the parts that impact only secext2 and this proposal. There is a second part that covers the whole discussion of authority and 2181. Justification issues: My understanding of why we "needed" the key in the parent was as follows: If you have a parent zone secured and a child zone secured, you have to be able to tell the query source whether to reject unsigned responses from the child. The original system did this, but at the expense of the parent having to do key management for the child. If I understand the new proposal right, there is no requirement that the parent return anything other than the delegation glue if the parent and child are both secured. Is the parent still required to return null records for unsecured children? Our proposal was to keep the logic of the parent always returning a signed key, but removing the content and only having it be a consistent flag, the negation of the null key. The motivation for this was to allow large registries to more easily/quickly deploy secure DNS. Partly I am confused because you have argued for this in the past. If I read your new text for 2.3.4, it does not say at all what you said you wanted it to say. This is a major change in functional logic from 2065, and to kind of slide it in with a subtle interpretation in a text rewrite is bad. I have talked to the other authors and they strongly believe that this new view of delegation logic is bad and shold not be done. If it is decided that removing the requirement for any security related glue in the case of a secure parent and child, then this whole proposal becomes moot and the registries can simply go the route of least resistance. Again, the authors do not believe that this change in delegation logic is well considered and thus continue to believe that this proposal is needed to allow secure chlidren to be flags without dealing with key management. Your assumptions about how many keys people keep are different than mine. The idea of a 5-10% rollover time seems ludicrous to me if I'm talking about an action that requires communicating with a registry. The whole reason for this proposal is to allow registry/user situations to work with DNSSEC in place. I know mark kosters and I like mark and there is no way I am going to trust the Internic to never miss a submission on a 30 day rollover key for my .com zone. The whole idea of explicit start and stop times in keys is that I can stay safe by sending the key in long enough ahead of time that I can handle the problems. I'll admit that some of the numbers are abitrary, but there will be a whole bunch of dual key records. Speaking as an operator of a root nameserver, "specifically the working group consensus not to worry too much about UDP overflow" is very scary. The UDP size increase for DNS will take many years to deploy, so it's not going to save me. The idea that the roots would suddenly shift a significant percentage of their traffic to TCP after having fully processed the request once and not be extremely negatively impacted is silly and not the right thing if you care about the internet working when we try to deploy DNSSEC. There are two reasons why this is less of a problem in the child. The children are less of a hot spot than the roots, and since the person who controls the master can make the change, there is less need to have dual keys. I am keeping dual keys to protect myself from registry snafus. I agree that the issue of SOA counts is weak, but the rate of installed/changed data for secured subzones is not. Speaking as someone who dabbles in the registry world, casually saying that there might be a factor of 10 or 20 increase in change requests that need to be installed in the advertised zone scares me. Since I already know that I am facing exponential growth as a base, this hurts all the more. If the child key signing is an offline process independent of the zone generation, the scaling problem can be handled more easily. I agree that stopping advertisement of a key does not solve the attack, since the key can be used in many situations even after the key has been pulled from the parent zone. It is again a sympathy for the legal departments of a registry that it is unpleasant to not react with the desired speed of the customer. As a registry, I just want to never be involved with this. Your complete dismissal of the liability issue is at odds with what I have seen in the registry world. People like to sue registries, and this is trying to remove one opportunity. Waiving away the legal exposure of doing someone else's key management for them is not going to aid in getting secure DNS deployed. One key point of doing the key in the child only is that you do not need super secure communications from the child to the parent and back. Since the real key is only advertised by the child, and the child will only advertise it after it has checked that what it got back was what it sent signed by the parent, this removes the risk of forgery. You can still forge the secure/unsecure my zone messages, but that's a simpler attack to detect/solve. Specification issues: I have removed all the specific comments that are restatements of issues brought up in the justification area. 3.0 > The paragraph above and below both seem to hint that the child KEY > might only be signed by itself. That was not our intent. We can add a sentence to the first paragraph making it clear that then signature chain of child key signed by parentis still required. > Since you shouldn't use the name type field to indicate this sort of > indirect key, you need to use something else in the KEY RR. In > draft-ietf-dnssec-indirect-key-*.txt, it proposes to use a special > algorithm field value. Alternatively, you could use some other flag > bit. This idea is much different that indirect keys as decribed in the i-d you mentioned. This is a strict parent child relationship with the sole goal of removing the requirements on the parent to do key management for the child. Since this is directly comparable to the NULL key for an unsecure child zone, we consider a design that uses the same mechanism as the NULL key, ie. flags, makes the most sense. 4.0 > You also keep conveniently overlooking that the sort of insecure > indirect key you propose *throws* *away* all cryptographic security > for the data in the child. You not longer have data origin > authentication. You no longer have integrity. You are now totally > spoofable with only a tiny constant increment in effort over spoofing > a child zone for which the parent has a NULL KEY. Sure, the parent > is no longer performing the security service that was really > important, signing the child KEY, so as a result, you don't have any > security. Don, this is simply not true. Given that we believed that there needed to be some key, we chose to create a key that never validates and signals the resolver to get the valid key from the child. There is no loss in cryptographic security at all. The child still needs to offer a key that has a parent sig on it for it to be accepted, and the keys in the parent are still signed so they can not be forged by someone not capable of generating a parent sig. You managed to leap to an assumption that we had changed the entire logic of DNSSEC such that we are no longer requiring the parent to sign the child key, then used it to go on and on about the proposal. You even later in the response get that fact and still don't say what's needed is a clarification of 1 paragraph. jerry From owner-dns-security Tue Jun 30 14:37:27 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA01528 for dns-security-outgoing; Tue, 30 Jun 1998 14:37:14 -0400 (EDT) Message-Id: <199806301852.LAA21328@bb.rc.vix.com> X-Mailer: exmh version 1.6.9 8/22/96 To: dns-security@tis.com cc: namedroppers@internic.net Subject: Re: draft-lewis-dnskey-referral-00.txt (part 2) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 30 Jun 1998 11:52:26 -0700 From: Jerry Scharf Sender: owner-dns-security@ex.tis.com Precedence: bulk Don, Now on to the other part of your message. I found truly unfortunate your whole discussion about DNSSEC/DNS interactions. I will not even address what parts of it I agree or disagree at this time, other than to clarify that we were never discussing anything other than the AA bit in a DNS response. From my understanding, 2181 was done at least in part to address the specification issues in DNS that were damaged by DNSSEC. To now say that there were key pieces missing and you think that 2181's ideas are wrong is to say that 2181 failed to do what was needed to clarify DNS so that DNSSEC can work "right". This in itself is not a problem, the next part is the problem. The ISC and TIS have made hard commitments to funders to deliver a fully functional version of of BIND/DNSSEC with specific deadlines. This will be widely distributed and will be the basis of all future BIND development. We have worked quite hard forging this agreement and have worked with many of the people who deliver BIND to the end users to prime them for this delivery. We can not wait for the IETF to take another n months to hash this out. It's not that the implementation defines the spec, but the implementation has to take a snapshot of the spec and code to that. If you don't like what 2181 says, it had better get it fixed and fixed fast or you will live with it for a long time. We believe this is the right thing to do, because we believe getting DNSSEC successfully deployed is the only reason for doing all this work in the first place. jerry