From owner-dns-security Tue Sep 9 16:52:43 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA29833 for dns-security-outgoing; Tue, 9 Sep 1997 16:47:19 -0400 (EDT) Date: Tue, 9 Sep 1997 16:51:03 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: dns-security@tis.com Subject: draft chagnes 1 Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk Hi, I plan to make the following changes in the current (...secext2-01...) draft unless there is substantial objection: Appendix C: To make the code look a bit more like normal C code and to strenthen the checksum a little, it will be changed to return an int (with an appropriate commend about storing the int's octets in network order) and the last occurance of 0xFF will be changed to 0xFFFF. Protocol Octet: A value will be assigned for the dnssec protocol and it will specify that the octet should have that value on zone keys. KEY RR: The KEY RR for a zone should be automatically returned on queries of the SOA for that zone, as well as NS queries. The odd pharasiology used in the section on returning spontaneous KEY RRs on queries where it says "... must be returned if there is space ..." will be changes to say "... SHOULD be returned ...". Donald ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-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.eff.org/blueribbon.html WARNING, on 1 Oct 1997, +1-508 may change to +1-978. From owner-dns-security Thu Sep 11 10:18:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA00901 for dns-security-outgoing; Thu, 11 Sep 1997 10:14:58 -0400 (EDT) To: IETF-Announce@ietf.org Cc: dns-security@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnssec-dss-00.txt Date: Thu, 11 Sep 1997 10:10:31 -0400 Message-ID: <9709111010.aa07937@ietf.org> Sender: owner-dns-security@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Security Working Group of the IETF. Title : DSA KEYs and SIGs in the Domain Name System Author(s) : D. Eastlake Filename : draft-ietf-dnssec-dss-00.txt Pages : 7 Date : 10-Sep-97 A standard method for storing US Government Digital Signature Algorithm keys and signatures in the Domain Name System is described which utilizes DNS KEY and SIG resource records. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnssec-dss-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-dss-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dnssec-dss-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970910154745.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-dss-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-dss-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970910154745.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dns-security Thu Sep 11 13:38:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA02266 for dns-security-outgoing; Thu, 11 Sep 1997 13:37:00 -0400 (EDT) Message-Id: <3.0.1.32.19970911134732.00b3bd7c@pop.hq.tis.com> X-Sender: ogud@pop.hq.tis.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 11 Sep 1997 13:47:32 -0400 To: namedroppers@internic.com, dns-security@tis.com From: Olafur Gudmundsson (by way of Olafur Gudmundsson ) Subject: Bind and DNSSEC inter operation problem #1 with patch Cc: bind-workers@vix.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-dns-security@ex.tis.com Precedence: bulk It has come to my attention that there are some zones using DNSSEC records without running DNSSEC enabled servers. This is causing some applications problems. (Thanks to Randy Bush for forwarding me the relevant information). Problem description: Application requests records of type X from DNS, Server replies with SIG(X), X Application complains as first answer record is not of type X. DNSSEC aware servers know to put SIG(X) as the last record in the RR set. Cause: BIND and possibly other nameservers do round robin sorting in DNSSEC ignorant way. Fix: Attached are patches for bind-8.1.1 and bind-4.9.6 (applies to 4.9.[45]) Paul Vixie and others have looked at this patch and recommend its release. Please apply this to your nameservers. Description of patch: The new code round robins all types but SIG. SIG RR's are sorted to the end of the list and never promoted Possible problem: If originating server returns following set: SIG(X), X, X, X Recursive server will pass this on unchanged. But Caching server will return upon requests: first time: X, SIG(X), X, X second time: X, X, SIG(X), X from then on: X, X, X, SIG(X) Olafur 4.9.6 patch --------------cut here --------ns_resp.c.496.patch -------------- *** ns_resp.c.496 Tue Sep 9 16:16:37 1997 --- ns_resp.c Tue Sep 9 17:11:49 1997 *************** *** 2554,2578 **** delete_stale(np); #ifdef ROUND_ROBIN ! if (type != T_ANY && type != T_PTR) { ! /* cycle order of RRs, for a load balancing effect... */ ! register struct databuf **dpp; ! ! for (dpp = &np->n_data; dp = *dpp; dpp = &dp->d_next) { ! if (dp->d_next && wanted(dp, class, type)) { ! register struct databuf *lp; ! *dpp = lp = dp->d_next; ! dp->d_next = NULL; ! ! for (dpp = &lp->d_next; ! *dpp; ! dpp = &lp->d_next) ! lp = *dpp; ! *dpp = dp; ! break; ! } } } #endif /*ROUND_ROBIN*/ --- 2554,2586 ---- delete_stale(np); #ifdef ROUND_ROBIN ! /* ! * DNSSEC aware cycling of RRs, for a load balancing effect. ! * SIG records are all sorted to the end of the list to assure ! * they are always the last records in the rr set sent out ! * ogud@tis.com Jan 1997 ! */ ! if( type != T_ANY && type != T_PTR && type != T_SIG) { ! /* ! * dp is the current record ! * pdp predecessor to current dp ! * pldp predecessor to the last record of the wanted type ! */ ! register struct databuf *pdp=NULL, *pldp=NULL, *dp; ! /* search for the last record of the requested type */ ! for( dp=np->n_data; dp ; dp= dp->d_next) { ! /* signatures will sort to the end */ ! if( dp->d_type != T_SIG && wanted(dp, class, type)) ! pldp = pdp; /* pred to this RR record */ ! pdp = dp; ! } ! if( pldp ) { /* no need to reorder if first record */ ! dp = pldp->d_next; ! pldp->d_next = dp->d_next; /* remove ldp from queue */ ! dp->d_next = np->n_data; /* move first to second */ ! np->n_data = dp; /* insert at front */ } } #endif /*ROUND_ROBIN*/ ---------- 8.1.1 Patch -------cut here ------- ns_resp.c.811.diff ----------------- *** ns_resp.c.811 Tue Sep 9 16:16:17 1997 --- ns_resp.c Tue Sep 9 17:14:56 1997 *************** *** 2534,2559 **** delete_stale(np); #ifdef ROUND_ROBIN ! if (type != T_ANY && type != T_PTR) { ! /* cycle order of RRs, for a load balancing effect... */ ! struct databuf **dpp; ! ! for (dpp = &np->n_data; (dp = *dpp) != NULL; ! dpp = &dp->d_next) { ! if (dp->d_next && wanted(dp, class, type)) { ! struct databuf *lp; ! *dpp = lp = dp->d_next; ! dp->d_next = NULL; ! ! for (dpp = &lp->d_next; ! *dpp; ! dpp = &lp->d_next) ! lp = *dpp; ! *dpp = dp; ! break; ! } } } #endif /*ROUND_ROBIN*/ --- 2534,2566 ---- delete_stale(np); #ifdef ROUND_ROBIN ! /* ! * DNSSEC aware cycling of RRs, for a load balancing effect. ! * SIG records are all sorted to the end of the list to assure ! * they are always the last records in the rr set sent out ! * ogud@tis.com Jan 1997 ! */ ! if( type != T_ANY && type != T_PTR && type != T_SIG) { ! /* ! * dp is the current record ! * pdp predecessor to current dp ! * pldp predecessor to the last record of the wanted type ! */ ! register struct databuf *pdp=NULL, *pldp=NULL, *dp; ! /* search for the last record of the requested type */ ! for( dp=np->n_data; dp ; dp= dp->d_next) { ! /* signatures will sort to the end */ ! if( dp->d_type != T_SIG && wanted(dp, class, type)) ! pldp = pdp; /* pred to this RR record */ ! pdp = dp; ! } ! if( pldp ) { /* no need to reorder if first record */ ! dp = pldp->d_next; ! pldp->d_next = dp->d_next; /* remove ldp from queue */ ! dp->d_next = np->n_data; /* move first to second */ ! np->n_data = dp; /* insert at front */ } } #endif /*ROUND_ROBIN*/ From owner-dns-security Thu Sep 11 15:40:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA00909 for dns-security-outgoing; Thu, 11 Sep 1997 15:38:33 -0400 (EDT) Date: Thu, 11 Sep 1997 15:42:18 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: dns-security@tis.com Cc: "Donald E. Eastlake" Subject: Complexities with wildcards... Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk In the process of implementation, some additional complexities have been noted in connection with answers that are based on wildcard RRs or the absence of wildcard RRs: Assume zone.example is a zone with a wild card *.zone.example MX 100 mailhandler.zone.example *.zone.example NXT 1.zone.example MX SIG NXT 1.zone.example MX 100 foo.zone.example 1.zone.example NXT 3.zone.example MX SIG NXT ... 1.zone.example ... 3.zone.example MX 100 bar.zone.exzmple 3.zone.example NXT ... plus the SIGs to authenticate the above. (1) In answer to a query for type MX, name 2.zone.example, you would get the expansion of the wildcard MX and the expansion of its SIG. A secure resolver can verifty all this which involves converting back to the wildcard form for SIG verification. But how does the resolver know that there isn't actaully a non-wildcard 2.zone.example MX which MXes to a different place? In fact, a bad guy could have captured a wildcard expansion response and use it to deny service to more specific names which should override the wildcard. The answer is that, with any wildcard expansion response, you need to also provide an NXT proving that the specific name did not exist. Thus in this case, the "1.zone.example NXT 3.zone.example ..." and its authentication SIG(NXT) would have to appear in the authority section of the response to justify returning the wildcard expansion answer. (2) In answer to a query for type A, name 2.zone.example, you would get a failure with the *.zone.example NXT RR in the authority section to prove that type A is not present but, as above, this does not show that the *.zone.example NXT is the right one as there might be a 2.zone.example NXT with a different type bit map. The answer, as above, is that you need to return two NXTs, with their authenticating SIGs, in the authority section. One to prove that 2.zone.example is a non-existent name so the *.zone.example is applicable and the *.zone.example NXT to show that that name has no type A. --- --- Now assume that zone.example no longer has the wild card: (3) When a non-existent name is returned for 2.zone.example with the "1.zone.example NXT 3.zone.example ..." NXT RR, how does the resolver know that an wildcard expansion should not have been returned instead? It appears that it is necessary to also return a second NXT proving that there isn't a wildcard which should have been used to answer the query, although the potential for denial of service by a bad guy saving the "1.zone... NXT 3.zone..." RR to deny access to an existing wildcard is a narrower threat that the bad guy saving a wildcard NXT and using it to deny access to a vast range of existing names. (4) Non-existent type at an exisitng non-wildcard name isn't a problem. You can just return the one NXT for the existing non-wildcard name. (5) To be complete: an existing type at an existing name isn't a problem as no wildcard would effect the response and, of course, no NXTs are needed (unless the query was for NXT). --- --- Things become even more complex if you think about multiple level zones. For example, if you were querying for x.2.zone.example and a.2.zone.example and z.2.zone.example existed, you would need to prove that x.2.zone.example and *.2.zone.example did not exist to justify a response based on *.zone.example. Possible algorithms are given below. If anyone can think of a way to maintain security and avoid these complexities, I'd love to hear about it. One good thing to note is that a security aware resolver must reduce a wild card expansion RR back to its wild card form for signature verification. Thus it could optionally cache the wildcard form and reduce queries to the authoritative servers BUT it can locally expand the wildcard ONLY in cases where it also has cached NXT RRs that prove a more specific name does not exist. Donald ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-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.eff.org/blueribbon.html WARNING, on 1 Oct 1997, +1-508 may change to +1-978. First stab at query algorithms: WILD CARD EXPANSION RESPONSE: 1. always include the NXT the proves the specific name queried does not exist. 2. replace the left most label of the name queried with *. 3. if the current name matches the wild card you expanded, you are done. 4. othewise check to see if the NXTs you are returning so far prove the current name does not exist. If they don't, add the NXT which does prove the current name does not exist. 5. remove the next to the left most label, leaving the current name a shorter wildcar, and go to 3. WILD CARD NON-EXISTENT TYPE: as for wild card expansion response above except you also return the wild card NXT to prove the type does not exist. NON-EXISTENT NAME RESPOPNSE 1. always include the NXT showing the specific name does not exist. 2. replace the left most label of the name queried with *. 3. check to see if the NXTs you are returning so far prove the current name does not exist. If they don't, add the NXT which does prove the current name does not exist. 4. remove the next to the left most label, leaving the current name one label shorter. If the current name (which will be a wildcard) matches the zone name, you are through, otherwise, go to step 3. On VALDIATING a response, you need to check that the NXTs that would be included above are present. From owner-dns-security Fri Sep 12 16:50:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA10151 for dns-security-outgoing; Fri, 12 Sep 1997 16:47:42 -0400 (EDT) X-Sender: lewis@pop.hq.tis.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 12 Sep 1997 16:57:43 -0400 To: dns-security@tis.com From: Edward Lewis Subject: Determining a set's zone Cc: lewis@tis.com Sender: owner-dns-security@ex.tis.com Precedence: bulk This message is principly about determining the zone of a set. Before addressing that, I've included a short introduction explaining the need for this within DNSSEC. INTRODUCTION ============ Resolving DNS signatures is not simply a process of taking the data in the RRSet, the received signature(s), and the/each signature's key and seeing if the combination agrees. Ironically, a signature verifying a set of data can be misleading, the signature may have been generated by an entity that cannot or should not speak for the data. --- For example, Acme Widgets (acme-wdgts.com) and General Widgets (gen-wdgts.com) are compeitiors. Would you trust this data? www.acme-wdgts.com A 10.107.198.32 www.acme-wdgts.com SIG A 1 7200 1997... 1997... 54321 gen-wdgts.com. ... The answer should be "no," even if the signature is valid with the indicated key. (Why?) General Widgets could have substituted an IP address leading to a dis-information web server to sully Acme Widget's good name. Consider one more twist. What if Acme Widgets is not running a secured DNS zone? Yes, their loss. This is discoverable (providing com. is secured), and knowing that I should not be receiving the signature is much more important that knowing if the signature validates. *Joke on* The fact that I receive an unexpected signature is an event worthy of inclusion in the Security Information Base (SIB), used by the Simple Security Management Protocol (SSMP) - but I digress. *Joke off* --- This situation highlights one reason why the DNS secure resolver code is a lot more complicated than just the simple crypto-operation of signature validation. THE ISSUE ========= "How do I determine the zone of an RRSet?" I want to answer this question in order to asnwer such questions as: are there keys available for the zone? is the NXT received an appropriate answer? is the signer a domain I believe to be a/the rightful signer? First, the zone for an RRSet is determined by more than just the its name (& class) - if the name is a delegation point. If the type of an RRSet is KEY, then I really want to know the parent zone of the name. If the type is NXT I need to know either the signer or the next name to determine the zone. (Again, this applies to delegation point names, where there may be two NXT RRSets.) Having decided the zone I want to inspect, I might try "running up" the domain tree until I find either an NS or SOA record (set). But this can be misleading, especially if someone is falsely claiming to be a delegated zone. Therefore, I need to "run down" from the root (or, in the case of disjoint DNSSEC subtrees, from the closest DNSSEC-running subroot), towards the name I am examining. But what should I search for? NS records from the parent zone are unsigned, and it's conceivable that an NS record may be "slipped in" somewhere along the line to promote an illegal delegation. SOA records are more sound - but they are signed by the owner, whom I may not trust. (Keep in mind signing authorities, but let's not discuss them here.) What I really want is to ask for a record of the parent zone, signed by the parent zone, that says there is a delegation. There is a record for that. Ironically, it is the one record that supposed to show what doesn't exist. It is the NXT - at a delegation, the "upper" NXT is what is needed to justify the existence of the delegation. My question to the list: Is there a better way to do this / Does this seem necessary? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: +1 301-854-5794 Email: lewis@tis.com "What's it say about me that you'd think I'd fall for that" James McMurtry - "Where'd You Hide the Body" (1995) Opinions expressed are property of my evil twin, not my employer. From owner-dns-security Mon Sep 15 16:48:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA29381 for dns-security-outgoing; Mon, 15 Sep 1997 16:45:20 -0400 (EDT) Date: Mon, 15 Sep 1997 16:48:58 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: dns-security@tis.com Subject: Re: draft chagnes 1 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 On Tue, 9 Sep 1997, Donald E. Eastlake 3rd wrote: > Date: Tue, 9 Sep 1997 16:51:03 -0400 (EDT) > From: Donald E. Eastlake 3rd > > Hi, > > I plan to make the following changes in the current (...secext2-01...) > draft unless there is substantial objection: > > Appendix C: To make the code look a bit more like normal C code and to > strenthen the checksum a little, it will be changed to return an int > (with an appropriate commend about storing the int's octets in network > order) and the last occurance of 0xFF will be changed to 0xFFFF. To be more precise, the code now says: /* assumes int is at least 16 bits first byte of tag is most significant byte of return value second byte of tag is least significatn byte of return value */ int keytag ( unsigned char key[], /* the RDATA part of the KEY RR */ unsigned int keysize, /* the RDLENGTH */ ) { long int ac; /* assumed to be 32 bits or larger */ for ( ac = 0, i = 0; i < keysize; ++i ) ac += (i&1) ? key[i] : key[i]<<8; ac += (ac>>16) & 0xFFFF; return ac & 0xFFFF; } > Protocol Octet: A value will be assigned for the dnssec protocol and it > will specify that the octet should have that value on zone keys. To be more precise, the value is 3. > KEY RR: The KEY RR for a zone should be automatically returned on > queries of the SOA for that zone, as well as NS queries. The odd > pharasiology used in the section on returning spontaneous KEY RRs on > queries where it says "... must be returned if there is space ..." will > be changes to say "... SHOULD be returned ...". To be more precise, the text now says: Security aware DNS servers include KEY RRs as additional information in responses, where a KEY is available, in the following cases: (1) On the retrieval of SOA or NS RRs, the zone key KEY RR(s) with the same name SHOULD be included as additional information if space is available. There will always be at least one such KEY RR in a secure zone in connection with a subzone delegation point, even if it has the no-key type value to indicate that the subzone is unsecured. If not all additional information will fit, the type A or AAAA glue RRs have higher priority than KEY RR(s). (2) On retrieval of type A or AAAA RRs, the host KEY RR(s) (NOT the zone key) SHOULD be included if space is available. On inclusion of A or AAAA RRs as additional information, host KEY RRs with the same name will also be included but with lower priority than the A or AAAA RRs. > Donald > ===================================================================== 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 Sep 16 12:18:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA06190 for dns-security-outgoing; Tue, 16 Sep 1997 12:15:55 -0400 (EDT) Date: Tue, 16 Sep 1997 12:19:46 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: Edward Lewis Cc: dns-security@tis.com, "Donald E. Eastlake" Subject: Re: Determining an RRset's zone 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 On Fri, 12 Sep 1997, Edward Lewis wrote: > Date: Fri, 12 Sep 1997 16:57:43 -0400 > From: Edward Lewis > > This message is principly about determining the zone of a set. Before > addressing that, I've included a short introduction explaining the need for > this within DNSSEC. > > INTRODUCTION > ============ > > Resolving DNS signatures is not simply a process of taking the data in the > RRSet, the received signature(s), and the/each signature's key and seeing > if the combination agrees. Ironically, a signature verifying a set of data > can be misleading, the signature may have been generated by an entity that > cannot or should not speak for the data. > > --- > > For example, Acme Widgets (acme-wdgts.com) and General Widgets > (gen-wdgts.com) are compeitiors. Would you trust this data? > > www.acme-wdgts.com A 10.107.198.32 > www.acme-wdgts.com SIG A 1 7200 1997... 1997... 54321 gen-wdgts.com. ... > > The answer should be "no," even if the signature is valid with the > indicated key. (Why?) General Widgets could have substituted an IP address > leading to a dis-information web server to sully Acme Widget's good name. The latest draft has some rules in 6.3.1 that provide some guidance. I believe that applying them to this case would say you should only trust this if you have the public key for gen-wdgts.com staticly configured as a trusted key. > Consider one more twist. What if Acme Widgets is not running a secured DNS > zone? Yes, their loss. This is discoverable (providing com. is secured), > and knowing that I should not be receiving the signature is much more > important that knowing if the signature validates. > > ... > > --- > > This situation highlights one reason why the DNS secure resolver code is a > lot more complicated than just the simple crypto-operation of signature > validation. > > THE ISSUE > ========= > > "How do I determine the zone of an RRSet?" > > I want to answer this question in order to asnwer such questions as: > are there keys available for the zone? > is the NXT received an appropriate answer? > is the signer a domain I believe to be a/the rightful signer? Knowing what zone an RRset is in is very useful for the first two questions above but I do not belive it needs to be taken into account for the third question and indeed the draft sectino 6.3.1 rules do not care about zone boundaries. Tighter rules could be written which do take into account zone boundaries but I am not convinced the additional complexity is worth it. > First, the zone for an RRSet is determined by more than just the its name > (& class) - if the name is a delegation point. If the type of an RRSet is > KEY, then I really want to know the parent zone of the name. If the type > is NXT I need to know either the signer or the next name to determine the > zone. (Again, this applies to delegation point names, where there may be > two NXT RRSets.) > > Having decided the zone I want to inspect, I might try "running up" the > domain tree until I find either an NS or SOA record (set). But this can be > misleading, especially if someone is falsely claiming to be a delegated > zone. Well, if you can verify the SIG on the NS or SOA I think you are OK. > Therefore, I need to "run down" from the root (or, in the case of disjoint > DNSSEC subtrees, from the closest DNSSEC-running subroot), towards the name > I am examining. When DNSSEC was being designed, it was thought that it would be very hard to get root and high level zones secured. Now the situation is just the opposite. It appears that root and some of the high level zones may be among the first secured, which is certainly good. Under such conditions, I'm not sure how much it is worth worrying about DNSSEC islands in an insecure sea... > But what should I search for? NS records from the parent zone are > unsigned, and it's conceivable that an NS record may be "slipped in" > somewhere along the line to promote an illegal delegation. SOA records are > more sound - but they are signed by the owner, whom I may not trust. (Keep > in mind signing authorities, but let's not discuss them here.) What I > really want is to ask for a record of the parent zone, signed by the parent > zone, that says there is a delegation. How about the child's zone KEY signed by the parent? Doesn't matter if it was physically in the parent or child zone, it proves a delegation. > There is a record for that. Ironically, it is the one record that supposed > to show what doesn't exist. It is the NXT - at a delegation, the "upper" > NXT is what is needed to justify the existence of the delegation. Because of having NS on in the type bit map? > My question to the list: Is there a better way to do this / Does this seem > necessary? Well, a resolvers certainly needs to understand zones to be able to retrieve the RRs it needs to answer a query. Ditto a secure resolver securely answering a query. But I don't think it is necessary to make the rules in 6.3.1 more complex to take zone boundaries into account. > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis Trusted Information Systems > Phone: +1 301-854-5794 Email: lewis@tis.com > > "What's it say about me that you'd think I'd fall for that" > James McMurtry - "Where'd You Hide the Body" (1995) > > Opinions expressed are property of my evil twin, not my employer. 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 Wed Sep 17 08:42:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA13709 for dns-security-outgoing; Wed, 17 Sep 1997 08:40:34 -0400 (EDT) X-Sender: lewis@pop.hq.tis.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 17 Sep 1997 08:13:37 -0400 To: Edward Lewis From: Edward Lewis Subject: Re: Determining a set's zone Cc: dns-security@tis.com, lewis@tis.com Sender: owner-dns-security@ex.tis.com Precedence: bulk At 4:57 PM -0400 9/12/97, Edward Lewis wrote: >There is a record for that. Ironically, it is the one record that supposed >to show what doesn't exist. It is the NXT - at a delegation, the "upper" >NXT is what is needed to justify the existence of the delegation. > >My question to the list: Is there a better way to do this / Does this seem >necessary? After working on this for a day plus, I realized this doesn't work either, well, not for the way I've written the code so far. The problem is that the algorithm has a segment like this: send query receive answer all sorts of error checks determine if there should be a signature determine the zone if the zone is unknown, learn about it do this by asking for the nxt ----------step #7 do the crypto work What is labeled step #7 is a recursive call to the secure resolver. Recursion works only when the problem gets reduced in each step until some degenerate problem is trivially handled. In this case, the zone of a particular set is discovered by learning all the zones from a preconfigured zone down to it, domain-by-domain (as opposed to zone-by-zone). For a given name, I'd establish it's parent after establishing the parent's grandparent and so on, until the antecedant is a preconfigured zone. On paper, the recursive step should work. But try telling that to the computer. The problem is that when I request the NXT for a delegation point and the server knows of both the "upper" and "lower" NXT, I get both the upper and the lower NXT's. Keep in mind that (at least as far as I am concerned) there are two record sets at a delegation point that "belong" to the upper zone - the upper NXT and the KEY set. The rest are in the lower zone. The upper NXT does not cause a problem. In the recursive call, it is the (part of the) answer - so it is run through the algorithm. Prior to returning from this level of the calls, I will have (err, should have) learned about the parent of the zone I am seeking. However, the answer is two part - the second is the lower NXT. The zone of the lower NXT is the same zone I am already trying to learn about when I initiaited this level of recursion. What this translates into is an infinite recursion loop. I never return from this level of the recursion - so the upper NXT's lesson is lost. This loop does not occur if the name server I am contacting has the upper NXT and not the lower NXT (although I have not tested that case in my code). I suppose the fall back is to ask instead for the KEY records. This will avoid the infinite recursion loop. However, the KEY record fails to tell me what I want to know. It *might* imply the existence of an NS record at the same name - this is true if only the only names allowed to have zone keys are delegtion points. (I have seen examples bandied about in other e-mails which run contrary to this.) One very involved solution is to look for the KEY records to establish a "possible" zone and then look for the NS records to seal it, but this introduces yet another state machine in the code - and all the necessary extra code to handle possible delays in getting the answers (to the NS query). I am coding single threaded now, I can imagine the multi-threaded solution getting pretty advanced. Another solution is to avoid the recursion, but this would grow the code base by 75% to 90%. The error handling situations is what drives all this. Yet another is for me to rethink the kinds of error checking I should be doing, and perhaps this (what zone?) is the wrong question to be asking in the situation I am facing. I suppose for now, I'll plug away with the request for KEYs and infer the existence of zones - but in a "security" system, infering facts is not good. (I've seen way to many bad guy movies.) I would like to leave this thought for the future. What is lacking here is an authenticated verification of the existence of a delegation by the zone doing the delegating. What is needed in the future is a record that is held in the delegating a zone that there is a delegation at a specified point. In the current DNS, the NS set inferred the existence of the delegation - and inference is alright if I am not concerned with matters of trust. Having the delegatee sign these records leads me not to trust them - as delegations is an activity granted downward, not upward. Sure, it may be that a bad entity may have a key signed by the zone which it uses to sign NS records - even if the flags don't allow it. In the crypto- verification portion I should detect this. However, the amount of data the secure resolver has to maintain to do this (in terms of context variables, state variable, other flags) is considerable. (I never realized how context-sensitive the DNS response packet is.) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: +1 301-854-5794 Email: lewis@tis.com "What's it say about me that you'd think I'd fall for that" James McMurtry - "Where'd You Hide the Body" (1995) Opinions expressed are property of my evil twin, not my employer. From owner-dns-security Thu Sep 18 01:56:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA19769 for dns-security-outgoing; Thu, 18 Sep 1997 01:55:17 -0400 (EDT) Message-Id: <199709180604.XAA00261@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Edward Lewis cc: dns-security@tis.com, gnu@toad.com Subject: Re: Determining a set's zone In-reply-to: Date: Wed, 17 Sep 1997 23:04:36 -0700 From: John Gilmore Sender: owner-dns-security@ex.tis.com Precedence: bulk > I suppose the fall back is to ask instead for the KEY records. This will > avoid the infinite recursion loop. However, the KEY record fails to tell > me what I want to know. It *might* imply the existence of an NS record at > the same name - this is true if only the only names allowed to have zone > keys are delegtion points. (I have seen examples bandied about in other > e-mails which run contrary to this.) You're close. I have been looking at this for a year, off and on, and I think the simplest solution is to put copies of the zone keys at every domain level in the zone. E.g. if a zone has names a, b.c, and d, there'd be (potentially identical) keys at the zone's root and at b. The whole signed file would look like: @ KEY ... @ SIG KEY ... @ ... a TXT ... a SIG TXT ... @ ... b KEY ... b SIG KEY ... @ ... b.c TXT ... b.c SIG TXT ... b ... <-- note this signature is by "b", not "@" c TXT ... c SIG TXT ... @ ... I think it's even possible for the signer application (which turns an unsigned zone into a signed zone) to do this, propagating keys to each level within the zone. The key it used to sign each RRset would have exactly one fewer domain label than the RRset has. (At the moment the signer signs with the "zone key" which might have N domain labels fewer than the RRset; N = 0 or greater.) Then you never need to care where the zone boundaries are, because you just peel off a domain label and look for a KEY. Much, much, much simpler for the resolver, which means much, much, much more secure for the resolver. All it costs is a small complication in the signer. John From owner-dns-security Thu Sep 18 14:32:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA24685 for dns-security-outgoing; Thu, 18 Sep 1997 14:28:59 -0400 (EDT) Date: Thu, 18 Sep 1997 14:39:20 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: dns-security@tis.com Subject: Re: Determining a set's zone 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 Zone keys only occur at delegation points. If you are in a secure zone, you can tell there is a delegation by finding a vefiyable zone KEY with a name inside the zone. NS RRs are only signed in the child so NS RR's should only appear signed by a zone key of the same owner name as the NS RR. It has been suggested that things would be further simiplified if zone keys could only be signed by zone keys. This means that you could not have a dynamic update wildcard key, for example, that could sign a zone key and authorize the addition of NS's to create a delegation in mode A. It would still be possible for such a key to authorize creation of a delegation in mode B where the zone signs everything in the zone as served anyway. I plan to make this change so people should comment if they have different ideas. The draft originated at a time when it was unclear how quickly root and high level zones would get secured and it was thought there might be many secure islands of DNS data in an insecure ocean. It now appears that high level zones may be seucred early so secure islands should be much less common. There is language in the draft suggesting that you should attempt to locally apply dnssec in a secure island even when you have no way of actually verifying any of it to a trusted key. This adds complexity with little gain in the environment we are likely to see. While not prohibiting such local security consistency checking, I propose to change the language of the draft to reflect the idea that it is primarily worth while to apply dnssec within any disjoint island of DNS data only if you have a staticly configured key somewhere in that island. Donald On Wed, 17 Sep 1997, Edward Lewis wrote: > Date: Wed, 17 Sep 1997 08:13:37 -0400 > From: Edward Lewis > To: Edward Lewis > Cc: dns-security@tis.com, lewis@tis.com > Subject: Re: Determining a set's zone > > At 4:57 PM -0400 9/12/97, Edward Lewis wrote: > >There is a record for that. Ironically, it is the one record that supposed > >to show what doesn't exist. It is the NXT - at a delegation, the "upper" > >NXT is what is needed to justify the existence of the delegation. > > > >My question to the list: Is there a better way to do this / Does this seem > >necessary? > > After working on this for a day plus, I realized this doesn't work either, > well, not for the way I've written the code so far. The problem is that > the algorithm has a segment like this: > > send query > receive answer > all sorts of error checks > determine if there should be a signature > determine the zone > if the zone is unknown, learn about it > do this by asking for the nxt ----------step #7 > do the crypto work > > What is labeled step #7 is a recursive call to the secure resolver. > Recursion works only when the problem gets reduced in each step until some > degenerate problem is trivially handled. > > In this case, the zone of a particular set is discovered by learning all > the zones from a preconfigured zone down to it, domain-by-domain (as > opposed to zone-by-zone). For a given name, I'd establish it's parent > after establishing the parent's grandparent and so on, until the antecedant > is a preconfigured zone. On paper, the recursive step should work. > > But try telling that to the computer. > > The problem is that when I request the NXT for a delegation point and the > server knows of both the "upper" and "lower" NXT, I get both the upper and > the lower NXT's. Keep in mind that (at least as far as I am concerned) > there are two record sets at a delegation point that "belong" to the upper > zone - the upper NXT and the KEY set. The rest are in the lower zone. > > The upper NXT does not cause a problem. In the recursive call, it is the > (part of the) answer - so it is run through the algorithm. Prior to > returning from this level of the calls, I will have (err, should have) > learned about the parent of the zone I am seeking. > > However, the answer is two part - the second is the lower NXT. The zone of > the lower NXT is the same zone I am already trying to learn about when I > initiaited this level of recursion. What this translates into is an > infinite recursion loop. I never return from this level of the recursion - > so the upper NXT's lesson is lost. > > This loop does not occur if the name server I am contacting has the upper > NXT and not the lower NXT (although I have not tested that case in my code). > > I suppose the fall back is to ask instead for the KEY records. This will > avoid the infinite recursion loop. However, the KEY record fails to tell > me what I want to know. It *might* imply the existence of an NS record at > the same name - this is true if only the only names allowed to have zone > keys are delegtion points. (I have seen examples bandied about in other > e-mails which run contrary to this.) > > One very involved solution is to look for the KEY records to establish a > "possible" zone and then look for the NS records to seal it, but this > introduces yet another state machine in the code - and all the necessary > extra code to handle possible delays in getting the answers (to the NS > query). I am coding single threaded now, I can imagine the multi-threaded > solution getting pretty advanced. > > Another solution is to avoid the recursion, but this would grow the code > base by 75% to 90%. The error handling situations is what drives all this. > > Yet another is for me to rethink the kinds of error checking I should be > doing, and perhaps this (what zone?) is the wrong question to be asking in > the situation I am facing. > > I suppose for now, I'll plug away with the request for KEYs and infer the > existence of zones - but in a "security" system, infering facts is not > good. (I've seen way to many bad guy movies.) > > I would like to leave this thought for the future. What is lacking here is > an authenticated verification of the existence of a delegation by the zone > doing the delegating. What is needed in the future is a record that is > held in the delegating a zone that there is a delegation at a specified > point. > > In the current DNS, the NS set inferred the existence of the delegation - > and inference is alright if I am not concerned with matters of trust. > Having the delegatee sign these records leads me not to trust them - as > delegations is an activity granted downward, not upward. > > Sure, it may be that a bad entity may have a key signed by the zone which > it uses to sign NS records - even if the flags don't allow it. In the > crypto- verification portion I should detect this. However, the amount of > data the secure resolver has to maintain to do this (in terms of context > variables, state variable, other flags) is considerable. (I never realized > how context-sensitive the DNS response packet is.) > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis Trusted Information Systems > Phone: +1 301-854-5794 Email: lewis@tis.com > > "What's it say about me that you'd think I'd fall for that" > James McMurtry - "Where'd You Hide the Body" (1995) > > Opinions expressed are property of my evil twin, not my employer. > > > ===================================================================== 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 Fri Sep 19 10:56:00 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA01183 for dns-security-outgoing; Fri, 19 Sep 1997 10:54:47 -0400 (EDT) X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 19 Sep 1997 07:54:35 -0700 To: dns-security@tis.com From: Fred Baker Subject: Costs of Mandatory Key Recovery Sender: owner-dns-security@ex.tis.com Precedence: bulk If you could email any hard numbers as to expected costs to Don Heath , it would be helpful. >>Date: Wed, 17 Sep 1997 10:55:55 -0400 >>From: Philip Webre >>To: heath@isoc.org >>Subject: Costs of Mandatory Key Recovery >>Content-Disposition: inline >> >>As I explained over the telephone, we are trying to estimate >>the private sector costs associated with mandatory key >>recovery in the US. Thursday the House Intelligence >>Committees passed an amended version of HR 695 that >>would mandate immediate key recovery in all encryption >>products sold, imported or distributed in the US after >>January 31, 2000. It further imposes this requirement >>on Internet service providers who provide encryption >>services when presented by a warrant from a duly authorized >>law enforcement official. >> >>We expect that within an organization like a corporate >>LAN, key recovery can be mandated in a straight forward >>manner. But since the relationship between an ISP >>and its client is more distant, very different mechanisms >>and cost structure would surface. I would be very >>interested in any information you could provide regarding >>the costs associated with such a mandate. >> >>Address: >>Philip Webre >>Congressional Budget Office >>Natural Resources and Commerce Division >>495 Ford House Office Bldg. >>Washington, D.C. 20515 >>Fax Number: 202-226-0207 >>Voice: 202-226-2940 >>Internet: Philipw@CBO.GOV > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Planning is bringing the future into the present so that you can do something about it now." Alan Lakein From owner-dns-security Tue Sep 23 10:00:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA00189 for dns-security-outgoing; Tue, 23 Sep 1997 09:56:35 -0400 (EDT) Date: Tue, 23 Sep 1997 10:06:24 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: John Gilmore Cc: dns-security@tis.com, "Donald E. Eastlake" Subject: Re: Determining a set's zone In-Reply-To: <199709180604.XAA00261@toad.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk John, On Wed, 17 Sep 1997, John Gilmore wrote: > Date: Wed, 17 Sep 1997 23:04:36 -0700 > From: John Gilmore > Cc: dns-security@tis.com, gnu@toad.com > > > I suppose the fall back is to ask instead for the KEY records. This will > > avoid the infinite recursion loop. However, the KEY record fails to tell > > me what I want to know. It *might* imply the existence of an NS record at > > the same name - this is true if only the only names allowed to have zone > > keys are delegtion points. (I have seen examples bandied about in other > > e-mails which run contrary to this.) I don't see any problem with a zone KEY always implying a delegation point. > You're close. I have been looking at this for a year, off and on, and > I think the simplest solution is to put copies of the zone keys at > every domain level in the zone. E.g. if a zone has names a, b.c, and > d, there'd be (potentially identical) keys at the zone's root and at > b. The whole signed file would look like: I believe that I understand what you are proposing below but I don't think it help's much in unambiguously determining what criteria to apply for detecting delegation points, which was the specific thing Ed wanted to do. > @ KEY ... > @ SIG KEY ... @ ... > > a TXT ... > a SIG TXT ... @ ... > > b KEY ... > b SIG KEY ... @ ... > > b.c TXT ... > b.c SIG TXT ... b ... <-- note this signature is by "b", not "@" > > c TXT ... > c SIG TXT ... @ ... > > I think it's even possible for the signer application (which turns an > unsigned zone into a signed zone) to do this, propagating keys to each > level within the zone. The key it used to sign each RRset would have > exactly one fewer domain label than the RRset has. (At the moment > the signer signs with the "zone key" which might have N domain labels > fewer than the RRset; N = 0 or greater.) Well, so what? The SIG that signs something has the signer name in it so you can tell what it is... > Then you never need to care where the zone boundaries are, because you > just peel off a domain label and look for a KEY. Much, much, much > simpler for the resolver, which means much, much, much more secure for > the resolver. All it costs is a small complication in the signer. If that would solve all the worlds problems, then we could just eliminate the Signer field from the SIG RR. But there are cases where you need to have RRs signed by *longer* names, there are cross certification cases, etc. I'm just not sure what would be gained by plumping up zones with these extra KEY RRs, which would also have to be dynamically added for some dynamic updates, etc... > John 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 Sep 23 10:24:41 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA00492 for dns-security-outgoing; Tue, 23 Sep 1997 10:24:33 -0400 (EDT) X-Sender: lewis@pop.hq.tis.com Message-Id: In-Reply-To: References: <199709180604.XAA00261@toad.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 23 Sep 1997 10:34:36 -0400 To: "Donald E. Eastlake 3rd" From: Edward Lewis Subject: Re: Determining a set's zone Cc: John Gilmore , dns-security@tis.com, "Donald E. Eastlake" Sender: owner-dns-security@ex.tis.com Precedence: bulk At 10:06 AM -0400 9/23/97, Donald E. Eastlake 3rd wrote: >On Wed, 17 Sep 1997, John Gilmore wrote: (Donald said:) >I don't see any problem with a zone KEY always implying a delegation >point. I agree with the intent of this statement, but not how it is said. ;) In "doing security" I don't like implied/implicit statements nor inferences. This is why one of the upcoming documents I am currently floating for comments says this, but in a stronger way. A "zone key" explicilty decalres a delegation. If the NS records are missing, we are experiencing a misconfiguration. (John said:) >> You're close. I have been looking at this for a year, off and on, and >> I think the simplest solution is to put copies of the zone keys at Trying to not sound snide, but the solution shown complicates (as in makes more records) things. The problem is not in multi-label (multi-domain) zones. My code has never had a problem with that. (Back to Donald:) >If that would solve all the worlds problems, then we could just eliminate >the Signer field from the SIG RR. But there are cases where you need to I've come to the conclusion that: When descending the tree to find data, I use unverified hints -- ie I don't verify anything on the way to the answer After an answer is proposed I use verified data in the verification -- ie the keys are verified after being found, and the other needed info/glue too. If I try to use verified data to descend the tree, I will inevitably run the risk of an infinite verification loop. What does this have to do with the above quip? It's a long story, relating to the aforementioned doc-in-production. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: +1 301-854-5794 Email: lewis@tis.com "What's it say about me that you'd think I'd fall for that" James McMurtry - "Where'd You Hide the Body" (1995) Opinions expressed are property of my evil twin, not my employer.