From owner-dns-security Tue Nov 4 13:43:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA14360 for dns-security-outgoing; Tue, 4 Nov 1997 13:37:22 -0500 (EST) X-Sender: lewis@pop.hq.tis.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 4 Nov 1997 13:43:12 -0500 To: dee@cybercash.com, ogud@tis.com, gnu@toad.com, charlie_kaufman@iris.com, dns-security@tis.com From: Edward Lewis Subject: $SIGNER directive Cc: lewis@tis.com Sender: owner-dns-security@ex.tis.com Precedence: bulk I'm beginning work on another DNSSEC signer application - trying to correct flaws in the first, among other reasons - and have hit a problem with the $SIGNER directive. Now that I've become aware of the allowance of multiple signatures (the major flaw in the first signer is that it assumes up front there would only be one), the existing definition of: $SIGNER ; means turn signing off $SIGNER name footprint ; means sign with the specified key is insufficient. I'm not sure what to do, so I thought I'd suggest some alternatives to the list. Option 1: Make the $SIGNER an additive directive. $SIGNER ADD name footprint ; adds a key to the list of those to apply $SIGNER DEL name footprint ; stops the use of the key Option 2: Make the $SIGNER list all keys to use. $SIGNER name1 foot1 name2 foot2 ; set the list of keys to apply to this Option 3: Use a combination: $SIGNER name1 foot1 name2 foot2 ; set the list of keys to apply to this $SIGNER ADD name3 foot3 ; adds this key $SIGNER DEL name2 foot2 ; removes this key $SIGNER name1 foot1 name2 foot2 ; resets the list Other things I'd like to reconsider: 1) Make the $SIGNER directive specific to a file - i.e., it is preserved after a $INCLUDE. This does not ease implementation, but my experience with making test data leads me to prefer not having to reset the key in use after including another file. 2) Allow for: $SIGNER name to specify the use of any key owned by that name. The key would be selected through a series of preferences - first a zone key, then a signing key, then a DNS published key, finally a non-published key (in which case name is not a domain name). Note: this complicates the synatxi above. But this helps in places where keys change over (and would be a help with some test data situations). 3) Have the signer work in two modes regarding the selection of signers - one in which the directives are obeyed and another in which only the keys given as input (via the run-time interface) are used. Presumably, the zone signing would be the one to follow the $SIGNERs and extra signers would run the latter. (Zone signers could specify a run time key(s) - this would be the same as a $SIGNER at the top of the file.) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: +1 301-854-5794 Email: lewis@tis.com "Serenity now, insanity later" -- Lloyd Braun Opinions expressed are property of my evil twin, not my employer. From owner-dns-security Tue Nov 4 14:24:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA14690 for dns-security-outgoing; Tue, 4 Nov 1997 14:23:56 -0500 (EST) From: bmanning@isi.edu Posted-Date: Tue, 4 Nov 1997 11:33:37 -0800 (PST) Message-Id: <199711041933.AA20473@zed.isi.edu> Subject: Re: $SIGNER directive To: lewis@tis.com (Edward Lewis) Date: Tue, 4 Nov 1997 11:33:37 -0800 (PST) Cc: dee@cybercash.com, ogud@tis.com, gnu@toad.com, charlie_kaufman@iris.com, dns-security@tis.com, lewis@tis.com In-Reply-To: from "Edward Lewis" at Nov 4, 97 01:43:12 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-dns-security@ex.tis.com Precedence: bulk > Option 3: I like this option. > Other things I'd like to reconsider: > > 1) Make the $SIGNER directive specific to a file - i.e., it is preserved > after a $INCLUDE. This does not ease implementation, but my experience > with making test data leads me to prefer not having to reset the key in use > after including another file. Deals w/ multiple $INCLUDES? -- --bill From owner-dns-security Wed Nov 5 08:25:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA20405 for dns-security-outgoing; Wed, 5 Nov 1997 08:22:05 -0500 (EST) X-Sender: lewis@pop.hq.tis.com Message-Id: In-Reply-To: <199711041933.AA20473@zed.isi.edu> References: from "Edward Lewis" at Nov 4, 97 01:43:12 pm Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 5 Nov 1997 08:22:04 -0500 To: bmanning@isi.edu From: Edward Lewis Subject: Re: $SIGNER directive Cc: lewis@tis.com (Edward Lewis), dee@cybercash.com, ogud@tis.com, gnu@toad.com, charlie_kaufman@iris.com, dns-security@tis.com Sender: owner-dns-security@ex.tis.com Precedence: bulk At 2:33 PM -0500 11/4/97, bmanning@isi.edu wrote: >> Option 3: > > I like this option. After thinking more, I'd have to add another keyword, so the set of lines is {"SIGNER ADD" "SIGNER DEL" and "SIGNER SET"}. This way I can tell the difference between add.zone and ADD. > >> Other things I'd like to reconsider: >> >> 1) Make the $SIGNER directive specific to a file - i.e., it is preserved >> after a $INCLUDE. This does not ease implementation, but my experience > Deals w/ multiple $INCLUDES? I don't quite follow what do you mean by multiple $INCLUDEs? Multiple nesting? I would guess that as an INCLUDE is followed, the origin is either inheritied or changed to what is specified, and the signer is just inherited (I don't want to change the $INCLUDE to add signers). On return from the $INCLUDE, the state of the file is restored - ir-regardless of how many levels of $INCLUDEs are nested. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: +1 301-854-5794 Email: lewis@tis.com "Serenity now, insanity later" -- Lloyd Braun Opinions expressed are property of my evil twin, not my employer. From owner-dns-security Wed Nov 5 08:31:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA20438 for dns-security-outgoing; Wed, 5 Nov 1997 08:30:03 -0500 (EST) From: bmanning@isi.edu Posted-Date: Wed, 5 Nov 1997 05:40:08 -0800 (PST) Message-Id: <199711051340.AA25383@zed.isi.edu> Subject: Re: $SIGNER directive To: lewis@tis.com (Edward Lewis) Date: Wed, 5 Nov 1997 05:40:08 -0800 (PST) Cc: bmanning@isi.edu, lewis@tis.com, dee@cybercash.com, ogud@tis.com, gnu@toad.com, charlie_kaufman@iris.com, dns-security@tis.com In-Reply-To: from "Edward Lewis" at Nov 5, 97 08:22:04 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-dns-security@ex.tis.com Precedence: bulk > >> 1) Make the $SIGNER directive specific to a file - i.e., it is preserved > >> after a $INCLUDE. This does not ease implementation, but my experience > > Deals w/ multiple $INCLUDES? > > I don't quite follow what do you mean by multiple $INCLUDEs? Multiple nesting? > > I would guess that as an INCLUDE is followed, the origin is either > inheritied or changed to what is specified, and the signer is just > inherited (I don't want to change the $INCLUDE to add signers). On return > from the $INCLUDE, the state of the file is restored - ir-regardless of how > many levels of $INCLUDEs are nested. So you may have something like: $INCLUDE $SIGNER $INCLUDE $SIGNER $INCLUDE $SIGNER $INCLUDE $SIGNER $INCLUDE $SIGNER $INCLUDE (unsigned) $INCLUDE $SIGNER $INCLUDE $SIGNER because each of the $includes is a cut point. What now? -- --bill From owner-dns-security Wed Nov 5 09:39:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA20972 for dns-security-outgoing; Wed, 5 Nov 1997 09:38:38 -0500 (EST) X-Sender: lewis@pop.hq.tis.com Message-Id: In-Reply-To: <199711051340.AA25383@zed.isi.edu> References: from "Edward Lewis" at Nov 5, 97 08:22:04 am Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 5 Nov 1997 09:42:19 -0500 To: bmanning@isi.edu From: Edward Lewis Subject: Re: $SIGNER directive Cc: lewis@tis.com (Edward Lewis), bmanning@isi.edu, dee@cybercash.com, gnu@toad.com, charlie_kaufman@iris.com, dns-security@tis.com Sender: owner-dns-security@ex.tis.com Precedence: bulk At 8:40 AM -0500 11/5/97, bmanning@isi.edu wrote: >So you may have something like: > > $INCLUDE a > $SIGNER #1 > $INCLUDE b > $SIGNER #2 > $INCLUDE c > $SIGNER #3 > $INCLUDE d > $SIGNER #4 > $INCLUDE e > $SIGNER #5 > $INCLUDE f $SIGNER (#6 = empty line) > (unsigned) > $INCLUDE g > $SIGNER #7 > $INCLUDE h > $SIGNER #8 > > >because each of the $includes is a cut point. What now? Ok, now you've got me on the run. (I'm still not sure of the question.) A signer app runs by zone. This is unlike the server which loads many zones. So, the signer begins at cut point (which is the same as a delegation point, right?) and works until it sees the cut points. The signer doesn't 'cross' them. I added a little to the example above to try to answer the question...any records in file a are signed by #1, regardless of $INCLUDEs in a. Eg - file a file b ====== ====== $SIGNER #1 $SIGNER #2 record 1 record 4 record 2 $INCLUDE b record 3 I want to make it so that the signer of record 3 is signer #1. As it is now, the signer would be #2 as set in file b. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: +1 301-854-5794 Email: lewis@tis.com "Serenity now, insanity later" -- Lloyd Braun Opinions expressed are property of my evil twin, not my employer. From owner-dns-security Wed Nov 5 11:54:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA22081 for dns-security-outgoing; Wed, 5 Nov 1997 11:53:36 -0500 (EST) From: Xiaoyi Liu Message-Id: <199711051704.JAA02524@stilton.cisco.com> Subject: URL for download To: dns-security@tis.com Date: Wed, 5 Nov 1997 09:04:10 -0800 (PST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-dns-security@ex.tis.com Precedence: bulk Hi, I could not find the URL do downlod the most recient DNSSEC server code. Can someone point me to the right location? Thanks Xiaoyi From owner-dns-security Thu Nov 13 10:57:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA24564 for dns-security-outgoing; Thu, 13 Nov 1997 10:51:46 -0500 (EST) X-Sender: lewis@pop.hq.tis.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 13 Nov 1997 11:02:11 -0500 To: dns-security@tis.com From: Edward Lewis Subject: PROPOSED new $SIGNER syntax/semantics Sender: owner-dns-security@ex.tis.com Precedence: bulk This is a proposal for the new $SIGNER given the presence of footprints and multiple signatures per set. Both of these have been around for a long time, by I am a slow reader. ;) That is to say, the earlier definitions of the $SIGNER directive lacked either the capacity to handle footprints and/or multiple signers. Legal forms: $SIGNER [ ]+ $SIGNER [ ]* ------ operation1 = ADD | DEL operation2 = SET ADD means to add the signer (=key) to the set of currently signing keys if the key is already in the list, this is a no-op DEL means to delete the signer (=key) to the set of currently signing keys if the key is not in the list, this is a no-op SET means to delete all keys from list and replace them with the new keys if there are duplications in the list, the duplicate is a no-op add "$SIGNER SET \n" = don't apply any key (e.g., glue data) ------- name = valid domain name syntax the name need not appear in the file, nor anywhere in the DNS tree ------- footprint = 0-65535 | ANY numeric value means use that value as the footprint ANY means that the signing application chooses a key belonging to (or associated with) the name. The choice is made according to "some" policy ------- Default policy for reference signer: The signer will make a list of all keys identified in SIGNER and KEY RR lines. After processing the input files, all signers apecified by ANY will be resolved. The resolution process is: If the name is in the list of identified keys (w/ footprints) Choose according to the following: A key that has zone-key flags A key that has other signing flags Any key If the name is not found elsewhere in the list or none of the listed keys are available The key is treated as unavailable All records signed by some name's ANY key are to be signed by the same chosen key. A key that is unavailable to the signer means that the signing is not done instead, a $SIGNER is generated in the output. For example: >$SIGNER SET a 1 b 2 >rr1 type data >rr2 type data >$SIGNER ADD c 3 >rr3 type data >$SIGNER ADD a ANY >rr4 type data >$SIGNER DEL a 1 >rr5 type data >$SIGNER DEL b 2 >rr6 type data Available keys: b 2 and c 3 Unavailable: a 1 and a ANY Output: >$SIGNER SET a 1 >rr1 type data >rr1 SIG type data by b 2 >rr2 type data >rr2 SIG type data by b 2 >rr3 type data >rr3 SIG type data by b 2 >rr3 SIG type data by c 3 >$SIGNER ADD a ANY >rr4 type data >rr4 SIG type data by b 2 >rr4 SIG type data by c 3 >$SIGNER DEL a 1 >rr5 type data >rr5 SIG type data by b 2 >rr5 SIG type data by c 3 >rr6 type data >rr6 SIG type data by c 3 Note the lack of directives involving b 2 and c 3 in the final data. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: +1 301-854-5794 Email: lewis@tis.com "Serenity now, insanity later" -- Lloyd Braun Opinions expressed are property of my evil twin, not my employer. From owner-dns-security Thu Nov 13 13:12:21 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA00725 for dns-security-outgoing; Thu, 13 Nov 1997 13:11:21 -0500 (EST) X-Sender: lewis@pop.hq.tis.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 13 Nov 1997 13:21:32 -0500 To: Edward Lewis From: Edward Lewis Subject: Re: PROPOSED new $SIGNER syntax/semantics Cc: dns-security@tis.com Sender: owner-dns-security@ex.tis.com Precedence: bulk At 11:02 AM -0500 11/13/97, Edward Lewis wrote: >Legal forms: >$SIGNER [ ]+ >$SIGNER [ ]* After sitting and thinking a bit more, and facing a complier, I thought I'd propose an alternative, which is: $SIGNER [ ]* $SIGNER [ ]* This is: $SIGNER ADD a 1 b 2 c 3 $SIGNER DEL a 1 c 3 $SIGNER SET a 2 b 3 c 4 This latter proposal is a bit easier to code, and makes all three forms of the $SIGNER the same, hence easier to remember. It removes the ability to add and delete keys from a set on the same line, which I doubt is a serious loss. Comments? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: +1 301-854-5794 Email: lewis@tis.com "Serenity now, insanity later" -- Lloyd Braun Opinions expressed are property of my evil twin, not my employer. From owner-dns-security Thu Nov 13 15:10:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA06443 for dns-security-outgoing; Thu, 13 Nov 1997 15:08:53 -0500 (EST) X-Sender: lewis@pop.hq.tis.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 13 Nov 1997 15:19:07 -0500 To: Edward Lewis From: Edward Lewis Subject: Re: PROPOSED new $SIGNER syntax/semantics Cc: dns-security@tis.com Sender: owner-dns-security@ex.tis.com Precedence: bulk Another thought... At 11:02 AM -0500 11/13/97, Edward Lewis wrote: >Default policy for reference signer: > >The signer will make a list of all keys identified in SIGNER and KEY RR lines. >After processing the input files, all signers apecified by ANY will be >resolved. The resolution process is: > If the name is in the list of identified keys (w/ footprints) > Choose according to the following: Another key of the same name specifically requested > A key that has zone-key flags > A key that has other signing flags > Any key -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: +1 301-854-5794 Email: lewis@tis.com "Serenity now, insanity later" -- Lloyd Braun Opinions expressed are property of my evil twin, not my employer. From owner-dns-security Thu Nov 20 14:10:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA13925 for dns-security-outgoing; Thu, 20 Nov 1997 14:03:48 -0500 (EST) Message-Id: <199711201517.KAA23071@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: dns-security@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-dnssec-key-handling-00.txt Date: Thu, 20 Nov 1997 10:17:07 -0500 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 : Zone KEY RRSet Signing Procedure Author(s) : O. Gudmundsson, E. Lewis Filename : draft-ietf-dnssec-key-handling-00.txt Pages : 8 Date : 19-Nov-97 Under the security extensions to DNS, as defined in RFC 2065 and RFC 2137, a secured zone will have a KEY RRSet associated with the domain name at the apex of the zone. This document covers the manner in which this RRSet is generated, signed, and inserted into the name servers. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnssec-key-handling-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-key-handling-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-key-handling-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: <19971119163207.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-key-handling-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-key-handling-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971119163207.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dns-security Sun Nov 23 22:40:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA06104 for dns-security-outgoing; Sun, 23 Nov 1997 22:36:23 -0500 (EST) Date: Sat, 22 Nov 1997 19:29:21 -0600 (CST) From: "Steven(Xunhua) Wang" To: dns-security@tis.com cc: dee@cybercash.com Subject: one question Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk In draft-ietf-dnssec-secext2-01.txt, there are some sentences about the confidentiality in Section 2.1: No efforts has been made to provide for any confidentiality for queries or responses. (This service may be available via IPSEC[RFC1825] or TLS[draft-ietf-tls-*]) I doubt that IPSEC can deal with this problem. As you know IPSEC is for host-to-host case. In the case of many users share a machine which has a public resolver, IPSEC can only guarantee the communcation between this machine with the name server. If there is any bad guy in these users, IPSEC will not be able to provide privacy. In fact, Bellovin has a paper about the security faults in IPSEC(it is available at ftp://ftp.research.att.com/dist/smb/badesp.ps) Steven Wang From owner-dns-security Sun Nov 23 23:16:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA06311 for dns-security-outgoing; Sun, 23 Nov 1997 23:16:25 -0500 (EST) Date: Sun, 23 Nov 1997 23:28:37 -0500 (EST) From: "Donald E. Eastlake 3rd" To: "Steven(Xunhua) Wang" Cc: dns-security@tis.com Subject: Re: one question 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 Sat, 22 Nov 1997, Steven(Xunhua) Wang wrote: > Date: Sat, 22 Nov 1997 19:29:21 -0600 (CST) > From: Steven(Xunhua) Wang > To: dns-security@tis.com > > In draft-ietf-dnssec-secext2-01.txt, there are some sentences about the > confidentiality in Section 2.1: > > No efforts has been made to provide for any confidentiality for > queries or responses. (This service may be available via > IPSEC[RFC1825] or TLS[draft-ietf-tls-*]) > > I doubt that IPSEC can deal with this problem. As you know IPSEC is for > host-to-host case. In the case of many users share a machine which has a > public resolver, IPSEC can only guarantee the communcation between this > machine with the name server. If there is any bad guy in these users, > IPSEC will not be able to provide privacy. It all depends on what threat you are talking about and what host set up. Certainly, even assuming that all you say is correct, IPSEC could protect against eavesdropping by interediate machines (routers or other machines on shared media). That alone is certainly enough to claim that some confidentiatlity is being provided. Furthermore, I know of no requirement that a single host wide resolver be the only DNS access by all users on a multi-user machine. Surely a user especially concerned about their confidentiality would be the most likely to go to the effort of running their own resolver and protecting its packets from other users on their host by user keyed IPSEC. > In fact, Bellovin has a paper about the security faults in IPSEC(it is > available at ftp://ftp.research.att.com/dist/smb/badesp.ps) > > Steven Wang 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 Mon Nov 24 08:41:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA09365 for dns-security-outgoing; Mon, 24 Nov 1997 08:39:25 -0500 (EST) Message-Id: <199711241349.IAA07911@relay.hq.tis.com> To: "Steven(Xunhua) Wang" cc: dns-security@tis.com, dee@cybercash.com Subject: Re: one question In-reply-to: Your message of "Sat, 22 Nov 1997 19:29:21 CST." Date: Mon, 24 Nov 1997 05:49:27 -0800 From: "Derrell D. Piper" Sender: owner-dns-security@ex.tis.com Precedence: bulk Steven, > I doubt that IPSEC can deal with this problem. As you know IPSEC is for > host-to-host case. In the case of many users share a machine which has a > public resolver, IPSEC can only guarantee the communcation between this > machine with the name server. If there is any bad guy in these users, > IPSEC will not be able to provide privacy. In fact, it can. IPSEC was designed to provide keying granularity down to individual users. This may or may not be supported by the underlying host operating system, but there are specific provisions in the core protocols to provide this level of granularity. Of course, to achieve real user-level security, you will need to use an operating system that enforces protected execution domains (e.g. UNIX, VMS, NT) and provides adequate protection between mutually hostile processes. > In fact, Bellovin has a paper about the security faults in IPSEC(it is > available at ftp://ftp.research.att.com/dist/smb/badesp.ps) Steve's paper details problems relating to the use of CBC ciphers in RFC-1829. Since this paper came out (1+ years ago), we've redesigned the mandatory ESP transform to include integrity protection and anti-replay. RFC-1829 and RFC-1828 are now effectively obsolete. Their replacement drafts are now in Last Call and should be moving to RFC status very soon. Derrell From owner-dns-security Mon Nov 24 09:03:03 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA09490 for dns-security-outgoing; Mon, 24 Nov 1997 09:01:26 -0500 (EST) Date: Mon, 24 Nov 1997 08:59:29 -0500 Message-Id: <199711241359.IAA17023@rsts-11.mit.edu> To: xwang@cs.uwm.edu CC: dns-security@tis.com, dee@cybercash.com In-reply-to: (xwang@cs.uwm.edu) Subject: Re: one question From: tytso@mit.edu Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-dns-security@ex.tis.com Precedence: bulk Date: Sat, 22 Nov 1997 19:29:21 -0600 (CST) From: "Steven(Xunhua) Wang" In draft-ietf-dnssec-secext2-01.txt, there are some sentences about the confidentiality in Section 2.1: No efforts has been made to provide for any confidentiality for queries or responses. (This service may be available via IPSEC[RFC1825] or TLS[draft-ietf-tls-*]) I doubt that IPSEC can deal with this problem. As you know IPSEC is for host-to-host case. In the case of many users share a machine which has a public resolver, IPSEC can only guarantee the communcation between this machine with the name server. If there is any bad guy in these users, IPSEC will not be able to provide privacy. It's not as bad as you make out. First of all, it is possible to use different keying material on a per-user basis with IPSEC. Secondly, if you have a resource which is shared amongst multiple users: memory, the bind resolver, a IPSEC network key, it is axiomatic that in order for the machine to be secure, the Trusted Computing Base (TCB) must enforce the appropriate security rules/policies to prevent one user from interfering or spying from another. For example, if the TCB allows one user to look at the memory belong to another user, no kind of per-confidentiality is possible from other hostile users sharing the same machine. Protecting against that is the requirement of the host operating system. You can't fault a protocol specification for requiring that the host operating system be secure in a time-sharing environment; all protocols will have this property! In fact, Bellovin has a paper about the security faults in IPSEC(it is available at ftp://ftp.research.att.com/dist/smb/badesp.ps) The paper you refer documents a problem with using ESP only, without the use of AH, and was written while we were working on an updated version of the IPSEC protocols. This problem has since been resolved in the latest versions of the protocol specifications, which have just recently finished last call in the IPSEC working group. - Ted From owner-dns-security Mon Nov 24 10:50:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA10200 for dns-security-outgoing; Mon, 24 Nov 1997 10:48:32 -0500 (EST) Date: Mon, 24 Nov 1997 09:59:47 -0600 (CST) From: "Steven(Xunhua) Wang" To: "Derrell D. Piper" cc: dns-security@tis.com Subject: In-Reply-To: <199711241349.IAA07911@relay.hq.tis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk On Mon, 24 Nov 1997, Derrell D. Piper wrote: > > In fact, Bellovin has a paper about the security faults in IPSEC(it is > > available at ftp://ftp.research.att.com/dist/smb/badesp.ps) > > Steve's paper details problems relating to the use of CBC ciphers in RFC-1829. > Since this paper came out (1+ years ago), we've redesigned the mandatory ESP > transform to include integrity protection and anti-replay. RFC-1829 and > RFC-1828 are now effectively obsolete. Their replacement drafts are now in > Last Call and should be moving to RFC status very soon. Yes, your answer resolve what I mean. Hope to see the new RFC soon! From owner-dns-security Tue Nov 25 08:47:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA17168 for dns-security-outgoing; Tue, 25 Nov 1997 08:43:33 -0500 (EST) X-Sender: lewis@pop.hq.tis.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 25 Nov 1997 08:53:53 -0500 To: dns-security@tis.com From: Edward Lewis Subject: Q about proposed zone signing of parent's keys Cc: lewis@tis.com Sender: owner-dns-security@ex.tis.com Precedence: bulk I have a question regarding the proposal to have a zone sign its parents keys. The reason for this signing is to avoid having to distribute the rook keys to all and have them configured statically. During the signing of a zone, a signer may be off-line, hence unable to perform DNS queries. How does a zone identify the name of the parent zone? It is simple for one-label deep zones, but it is not trivial for multi-label deep zones. E.g.: z02. soa ... ns ... ns ... ... z20.l03.l01.z02. ns ... ... The parent of z20.l03.l01.z02. is z02. as the l0x labels are not delegated subdomains. If the signer for z20... gets the public keys for z02., how can the off-line signer decide that these are indeed the parent's keys and not just some upper layer zone? Even if these arrive in a .PARENT file (*), there is no way to verify that this is the parent. (*) - .PARENT files are files of signed DNS data generated for delegation points. A .PARENT file holds the apex's keys, signature by the alleged parent, the NXT for the alleged parent zone and its signature. If the child is to sign the parent's keys, then the alleged parent's keys are needed in this file too. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: +1 301-854-5794 Email: lewis@tis.com "Serenity now, insanity later" -- Lloyd Braun Opinions expressed are property of my evil twin, not my employer. From owner-dns-security Tue Nov 25 14:20:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA19460 for dns-security-outgoing; Tue, 25 Nov 1997 14:19:38 -0500 (EST) Date: Tue, 25 Nov 1997 14:32:08 -0500 (EST) From: "Donald E. Eastlake 3rd" To: Edward Lewis Cc: dns-security@tis.com Subject: Re: Q about proposed zone signing of parent's keys 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 I'm not sure of the best operational way for the parents/higher keys to get transmitted to the signer process. But I don't see any reason for it not to sign any higher keys it is given via a trusted path. It might even be that between one signing run and the next, it is expected that the zone structure would change or that there are cached items left over from a previous zone structure that still need to be validated. So I see no reason for any checks is the parent key signing logic other than the owner name of keys being signed be shorter than that of the signer who owns the signing key. Donald On Tue, 25 Nov 1997, Edward Lewis wrote: > Date: Tue, 25 Nov 1997 08:53:53 -0500 > From: Edward Lewis > To: dns-security@tis.com > Cc: lewis@tis.com > Subject: Q about proposed zone signing of parent's keys > > I have a question regarding the proposal to have a zone sign its parents > keys. The reason for this signing is to avoid having to distribute the > rook keys to all and have them configured statically. > > During the signing of a zone, a signer may be off-line, hence unable to > perform DNS queries. How does a zone identify the name of the parent zone? > > It is simple for one-label deep zones, but it is not trivial for > multi-label deep zones. E.g.: > > z02. soa ... > ns ... > ns ... > ... > z20.l03.l01.z02. ns ... > ... > > The parent of z20.l03.l01.z02. is z02. as the l0x labels are not delegated > subdomains. > > If the signer for z20... gets the public keys for z02., how can the > off-line signer decide that these are indeed the parent's keys and not just > some upper layer zone? Even if these arrive in a .PARENT file (*), there > is no way to verify that this is the parent. > > (*) - .PARENT files are files of signed DNS data generated for delegation > points. A .PARENT file holds the apex's keys, signature by the alleged > parent, the NXT for the alleged parent zone and its signature. If the > child is to sign the parent's keys, then the alleged parent's keys are > needed in this file too. > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis Trusted Information Systems > Phone: +1 301-854-5794 Email: lewis@tis.com > > "Serenity now, insanity later" -- Lloyd Braun > > 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 Tue Nov 25 14:57:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA19731 for dns-security-outgoing; Tue, 25 Nov 1997 14:57:36 -0500 (EST) X-Sender: lewis@pop.hq.tis.com Message-Id: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 25 Nov 1997 15:07:28 -0500 To: dns-security@tis.com From: Edward Lewis Subject: Re: Q about proposed zone signing of parent's keys Sender: owner-dns-security@ex.tis.com Precedence: bulk At 2:32 PM -0500 11/25/97, Donald E. Eastlake 3rd wrote: >I'm not sure of the best operational way for the parents/higher keys to get >transmitted to the signer process. But I don't see any reason for it not to >sign any higher keys it is given via a trusted path. It might even be that >between one signing run and the next, it is expected that the zone structure >would change or that there are cached items left over from a previous zone >structure that still need to be validated. So I see no reason for any checks >is the parent key signing logic other than the owner name of keys being >signed be shorter than that of the signer who owns the signing key. > My solution is an new directive - $PARENT . I have a fundamental problem with assuming anything, especially based on the length of a name. DNSSEC is to increase security - whether to defend against malicious attacks or simple errors. Putting in assumptions just weakens the implementation of a security system. The mechanism I am now assuming for the inclusion of parent-related data into the signing process is a thing called a .PARENT file. The .PARENT file was invented as a mechanism to avoid the erasing of data during zone loading in BIND. I see the .PARENT file's contents being the same as the data sent from the parent to the signer via out of band methods. For the DOWN policy (documented in a draft I submitted Friday but not yet announced), the contents of the .PARENT file must include: The apex's NXT set in the parent The signature of that NXT set, signed by the parent The apex's KEY set The signature of the KEY set, signed by the parent For the UP policy, the following must be added: The parent's apex KEY set - unsigned The parent's apex NS set The address (glue) records for the NS set Signatures are optional. For the UP to work, the information in the UP .PARENT file must be treated differently than any other in BIND's current named. This .PARENT information should be held in lower credibility and security than that which is learned. However, if the learned information TTL's out, this information cannot disappear from the name server. (It shouldn't give it out anymore, but it should use it as a hint for finding parental and above information.) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: +1 301-854-5794 Email: lewis@tis.com "Serenity now, insanity later" -- Lloyd Braun Opinions expressed are property of my evil twin, not my employer. From owner-dns-security Fri Nov 28 02:13:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA07332 for dns-security-outgoing; Fri, 28 Nov 1997 02:08:58 -0500 (EST) From: Andrade Software Andrade Networking Message-Id: <199711280719.XAA13577@netcom13.netcom.com> Subject: Re: one question To: tytso@mit.edu Date: Thu, 27 Nov 1997 23:19:25 -0800 (PST) Cc: xwang@cs.uwm.edu, dns-security@tis.com, dee@cybercash.com In-Reply-To: <199711241359.IAA17023@rsts-11.mit.edu> from "tytso@mit.edu" at Nov 24, 97 08:59:29 am Sender: owner-dns-security@ex.tis.com Precedence: bulk Andrade Software & Networking Andrad@Netcom.Com MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1119 > > In fact, Bellovin has a paper about the security faults in IPSEC(it is > available at ftp://ftp.research.att.com/dist/smb/badesp.ps) > > The paper you refer documents a problem with using ESP only, without the > use of AH, and was written while we were working on an updated version > of the IPSEC protocols. This problem has since been resolved in the > latest versions of the protocol specifications, which have just recently > finished last call in the IPSEC working group. > So AH and ESP must now be together? Also how frequently is rekeying occurring? Is it per packet? How fast is key exchange and setup? How easy is it to tie keys to a user? How is trust managed between users or other entities? I guess I need to read the latest IPSEC I-D's to see if things have improved much since last year. Security at the IP layer is really very difficult to achieve because of its datagram nature and the fact that trust must ultimately flow from humans operating above the transport layer. - Alex -- Alex Alten P.O. Box 11406 Pleasanton, CA 94588 USA Andrade@Netcom.Com (510) 417-0159 From owner-dns-security Fri Nov 28 16:25:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA11230 for dns-security-outgoing; Fri, 28 Nov 1997 16:23:01 -0500 (EST) Date: Fri, 28 Nov 1997 16:33:53 -0500 Message-Id: <199711282133.QAA29981@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Andrade Software Andrade Networking Cc: xwang@cs.uwm.edu, dns-security@tis.com, dee@cybercash.com In-Reply-To: Andrade Software Andrade Networking's message of Thu, 27 Nov 1997 23:19:25 -0800 (PST), <199711280719.XAA13577@netcom13.netcom.com> Subject: Re: one question Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-dns-security@ex.tis.com Precedence: bulk From: Andrade Software Andrade Networking Date: Thu, 27 Nov 1997 23:19:25 -0800 (PST) So AH and ESP must now be together? No; ESP has been changed to also include data intgrity protection; AH can be still used alone if data confidentiality is not desired. Also how frequently is rekeying occurring? Is it per packet? How fast is key exchange and setup? How often rekeying is done is an administrative issue; it is typically will NOT be per packet. Key exchange and setup requires public key operations, so there will be the typical CPU requirements to do a public key exchange/setup. How easy is it to tie keys to a user? How is trust managed between users or other entities? These are administrative issues that are implementation specific. IPSEC allows for keys to be either per-user or per-host; depending on what the implementation has been optimized for, either or both may be supported. (For example, a security gateway which is used to tie two LAN's together over the general network, to form a Virtual Private Network, will obviously not be doing per-user keying, since that's not the goal of that use of IPSEC.) I guess I need to read the latest IPSEC I-D's to see if things have improved much since last year. Yes, you really do need to read the latest IPSEC I-D's. Much has changed in the last year. - Ted