From owner-dns-security Sun Dec 1 15:51:19 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA20348 for dns-security-outgoing; Sun, 1 Dec 1996 15:47:30 -0500 (EST) Message-Id: Date: Sun, 1 Dec 96 12:49 PST From: randy@psg.com (Randy Bush) To: Olafur Gudmundsson Cc: Paul Wren , namedroppers@internic.net, dns-security@tis.com Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and draft-ietf-dnsind-clarify-02.txt) References: <2.2.32.19961125222641.01677670@pop-sb.software.com> <9611261541.AA15251@sol.hq.tis.com> Sender: owner-dns-security@ex.tis.com Precedence: bulk > Please continue to forward your questions/comments to dns-security@tis.com. Olafur, I think it is useful for interoperatability issues to be on dnsind and dnssec public wg lists. randy From owner-dns-security Tue Dec 3 07:24:38 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA23495 for dns-security-outgoing; Tue, 3 Dec 1996 07:21:25 -0500 (EST) Date: Mon, 2 Dec 1996 23:55:12 -0500 (EST) Message-Id: <199612030455.XAA02636@patty.cs.columbia.edu> From: "Maggie M. Lee" To: dns-security@tis.com Subject: secure dns Sender: owner-dns-security@ex.tis.com Precedence: bulk Hi, I heard that secure dns has been released. I checked tis' home page but couldn't find it. Would you mind telling me where I can find a copy please? Thanks. Maggie Lee From owner-dns-security Tue Dec 3 10:20:15 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA24095 for dns-security-outgoing; Tue, 3 Dec 1996 10:19:28 -0500 (EST) Date: Tue, 3 Dec 1996 10:18:50 -0500 (EST) From: "Donald E. Eastlake 3rd" To: "Maggie M. Lee" Cc: dns-security@tis.com Subject: Re: secure dns In-Reply-To: <199612030455.XAA02636@patty.cs.columbia.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk Try http://www.tis.com/docs/research/network/dns.html for info on the TIS Beta implementation. Donald On Mon, 2 Dec 1996, Maggie M. Lee wrote: > Date: Mon, 2 Dec 1996 23:55:12 -0500 (EST) > From: Maggie M. Lee > To: dns-security@tis.com > Subject: secure dns > > > Hi, > > I heard that secure dns has been released. I checked tis' home page > but couldn't find it. Would you mind telling me where I can find a > copy please? Thanks. > > Maggie Lee ===================================================================== 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 From owner-dns-security Tue Dec 3 12:45:17 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA24365 for dns-security-outgoing; Tue, 3 Dec 1996 12:43:30 -0500 (EST) Date: Tue, 3 Dec 1996 12:06:00 -0500 (EST) Message-Id: <199612031706.MAA04310@patty.cs.columbia.edu> From: "Maggie M. Lee" To: dee@cybercash.com CC: dns-security@tis.com In-reply-to: (dee@cybercash.com) Subject: Re: secure dns Sender: owner-dns-security@ex.tis.com Precedence: bulk Don, Thanks a lot. I have read your internet-drafts on Secure DNS. They are very good. Maggie From owner-dns-security Tue Dec 3 13:28:08 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA24477 for dns-security-outgoing; Tue, 3 Dec 1996 13:27:00 -0500 (EST) X-Lotus-FromDomain: IBM RESEARCH From: "Padmaja Rao" To: dns-security@tis.com Message-ID: <852563F5:00653030.00@watngi01.watson.ibm.com> Date: Tue, 3 Dec 1996 13:27:50 -0400 Subject: Re: secure dns Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=xvsNQCmgEPnAoUDSCeArDNj4dQkJNrPaxHD7cBTLXhtlarHr70uV6x5a" Sender: owner-dns-security@ex.tis.com Precedence: bulk --0__=xvsNQCmgEPnAoUDSCeArDNj4dQkJNrPaxHD7cBTLXhtlarHr70uV6x5a Content-type: text/plain; charset=us-ascii Hi, Does anyone know if the final version (release) of this code will be available as public domain code. Padma ------ To: maggie @ cs.columbia.edu cc: dns-security @ tis.com (bcc: Padmaja Rao/Watson/IBM Research) From: dee @ cybercash.com Date: 12/03/96 10:18:50 AM Subject: Re: secure dns --0__=xvsNQCmgEPnAoUDSCeArDNj4dQkJNrPaxHD7cBTLXhtlarHr70uV6x5a Try http://www.tis.com/docs/research/network/dns.html for info on the TIS Beta implementation. Donald On Mon, 2 Dec 1996, Maggie M. Lee wrote: > Date: Mon, 2 Dec 1996 23:55:12 -0500 (EST) > From: Maggie M. Lee > To: dns-security@tis.com > Subject: secure dns > > > Hi, > > I heard that secure dns has been released. I checked tis' home page > but couldn't find it. Would you mind telling me where I can find a > copy please? Thanks. > > Maggie Lee ===================================================================== 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 --0__=xvsNQCmgEPnAoUDSCeArDNj4dQkJNrPaxHD7cBTLXhtlarHr70uV6x5a-- From owner-dns-security Wed Dec 4 04:16:39 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA25556 for dns-security-outgoing; Wed, 4 Dec 1996 04:15:03 -0500 (EST) Message-Id: <1.5.4.32.19961204091731.006cee5c@gatekeeper.grolier.fr> X-Sender: merlin@gatekeeper.grolier.fr X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 04 Dec 1996 10:17:31 +0100 To: dns-security@tis.com From: Thomas Merlin Subject: MacOS Sender: owner-dns-security@ex.tis.com Precedence: bulk Hello, I'm not sure this is the correct mailing list, but I was wondering if MacOS was a reliable solution for a secure web site. (Our web site has to be very-very-very-very-secure.) Thanks for your feedback, Best regards, Tom. From owner-dns-security Wed Dec 4 09:43:36 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA26483 for dns-security-outgoing; Wed, 4 Dec 1996 09:41:46 -0500 (EST) Date: Wed, 4 Dec 1996 09:41:22 -0500 (EST) From: "Donald E. Eastlake 3rd" To: Thomas Merlin Cc: dns-security@tis.com Subject: Re: MacOS In-Reply-To: <1.5.4.32.19961204091731.006cee5c@gatekeeper.grolier.fr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk This mailing list is for disucssion of Domain Name System security. The DNS is the system that lets you look up things like grolier.fr and find out what IP address handles email sent to that name, etc. This mailing list has nothing to do with particular operating systems. Maybe you should try www-talk@w3.org. (But my personal impression is that MacOS is a very popular and secure web server platform.) I have also received a private email message asking if dns-security will enable you to restrict web access to certain users. DNS security as such has little to do with web server security. Of course, in some sense, security is only as good as the weakest link and DNS security helps out anything that uses the DNS, including web access: The primary goal of DNS Security is "data origin authentication", that is, with appropriate configuration, assurance that data retrieved from a secure DNS zone is the authentic data intended by the zone master. For example, it could assure that the A (or AAAA) record retrieved with the IP address for your web server name is the address data actually inserted by the owner of your DNS zone so people are at least, hopefully, trying your address instead of some other address. While this is important, it has very little to do with protecting your web server once the user manages to get packets to it. It also turns out that DNS Security provides a convenient secure key distribution mechanism. This key distribution mechanism could be used as the basis for SSL or IPSEC like secure communications between a browser and a web server. That is begining to get at web access security since it could also be used as the basis for secure client identity, but it would require a lot more mechanism in addition to DNS security to provide that. Donald On Wed, 4 Dec 1996, Thomas Merlin wrote: > Date: Wed, 04 Dec 1996 10:17:31 +0100 > From: Thomas Merlin > To: dns-security@tis.com > Subject: MacOS > > Hello, > > I'm not sure this is the correct mailing list, but I was wondering if MacOS > was a reliable solution for a secure web site. (Our web site has to be > very-very-very-very-secure.) > > Thanks for your feedback, > > Best regards, > > Tom. > > ===================================================================== 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 From owner-dns-security Thu Dec 5 07:31:11 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA28271 for dns-security-outgoing; Thu, 5 Dec 1996 07:30:19 -0500 (EST) Date: Thu, 5 Dec 1996 07:30:19 -0500 (EST) From: owner-dns-security@ex.tis.com Message-Id: <199612051230.HAA28271@portal.ex.tis.com> To: "Donald E. Eastlake 3rd" cc: Havard.Eidnes@runit.sintef.no, namedroppers@internic.net, dns-security@tis.com, gnu@toad.com Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and draft-ietf-dnsind-clarify-02.txt) In-reply-to: Date: Wed, 04 Dec 1996 14:58:31 -0800 From: John Gilmore Sender: owner-dns-security@portal.ex.tis.com Precedence: bulk I think this is just a clarification from last week's discussion. > The superior authenticity of the KEY in the superzone > really comes from it being signed by the superzone. If the same KEY and > SIG appear at the apex of the subzone, they are equally authentic. To restate the above in simpler terms: What is critical in providing a certification chain authenticating each domain is that a SIG record, whose signer is the parent domain, exists to cover the domain's KEY record. Whether this record is served by the parent domain (as glue) or by the child domain (as authoritative), or both, is irrelevant to the certification chain. However, to preserve the integrity of DNS caching, glue records should always match the authoritative data. This argues against having parent domains provide KEY records for domains which do not implement DNSSEC (unless the child domains also provide the same null KEY record). It also argues against having different SIG KEY records in the parent and child zones (one signed by the parent, the other by the child). Instead, the child should serve both SIG records. The parent can choose to offer none, one, or both as glue. John From owner-dns-security Thu Dec 5 08:40:40 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA28390 for dns-security-outgoing; Thu, 5 Dec 1996 08:40:19 -0500 (EST) From: Samuli Mattila Message-Id: <199612051153.NAA20042@pallo.cs.hut.fi> Subject: key revokation in DNSSEC To: dns-security@tis.com Date: Thu, 5 Dec 1996 13:52:58 +0200 (EET) Cc: zam@iki.fi, Jarmo.Kaikkonen@hut.fi X-Mailer: ELM [version 2.4ME+ PL27 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-dns-security@ex.tis.com Precedence: bulk Hello all. A slight problem here with DNSSEC: We are implementing a generic public key encryptation scheme authentication layer, that supports RSA, ECC, ElGamal and LUC. This service layer uses smartcards (CSU) for decryptation and signing and DNSSEC for key distribution. It is highly unclear to me how key revokation is works in DNSSEC. Supposed that one of the secret keys is exposed, (or card losed in our case) and the exposed key is cached to various DNSSEC-servers (assuming TTL is too long), how do we tell all servers that some key is canceled? Is there some builtin revokation list broadcast? All suggestions are welcome. -- Samuli Mattila From owner-dns-security Thu Dec 5 09:09:55 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA28488 for dns-security-outgoing; Thu, 5 Dec 1996 09:09:47 -0500 (EST) Date: Thu, 5 Dec 1996 09:09:20 -0500 (EST) From: "Donald E. Eastlake 3rd" To: John Gilmore Cc: namedroppers@internic.net, dns-security@tis.com Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and draft-ietf-dnsind-clarify-02.txt) In-Reply-To: <199612051243.HAA24610@rs1.internic.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk John,, For some time we will have zones that are not secure and have not been modified in any way for security. Such zones will not have a signed null KEY RR or, indeed, any KEY or security RR. It is essential to be able to securely know that such a zone is insecure. Otherwise, someone wanting to spoof a zone will just pretend that it's an insecure zone that has not been modified in any way for security. The manner in which the DNSSEC Proposed Standard achieves this essential secure knowledge that a zone is insecure is by having a null KEY RR in the superzone signed by the superzone. It does not matter to DNSSEC what the state of the DNS authority bit is when this RR is retrieved. If you drop this from the superzone you have to introduce this secure information somewhere else in the superzone. You can't put it in the subzone without requiring every DNS zone is existence to be modified, which seems impractical to me. Thus I agree with most of what you say except that in the case of an insecure subzone the supezone *must* provide a null KEY RR. Donald On Wed, 4 Dec 1996, John Gilmore wrote: > Date: Wed, 04 Dec 1996 14:58:31 -0800 > From: John Gilmore > To: "Donald E. Eastlake 3rd" > Cc: Havard.Eidnes@RUNIT.SINTEF.NO, namedroppers@internic.net, > dns-security@TIS.COM, gnu@toad.com > Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and draft-ietf-dnsind-clarify-02.txt) > > I think this is just a clarification from last week's discussion. > > > The superior authenticity of the KEY in the superzone > > really comes from it being signed by the superzone. If the same KEY and > > SIG appear at the apex of the subzone, they are equally authentic. > > To restate the above in simpler terms: > > What is critical in providing a certification chain authenticating > each domain is that a SIG record, whose signer is the parent domain, > exists to cover the domain's KEY record. > > Whether this record is served by the parent domain (as glue) or by the > child domain (as authoritative), or both, is irrelevant to the > certification chain. > > However, to preserve the integrity of DNS caching, glue records should > always match the authoritative data. > > This argues against having parent domains provide KEY records for > domains which do not implement DNSSEC (unless the child domains also > provide the same null KEY record). It also argues against having > different SIG KEY records in the parent and child zones (one signed > by the parent, the other by the child). Instead, the child should serve > both SIG records. The parent can choose to offer none, one, or both > as glue. > > John > ===================================================================== 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 From owner-dns-security Thu Dec 5 09:49:59 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA28557 for dns-security-outgoing; Thu, 5 Dec 1996 09:48:19 -0500 (EST) Date: Thu, 5 Dec 1996 09:50:14 -0500 (EST) From: Edward Lewis X-Sender: lewis@singsing.hq.tis.com To: "Donald E. Eastlake 3rd" cc: John Gilmore , namedroppers@internic.net, dns-security@tis.com Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and draft-ietf-dnsind-clarify-02.txt) 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 Thu, 5 Dec 1996, Donald E. Eastlake 3rd wrote: > > Thus I agree with most of what you say except that in the case of an > insecure subzone the supezone *must* provide a null KEY RR. I disagree that there is a need to "must provide." Before I get into this headscratching example, let me say that I am not opposed to the "must" requirement's presence in the specification. It's implementable. I am merely trying to show there is no technical reason for it being present. (And thus, philosophically I guess I'm against it's presence.) (I hope this example is correct...if not, it exposes a weakness in understanding on my part. Please correct me...) Here is an example in which I think providing a null key is not helpful. The synopsis is that a parent zone is not the signer of the child's KEY RR. This could occur between a TLD (e.g., .COM and PSI) and a registrant in the TLD (e.g., zy23.com). In the example, "top." is the TLD, "bottom.top." is the delegated zone. Here is the inital state. In parent zone: $ORIGIN top. @ SOA ... ... KEY 33025 { Zone signing } ... bottom NS ns.bottom.top. KEY 256 { Null zone key } SIG KEY ... by top. ... ... In bottom.top.: $ORIGIN bottom.top. @ SOA ... ... KEY 33025 { Zone signing } ;;;;; a contradiction! SIG KEY ... by someone.else ... ... ns A 10.6.83.17 SIG A ...by bottom.top. ... ... bottom.top. is using "someone.else." to sign their zone key. This may not (ever) be known to top. Afterall, it is probably not running recursively. Now, if somehow this is inserted into top. "illegally" a secure zone would be "hijacked." ns.bottom.top. A 199.32.35.132 ; added to top.'s cache This nameserver (at 199.32.35.132) would be able to pull this off using non-secured DNS. It may even be able to pull it off as a secured DNS if it dupes "another.signer." to hold it's key - and "another.signer." is a trusted holder. The problem is that the top. zone should be authoritative for 1) the existence of the delegations NS and KEY records and 2) any SIG and NXT records it adds. The top zone is NOT authoritative for the contents of either the NS or KEY records, nor for the existence nor contents of any other records in the delegation. Having the null KEY RR means the parent is creating a record (and its contents) "outside its authority." And then it has the gall ;) to sign it! Without the null KEY RR, this is also possible, this situation is not caused by the presence of the null KEY RR. However, I don't see an advantage to having it. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: 301-854-5794 Email: lewis@tis.com From owner-dns-security Thu Dec 5 09:52:52 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA28592 for dns-security-outgoing; Thu, 5 Dec 1996 09:52:48 -0500 (EST) Date: Thu, 5 Dec 1996 09:52:33 -0500 (EST) From: "Donald E. Eastlake 3rd" To: Samuli Mattila Cc: dns-security@tis.com, zam@iki.fi, Jarmo.Kaikkonen@hut.fi Subject: Re: key revokation in DNSSEC In-Reply-To: <199612051153.NAA20042@pallo.cs.hut.fi> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk The original DNSSEC proposal by myself and Charlie Kaufman had a key revocation scheme but the overwhelming consensus of the WG was to leave that out for now. Key validity is generally determined by the expiration time in the SIG authenticating the KEY, not the TTL which is only a chache consistency mechanism. For the algorithm 1 DNSSEC keys, the idea to have fairly short expiration times, perhaps a couple of days, and just not worry about revocation for now. It's not like a long lived certificate system where things are valid for months or years. If you are using private algorithms or whatever, you could encode revocation information in KEY RRs if you wanted. Donald On Thu, 5 Dec 1996, Samuli Mattila wrote: > Date: Thu, 5 Dec 1996 13:52:58 +0200 (EET) > From: Samuli Mattila > To: dns-security@tis.com > Cc: zam@iki.fi, Jarmo.Kaikkonen@hut.fi > Subject: key revokation in DNSSEC > > Hello all. > > A slight problem here with DNSSEC: > > We are implementing a generic public key encryptation scheme > authentication layer, that supports RSA, ECC, ElGamal and LUC. > This service layer uses smartcards (CSU) for decryptation and > signing and DNSSEC for key distribution. > > It is highly unclear to me how key revokation is works in DNSSEC. > Supposed that one of the secret keys is exposed, (or card losed > in our case) and the exposed key is cached to various DNSSEC-servers > (assuming TTL is too long), how do we tell all servers that some > key is canceled? > > Is there some builtin revokation list broadcast? > > All suggestions are welcome. > > > -- Samuli Mattila > > > ===================================================================== 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 From owner-dns-security Thu Dec 5 10:02:56 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA28645 for dns-security-outgoing; Thu, 5 Dec 1996 10:02:49 -0500 (EST) Date: Thu, 5 Dec 1996 10:02:03 -0500 (EST) From: "Donald E. Eastlake 3rd" To: Edward Lewis Cc: namedroppers@internic.net, dns-security@tis.com Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and draft-ietf-dnsind-clarify-02.txt) 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 Ed, Your example seems to have little to do with what I was saying. (1) I was considering the normal general case where you were working your way down from root. If you have prior knowledge of a zone's key or if the zone is cross certified by someone whose key you trust, then you should trust the zone as secure. (2) I spoke only of the case of an unmodified insecure zone. In that case only, I said you *must* have a secure indication in the superzone that this subzone is insecure, otherwise someone tracing down from root can be spoofed into thinking they have stepped into an insecure zone. Your example is of a secure zone. It is has been modified from an insecure zone by the addition of security RRs. My "must" did not apply to secure zones. Donald On Thu, 5 Dec 1996, Edward Lewis wrote: > Date: Thu, 5 Dec 1996 09:50:14 -0500 (EST) > From: Edward Lewis > To: "Donald E. Eastlake 3rd" > Cc: John Gilmore , namedroppers@internic.net, > dns-security@tis.com > Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and draft-ietf-dnsind-clarify-02.txt) > > On Thu, 5 Dec 1996, Donald E. Eastlake 3rd wrote: > > > > Thus I agree with most of what you say except that in the case of an > > insecure subzone the supezone *must* provide a null KEY RR. > > I disagree that there is a need to "must provide." Before I get into > this headscratching example, let me say that I am not opposed to the > "must" requirement's presence in the specification. It's implementable. > I am merely trying to show there is no technical reason for it being > present. (And thus, philosophically I guess I'm against it's presence.) > > (I hope this example is correct...if not, it exposes a weakness in > understanding on my part. Please correct me...) > > Here is an example in which I think providing a null key is not helpful. > The synopsis is that a parent zone is not the signer of the child's KEY > RR. This could occur between a TLD (e.g., .COM and PSI) and a registrant > in the TLD (e.g., zy23.com). > > In the example, "top." is the TLD, "bottom.top." is the delegated zone. > Here is the inital state. > > In parent zone: > > $ORIGIN top. > @ SOA ... > ... > KEY 33025 { Zone signing } > ... > bottom NS ns.bottom.top. > KEY 256 { Null zone key } > SIG KEY ... by top. ... > ... > > In bottom.top.: > > $ORIGIN bottom.top. > @ SOA ... > ... > KEY 33025 { Zone signing } ;;;;; a contradiction! > SIG KEY ... by someone.else ... > ... > ns A 10.6.83.17 > SIG A ...by bottom.top. ... > ... > > bottom.top. is using "someone.else." to sign their zone key. This may not > (ever) be known to top. Afterall, it is probably not running recursively. > > Now, if somehow this is inserted into top. "illegally" a secure zone > would be "hijacked." > > ns.bottom.top. A 199.32.35.132 ; added to top.'s cache > > This nameserver (at 199.32.35.132) would be able to pull this off using > non-secured DNS. It may even be able to pull it off as a secured DNS if > it dupes "another.signer." to hold it's key - and "another.signer." is a > trusted holder. > > The problem is that the top. zone should be authoritative for 1) the > existence of the delegations NS and KEY records and 2) any SIG and NXT > records it adds. The top zone is NOT authoritative for the contents of > either the NS or KEY records, nor for the existence nor contents of any > other records in the delegation. > > Having the null KEY RR means the parent is creating a record (and its > contents) "outside its authority." And then it has the gall ;) to sign it! > > Without the null KEY RR, this is also possible, this situation is not > caused by the presence of the null KEY RR. However, I don't see an > advantage to having it. > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis Trusted Information Systems > Phone: 301-854-5794 Email: lewis@tis.com > > ===================================================================== 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 From owner-dns-security Thu Dec 5 10:34:02 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA28795 for dns-security-outgoing; Thu, 5 Dec 1996 10:33:48 -0500 (EST) Date: Thu, 5 Dec 1996 10:35:36 -0500 (EST) From: Edward Lewis X-Sender: lewis@singsing.hq.tis.com To: "Donald E. Eastlake 3rd" cc: namedroppers@internic.net, dns-security@tis.com Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and draft-ietf-dnsind-clarify-02.txt) 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 Thu, 5 Dec 1996, Donald E. Eastlake 3rd wrote: > Your example seems to have little to do with what I was saying. "Seems" is correct. Sorry about not being clear... Considering the assumptions that everyone is following the specification, the presence of the null KEY RR indicated a non-secured delegated zone. I see that. The absence of any KEY RR results in not knowing what to expect of the delegated zone's security. My understanding of that is why I am not vehemently opposed to the requirement. But in considering the operational scenarios, in which mistakes and outright malicious attacks occur, the presence of the null KEY RR is no more helpful than having no KEY RR at a delegation point. This is what my example is trying to illustrate. Consider a delegating zone that (early on) does not offer to sign KEY RR's for it's clients, but is running the secure DNS extenstions. For the registry's clients that are running secure DNS with a zone key, the null KEY (inserted as required by the delegator) is incorrect. Another situation may occur during the switch to secure DNS. A client of a registry may "forget" to tell the registry that it is using someone else to sign it's zone keys. (I have worked at places with incorrect network contact information in the whois database. Network management - as opposed to adminisitrators - seem to forget to update such information.) Yet another situation is the malicious polluting of the parent by a rogue administrator (or other means). This is the situation in which the parent is overstepping it's bounds by creating the contents for which it does not have authority. (This only works for the null KEY RR - it's the only RR that a secure resolver expects to get from the parent and the parent's KEY to verify.) The bottom line is that in theory, the null KEY RR authoritatively and correctly indicates a non-secured delegation. But in practice, this gives too much(?) power to the delegating zone over the delegation. (Would you want a TLD aministration to be able to hold your zone at "null KEY point" over some issue? ;) ) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: 301-854-5794 Email: lewis@tis.com From owner-dns-security Thu Dec 5 16:46:41 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA29500 for dns-security-outgoing; Thu, 5 Dec 1996 16:43:59 -0500 (EST) Message-Id: <9612052145.AA20433@sol.hq.tis.com> To: "Padmaja Rao" Cc: ogud@tis.com, dns-security@tis.com Subject: Re: secure dns In-Reply-To: Your message of "Tue, 03 Dec 1996 13:27:50 -0400." <852563F5:00653030.00@watngi01.watson.ibm.com> Date: Thu, 05 Dec 1996 16:45:53 -0500 From: Olafur Gudmundsson Sender: owner-dns-security@ex.tis.com Precedence: bulk "Padmaja Rao" writes: > > --0__=xvsNQCmgEPnAoUDSCeArDNj4dQkJNrPaxHD7cBTLXhtlarHr70uV6x5a > Content-type: text/plain; charset=us-ascii > > > > Hi, > Does anyone know if the final version (release) of this code will be > available as public domain code. When it gets migrared into the standard bind distribution. There will be at least one more release of the TIS code soon after IETF, to bring it up to bind-4.9.5. Olafur From owner-dns-security Thu Dec 5 22:06:41 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA29917 for dns-security-outgoing; Thu, 5 Dec 1996 22:05:54 -0500 (EST) From: Masataka Ohta Message-Id: <199612060248.LAA13527@necom830.hpcl.titech.ac.jp> Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and draft-ietf-dnsind-clarify-02.txt) To: lewis@tis.com (Edward Lewis) Date: Fri, 6 Dec 96 11:48:35 JST Cc: dee@cybercash.com, gnu@toad.com, namedroppers@internic.net, dns-security@tis.com In-Reply-To: ; from "Edward Lewis" at Dec 5, 96 9:50 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-dns-security@ex.tis.com Precedence: bulk > > Thus I agree with most of what you say except that in the case of an > > insecure subzone the supezone *must* provide a null KEY RR. > > I disagree that there is a need to "must provide." Before I get into > this headscratching example, let me say that I am not opposed to the > "must" requirement's presence in the specification. It's implementable. As long as you don't call the implementation DNS, it would be implementable. > I am merely trying to show there is no technical reason for it being > present. (And thus, philosophically I guess I'm against it's presence.) Agreed. The null KEY RR gives mere half cooked and half broken protection against unimportant denial of service. In the real world applications, it is useless to securely know that some lookup is insecure. The only meaningful protection agaist denial of service attacks is to securely know that some node does not exist, which can be performed by ZL RRs without introducing glue related complications. Masataka Ohta From owner-dns-security Fri Dec 6 02:07:58 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA00021 for dns-security-outgoing; Fri, 6 Dec 1996 02:06:12 -0500 (EST) Date: Thu, 5 Dec 1996 23:08:27 -0800 (PST) X-btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: dns-security@tis.com From: paul@vix.com (Paul A Vixie) Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and draft-ietf-dnsind-clarify-02.txt) Organization: Vixie Enterprises Message-ID: References: NNTP-Posting-Host: wisdom.home.vix.com In-reply-to: lewis@tis.com's message of 5 Dec 1996 08:32:19 -0800 Xref: vixie local.mail.dns.security:460 Sender: owner-dns-security@ex.tis.com Precedence: bulk There's a limit to how much we ought to change the fundamental underlayment of DNS just to provide security. I don't like type-covered since it means some RRsets are no longer denoted by a tuple. But Donald explained to me why this was necessary and I could not think of a better way either. In the case of parent-vs-child SIGs, the answer is clearer by far: the zone's servers are authoritative for the zone, the parent has NS RRs only, and the zone needs to be resigned with the parent's key when it changes. If this means an out of band protocol needs to be specified to make zone signatures work, I hope that someone here will get started on that really soon. -- Paul Vixie La Honda, CA "Illegitimibus non carborundum." pacbell!vixie!paul From owner-dns-security Fri Dec 6 05:34:02 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id FAA00146 for dns-security-outgoing; Fri, 6 Dec 1996 05:32:41 -0500 (EST) Message-ID: <32A7F8B7.794BDF32@inria.fr> Date: Fri, 06 Dec 1996 11:43:03 +0100 From: Shabou Malek Organization: INRIA X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 4.1.3_U1 sun4m) MIME-Version: 1.0 To: dns-security@tis.com Subject: request for information Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-dns-security@ex.tis.com Precedence: bulk i work in INRIA (france) on dynamicUpdate and security of the dns and i am looking of technical documentation of the bind (vixie release and tis release) (fonctions and API) shabou malek From owner-dns-security Sat Dec 7 01:43:03 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA02136 for dns-security-outgoing; Sat, 7 Dec 1996 01:41:26 -0500 (EST) From: Masataka Ohta Message-Id: <199612070642.PAA01999@necom830.hpcl.titech.ac.jp> Subject: Re: DNSSEC and split RRsets (was: dynDNS-draft comment and draft-ietf-dnsind-clarify-02.txt) To: paul@vix.com (Paul A Vixie) Date: Sat, 7 Dec 96 15:42:00 JST Cc: dns-security@tis.com In-Reply-To: ; from "Paul A Vixie" at Dec 5, 96 11:08 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-dns-security@ex.tis.com Precedence: bulk Paul; > There's a limit to how much we ought to change the fundamental underlayment > of DNS just to provide security. I don't like type-covered since it means > some RRsets are no longer denoted by a tuple. But Donald > explained to me why this was necessary and I could not think of a better way > either. You should have asked me. While things like is necessary, it is possible to reduce the size of the RR with , which means that, most of the case, all the RRs with confortably fits in a single 512 byte message. To do so, let the RR with have digest (16 or 20 byte long), not signature (64~256 byte long). For example, with the following RR RRD the length of an RR without the name is only 32 (with MD5 digest) or 36 (with SHA digest) bytes long. The digest values themselves, then, digested and signed only once per a node. That is, you can put more than 10 RRs in a single UDP packet. Masataka Ohta From owner-dns-security Mon Dec 9 12:17:01 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA05501 for dns-security-outgoing; Mon, 9 Dec 1996 12:13:27 -0500 (EST) Message-Id: <2.2.32.19961209171504.006832cc@popsrvr.hq.tis.com> X-Sender: ogud@popsrvr.hq.tis.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 09 Dec 1996 12:15:04 -0500 To: Samuli Mattila , dns-security@tis.com From: Olafur Gudmundsson Subject: Re: key revokation in DNSSEC Cc: zam@iki.fi, Jarmo.Kaikkonen@hut.fi Sender: owner-dns-security@ex.tis.com Precedence: bulk At 01:52 PM 12/5/96 +0200, Samuli Mattila wrote: >Hello all. > >A slight problem here with DNSSEC: > >It is highly unclear to me how key revokation is works in DNSSEC. >Supposed that one of the secret keys is exposed, (or card losed >in our case) and the exposed key is cached to various DNSSEC-servers >(assuming TTL is too long), how do we tell all servers that some >key is canceled? Short answer, you can not !! DNSSEC does not have KEY revocation, KEYs expire when the accompanying Signature expires (based on the expiration thime in the signature). If you need to be able to remove keys rapidly you keep your zone TTL and expiration times low. This on the other hand forces you to resign your zone freqently. There is no way that DNS can be modified in a way that originating zone can purge data from all caching servers that may contain the data. DNSSEC has accepted the fact that TTL is the lower and most often the upper bound on how long revoked KEYS stay around. Malicious servers can continue to return the revoked KEY until its Signature expires. The question is who will ask the malicious server. The operational guideline should be to keep your TTL value > >Is there some builtin revokation list broadcast? No > >All suggestions are welcome. Keep your TTLs low and resign Store all KEYs you possibly want to revoke below your zone apex (zone name). Olafur =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Olafur Gudmundsson ogud@tis.com 3060 Washington Road 301-854-5700 Glenwood MD 21738 301-854-5363 From owner-dns-security Mon Dec 9 13:43:13 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA05737 for dns-security-outgoing; Mon, 9 Dec 1996 13:40:44 -0500 (EST) From: Samuli Mattila Message-Id: <199612091843.UAA04093@pallo.cs.hut.fi> Subject: key revocation (continued) In-Reply-To: <2.2.32.19961209171504.006832cc@popsrvr.hq.tis.com> from Olafur Gudmundsson at "Dec 9, 96 12:15:04 pm" To: ogud@tis.com (Olafur Gudmundsson) Date: Mon, 9 Dec 1996 20:43:09 +0200 (EET) Cc: dns-security@tis.com, zam@iki.fi X-Mailer: ELM [version 2.4ME+ PL27 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-dns-security@ex.tis.com Precedence: bulk > Short answer, you can not !! As you are well aware there is a huge demand for a key exchange server on the market. If you are implementing such a server, why make it crippled? We at HUT are doing a research on smartcards and a pilot-version of a layer that allows third party software to use PK-encryption for authentication, and we use DNSSEC for key exchange. Soon Finnish government will pass a law that allows smartcards (CSU) as a personal ID (Sweden is not far behind), later the rest of Europe will most propably follow. And I'd be most surprised if US will not make it's own twisted version of this (they tend to do that). Supposedly every person will have a key pair, so we need a good scheme for key exchange. DNSSEC might as well be this server, if key revocation problem is corrected. At this capacity one day TTL or similar cludge is not a very classy sollution. Why DNSSEC? It is already widely accepted, although not perfect. If every country and organisation selects their own commersial sollution (which are surprisingly not compatible) for key exchange, this will drag down communication security for years. You are in the position to set the standards, why not make right at the first time? Even a promise to add key revocation scheme lateron would make miracles to DNSSEC's reliability. ps. This is just feedback and my personal opinion on this matter, and I am deliverably leaving cryptographic policies out of this. -- Samuli Mattila From owner-dns-security Mon Dec 9 13:58:27 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA05876 for dns-security-outgoing; Mon, 9 Dec 1996 13:56:36 -0500 (EST) X-Sender: galvin@pop.east.commerce.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 9 Dec 1996 14:01:28 -0500 To: namedroppers@internic.net, dns-security@ex.tis.com From: "James M. Galvin" Subject: DNSSEC/DNSIND joint meeting WEDNESDAY Sender: owner-dns-security@ex.tis.com Precedence: bulk The joint meeting of the DNSSEC and DNSIND working groups has been moved to the WEDNESDAY morning slot currently occupied by DNSSEC. The joint meeting on the agenda scheduled for friday has been CANCELLED. The only item on the agenda is Secure Dynamic Update. Other topics will be permitted if time permits. See y'all there! Jim ---------------------------------------------------------------------------- James M. Galvin galvin@commerce.net CommerceNet +1 410.203.2707 3209-A Corporate Court FAX +1 410.203.2709 Ellicott City, MD 21042 http://www.commerce.net/ http://www.eff.org/blueribbon http://www.eff.org/goldkey From owner-dns-security Mon Dec 9 16:17:36 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA06464 for dns-security-outgoing; Mon, 9 Dec 1996 16:16:43 -0500 (EST) X-Sender: mccoy@hesiod.communities.com Message-Id: In-Reply-To: <199612091843.UAA04093@pallo.cs.hut.fi> References: <2.2.32.19961209171504.006832cc@popsrvr.hq.tis.com> from Olafur Gudmundsson at "Dec 9, 96 12:15:04 pm" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 9 Dec 1996 13:18:55 -0800 To: Samuli Mattila From: Jim McCoy Subject: Re:key revocation (continued) Cc: dns-security@tis.com Sender: owner-dns-security@ex.tis.com Precedence: bulk Samuli Mattila writes [regarding Key revocation...] >> Short answer, you can not !! > >As you are well aware there is a huge demand for a key exchange server >on the market. If you are implementing such a server, why make it crippled? Because the problem you are trying to solve is not the one which this initiative is working on fixing. You need to check in on the work of the PKI and SPKI working groups. DNSSEC is intended to secure the DNS namespace, not provide general public key infrastructure. jim From owner-dns-security Tue Dec 10 11:39:51 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA08243 for dns-security-outgoing; Tue, 10 Dec 1996 11:36:05 -0500 (EST) Message-Id: <2.2.32.19961210163813.00682bc8@popsrvr.hq.tis.com> X-Sender: ogud@popsrvr.hq.tis.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 10 Dec 1996 11:38:13 -0500 To: Samuli Mattila From: Olafur Gudmundsson Subject: Re: key revocation (continued) Cc: dns-security@tis.com Sender: owner-dns-security@ex.tis.com Precedence: bulk At 08:43 PM 12/9/96 +0200, you wrote: > >> Short answer, you can not !! > >As you are well aware there is a huge demand for a key exchange server on the >market. If you are implementing such a server, why make it crippled? It is not crippled, it is designed to fit within the existing DNS schema, which relies on timers for data refreshing. In the original DNSSEC draft there was an KEY revocation schema, but there where number of problems, including that it was deemed hard/impossible to implement and we where not sure that it could get rid of KEYs that had expired. Thus the working group agreed that the current expiration mechanism was sufficient for DNS purposes. ( I will take my fair credit for having the key revocation schema deleted from the draft). Instead of screeming "DNSSEC is crippled" please take a few minutes to clearly state your operating "requirements" including timing and reliabiltity. Maybe we can figure out a way to map those "requirements" so that DNS will treat the keys in a way that will give you operationally behavior that is similar to what you would get from a system that has explicit key revocation built into it. > >We at HUT are doing a research on smartcards and a pilot-version of a layer >that allows third party software to use PK-encryption for authentication, and >we use DNSSEC for key exchange. > >Soon Finnish government will pass a law that allows smartcards (CSU) as a personal ID (Sweden is not far behind), later the rest of Europe will most propably follow. And I'd be most surprised if US will not make it's own twisted version of this (they tend to do that). People here in the US are largely against ID cards, so we will see what happens > >Supposedly every person will have a key pair, so we need a good scheme for key >exchange. DNSSEC might as well be this server, if key revocation problem is >corrected. At this capacity one day TTL or similar cludge is not a very classy >sollution. KISS (keep it simple .......) If DNSSEC schema works why do you care if it is "classy" ? DNS is not designed for KEY exchange it is designed for making public data available. It is accepted that some of the data in the DNS distributed database is inconsistent. If your application can not tolerate the loose consistency of DNS, under any circumstances you should not use DNS. > >Why DNSSEC? It is already widely accepted, although not perfect. If every >country and organisation selects their own commersial sollution (which are >surprisingly not compatible) for key exchange, this will drag down >communication security for years. > >You are in the position to set the standards, why not make right at the first >time? Even a promise to add key revocation scheme lateron would make miracles >to DNSSEC's reliability. IF you or someone is willing to figure out how to do key revocation schema for DNSSEC that does not break DNS at the same time, please go ahead and submit a draft to the working group. I would be happy to help. >-- Samuli Mattila > > Olafur Gudmundsson ogud@tis.com =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Olafur Gudmundsson ogud@tis.com 3060 Washington Road 301-854-5700 Glenwood MD 21738 301-854-5363 From owner-dns-security Wed Dec 11 07:56:37 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA10144 for dns-security-outgoing; Wed, 11 Dec 1996 07:55:00 -0500 (EST) Message-ID: <32AE7AD0.2781E494@inria.fr> Date: Wed, 11 Dec 1996 10:11:44 +0100 From: Shabou Malek Organization: INRIA X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 4.1.3_U1 sun4m) MIME-Version: 1.0 To: dns-security@tis.com Subject: help for subscription Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-dns-security@ex.tis.com Precedence: bulk does any one known how to subscribe in bind-workers mailling list A+ From owner-dns-security Thu Dec 12 15:35:55 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA04848 for dns-security-outgoing; Thu, 12 Dec 1996 15:30:39 -0500 (EST) From: Samuli Mattila Message-Id: <199612122032.WAA05171@pallo.cs.hut.fi> Subject: Re: key revocation (continued) In-Reply-To: <2.2.32.19961210163813.00682bc8@popsrvr.hq.tis.com> from Olafur Gudmundsson at "Dec 10, 96 11:38:13 am" To: ogud@tis.com (Olafur Gudmundsson) Date: Thu, 12 Dec 1996 22:32:58 +0200 (EET) Cc: dns-security@tis.com, zam@iki.fi X-Mailer: ELM [version 2.4ME+ PL27 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-dns-security@ex.tis.com Precedence: bulk > ogud@tis.com (Olafur Gudmundsson) wrote: > IF you or someone is willing to figure out how to do key revocation schema > for DNSSEC that does not break DNS at the same time, please go ahead and > submit a draft to the working group. A friend of mine told me that there has been already a lot of discussion on subject "short lived certificates vs. crl" (unfortunately I have missed it). I'am not particulary forth crl's, but the scheme has various good sides. The answer to this dilemma propably lies somewhere in the middleground. In my opinion DNSSEC should also support crl, allthough it is not trivial to implement a good key revocation schema. Why? Because would make DNSSEC a more generic sollution, even to the problems yet to come. Now supposedly we are in a situation where every person has a key-pair (or a few) and we use DNSSEC for key exchange. If we use 1 day certificates, the traffic would propably prove troublesome. Let us take a trusted 3rd party as a key rovocation server (KRS), to whom all the threathened keys are reported to. KRS would be subject to all revocation queries (atleast from DNSSEC). Instead of making 1 days certificates the DNSSEC would now sign keys for one month. DNSSEC would also be obligated to make a revocation-list-query to KRS once per day, where it asks for latest ( 1 month ) revocation list. This list should then be stored and cache- and key list consistency checked accordingly. DNSSEC could also pass this revocation list forth on a clients query. Wether a system chooses to use this revocation list scheme is entirely up to it, nevertheless this option should be available. The optimum time values (as 1 day or 1 month here) should be calculated by simulation. As you may realise, I really didn't give this a much thought (due lack of free time), but the sollution might be something like this. -- Samuli Mattila From owner-dns-security Fri Dec 13 12:15:37 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA01021 for dns-security-outgoing; Fri, 13 Dec 1996 12:15:10 -0500 (EST) Message-ID: <32B1918F.446B9B3D@inria.fr> Date: Fri, 13 Dec 1996 18:25:35 +0100 From: Shabou Malek Organization: INRIA X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 4.1.3_U1 sun4m) MIME-Version: 1.0 To: dns-security@tis.com Subject: dynamic update Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-dns-security@ex.tis.com Precedence: bulk i have tried to compile secdns with ALLOW_UPDATE option but i didn'i succed. an error occures in res_mkquery saying: res_mkquery.c:200: `UPDATEM' undeclared (first use this function) A+ From owner-dns-security Fri Dec 13 13:14:06 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA02186 for dns-security-outgoing; Fri, 13 Dec 1996 13:12:26 -0500 (EST) Message-Id: Date: Fri, 13 Dec 96 10:14 PST From: randy@psg.com (Randy Bush) To: namedroppers , dnssec Subject: draft minutes for Joint DNSSEC/DNSIND WG Meeting Sender: owner-dns-security@ex.tis.com Precedence: bulk The DNSSEC and DNSIND working groups met jointly. The agenda was as follows: Introductions Implementation Status Documents draft-ietf-dnsind-dynDNS-11.txt draft-ietf-dnssec-update-02.txt Although it had been announced on the mailing list, Trusted Information Systems (TIS) announced the global (i.e. exportable!) availability of their DNSSEC implementation; it has been approved for export in source code form. Note, the source code does not include the cryptographic functions. These are available separately in the US by acquiring RSAREF and outside the US by acquiring RSAEURO. John Gilmore was thanked for his expertise and advice in assisting TIS during the export application process. TIS reported that their implementation of DNSSEC is currently being integrated with the latest version of bind. The completion of this will permit bind to be distributed with support for secure DNS. In parallel they have begun implementing the secure dynamic update specifications. John Gilmore reported that support for SIG and KEY records is in the current production release of BIND (4.9.5). This support allows the RR's to be published and queried, but does no crypto validation. You can generate these records using the offline signer in TIS's beta release. The same support, plus additional support for NXT records is already in BIND 8.x, and I am actively working on merging the rest of TIS's DNSSEC into it. Two of the root/com servers are running 4.9.5 and could publish keys and signatures (the rest will have to upgrade to make it possible for the IANA or the InterNIC to publish keys or signature). Paul Vixie reported that the latest version of bind currently supports the latest version of dynamic update without security. In closing, the working group was asked if there were any serious technical objections to the advancement of the two principal documents before them. The dynamic udpate document (dnsind-dynDNS) is in IETF Last Call pending the advancement of the secure dynamic update document (dnssec-update). A technical issue was raised in the secure dynamic update draft (dnssec-update) as to the incompleteness of the specification of reverse key lookups. It was decided to defer the issue to the mailing list and to move that section of the document to a separate document, likely after advancement. With the one editorial change it was the consensus of the working groups to submit the secure dynamic update draft (dnssec-update) to the IESG to be considered for publication as a Proposed Standard. All discussion of future work of the working groups was deferred to their respective mailing lists and the meeting adjourned. From owner-dns-security Fri Dec 13 13:26:14 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA02486 for dns-security-outgoing; Fri, 13 Dec 1996 13:26:06 -0500 (EST) X-Sender: galvin@pop.east.commerce.net (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 13 Dec 1996 12:42:41 -0500 To: namedroppers@internic.net, dns-security@tis.com From: "James M. Galvin" Subject: draft Joint DNSSEC/DNSIND Meeting Minutes Sender: owner-dns-security@ex.tis.com Precedence: bulk Enclosed below are the draft minutes for our joint meeting. Comments, corrections, and questions are solicited until wednesday, December 18, at which time they will be submitted for inclusion in the proceedings. Enjoy. -------- The DNSSEC and DNSIND working groups met jointly on wednesday, December 11. The agenda was as follows: Introductions Implementation Status Documents draft-ietf-dnsind-dynDNS-11.txt draft-ietf-dnssec-update-02.txt Although it has been announced on the mailing list for some time, Trusted Information Systems (TIS) announced the global availability of their DNSSEC implementation; it has been approved for export in source code form. Note, the source code does not include the cryptographic functions. These are available separately in the US by acquiring RSAREF and outside the US by acquiring RSAEURO. John Gilmore was thanked for his expertise and advice in assisting TIS during the export application process. TIS reported that their implementation of DNSSEC is currently being integrated with the latest version of bind. The completion of this will permit bind to be distributed with support for secure DNS. In parallel they have begun implementing the secure dynamic update specifications. John Gilmore reported that support for SIG and KEY records is in the current production release of BIND (4.9.5). This support allows the RR's to be published and queried, but does no cryptographic validation. You can generate these records using the offline signer in TIS's beta release. The same support, plus additional support for NXT records is already in BIND 8.x, and he is actively working on merging the rest of TIS's DNSSEC into it. In addition, two of the root/com servers are running 4.9.5 and could publish keys and signatures (the rest will have to upgrade to make it possible for the IANA or the InterNIC to publish keys or signature). Paul Vixie reported that the latest version of bind currently supports the latest version of dynamic update without security. In closing, the working group was asked if there were any serious technical objections to the advancement of the two principal documents before them. The dynamic udpate document (dnsind-dynDNS) is in IETF Last Call pending the advancement of the secure dynamic update document (dnssec-update). A technical issue was raised in the secure dynamic update draft (dnssec-update) as to the incompleteness of the specification of reverse key lookups. It was decided to defer the issue to the mailing list and to move that section of the document to a separate document. With the one editorial change it was the consensus of the working groups to submit the secure dynamic update draft (dnssec-update) to the IESG to be considered for publication as a Proposed Standard. All discussion of future work of the working groups was deferred to their respective mailing lists and the meeting adjourned. ---------------------------------------------------------------------------- James M. Galvin galvin@commerce.net CommerceNet +1 410.203.2707 3209-A Corporate Court FAX +1 410.203.2709 Ellicott City, MD 21042 http://www.commerce.net/ http://www.eff.org/blueribbon http://www.eff.org/goldkey From owner-dns-security Sat Dec 14 03:14:07 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA19665 for dns-security-outgoing; Sat, 14 Dec 1996 03:12:18 -0500 (EST) Date: Sat, 14 Dec 1996 00:15:02 -0800 (PST) X-btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: dns-security@tis.com From: paul@vix.com (Paul A Vixie) Subject: Re: dynamic update Organization: Vixie Enterprises Message-ID: References: <32B1918F.446B9B3D@inria.fr> NNTP-Posting-Host: wisdom.home.vix.com In-reply-to: malek.shabou@inria.fr's message of 13 Dec 1996 10:05:32 -0800 Xref: vixie local.mail.dns.security:473 Sender: owner-dns-security@ex.tis.com Precedence: bulk ALLOW_UPDATE is old stuff, unrelated to DNS UPDATE. It's gone in BIND 8.1. -- Paul Vixie La Honda, CA "Illegitimibus non carborundum." pacbell!vixie!paul From owner-dns-security Wed Dec 18 03:33:22 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA04327 for dns-security-outgoing; Wed, 18 Dec 1996 03:29:09 -0500 (EST) From: Masataka Ohta Message-Id: <199612180830.RAA08722@necom830.hpcl.titech.ac.jp> Subject: Re: draft Joint DNSSEC/DNSIND Meeting Minutes To: galvin@commerce.net (James M. Galvin) Date: Wed, 18 Dec 96 17:29:56 JST Cc: namedroppers@internic.net, dns-security@tis.com In-Reply-To: ; from "James M. Galvin" at Dec 13, 96 12:42 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-dns-security@ex.tis.com Precedence: bulk James M. Galvin; > Enclosed below are the draft minutes for our joint meeting. Comments, > corrections, and questions are solicited until wednesday, December 18, at > which time they will be submitted for inclusion in the proceedings. > A technical issue was raised in the secure dynamic update draft > (dnssec-update) as to the incompleteness of the specification of reverse > key lookups. Wrong. The issue is not on some imcomplete specification. The issue is purely technical that it is impossible to perform reverse DNS lookups with hashed values. The issue is a serious technical defect. > It was decided to defer the issue to the mailing list and to > move that section of the document to a separate document. > > With the one editorial change it was the consensus of the working groups to > submit the secure dynamic update draft (dnssec-update) to the IESG to be > considered for publication as a Proposed Standard. I reconsider your proposal (as you gave the WGs only 5 seconds at the meeting to consider your proposal, it is difficult to call your proposal WG consensus). I now think that, as the issue raised is serious technical defect, it is impossible to call the change "one editorial change" and that one more WG last call is inevitable after the change. Masataka Ohta From owner-dns-security Wed Dec 18 21:36:47 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA11363 for dns-security-outgoing; Wed, 18 Dec 1996 21:35:04 -0500 (EST) X-Sender: galvin@pop.east.commerce.net Message-Id: In-Reply-To: <199612180830.RAA08722@necom830.hpcl.titech.ac.jp> References: ; from "James M. Galvin" at Dec 13, 96 12:42 pm Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 18 Dec 1996 21:38:51 -0500 To: Masataka Ohta From: "James M. Galvin" Subject: Re: draft Joint DNSSEC/DNSIND Meeting Minutes Cc: namedroppers@internic.net, dns-security@tis.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id VAA11360 Sender: owner-dns-security@ex.tis.com Precedence: bulk At 3:29 AM -0500 12/18/96, Masataka Ohta wrote: >> A technical issue was raised in the secure dynamic update draft >> (dnssec-update) as to the incompleteness of the specification of reverse >> key lookups. > >Wrong. The issue is not on some imcomplete specification. Please tell me what words you want me to use and I'll do that. >> With the one editorial change it was the consensus of the working groups to >> submit the secure dynamic update draft (dnssec-update) to the IESG to be >> considered for publication as a Proposed Standard. > >I reconsider your proposal (as you gave the WGs only 5 seconds at the >meeting to consider your proposal, it is difficult to call your proposal >WG consensus). > >I now think that, as the issue raised is serious technical defect, >it is impossible to call the change "one editorial change" and >that one more WG last call is inevitable after the change. Whether or not the issue is a "serious technical defect", it is an editorial change to remove it from the document and thus exclude it from consideration. It would be a technical change only if the removal of the functionality resulted in a protocol that could not perform correctly. Jim ---------------------------------------------------------------------------- James M. Galvin galvin@commerce.net CommerceNet +1 410.203.2707 3209-A Corporate Court FAX +1 410.203.2709 Ellicott City, MD 21042 http://www.commerce.net/ http://www.eff.org/blueribbon http://www.eff.org/goldkey From owner-dns-security Wed Dec 18 22:32:15 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA11658 for dns-security-outgoing; Wed, 18 Dec 1996 22:32:08 -0500 (EST) From: Masataka Ohta Message-Id: <199612190333.MAA10948@necom830.hpcl.titech.ac.jp> Subject: Re: draft Joint DNSSEC/DNSIND Meeting Minutes To: galvin@east.commerce.net (James M. Galvin) Date: Thu, 19 Dec 96 12:33:01 JST Cc: mohta@necom830.hpcl.titech.ac.jp, namedroppers@internic.net, dns-security@tis.com In-Reply-To: ; from "James M. Galvin" at Dec 18, 96 9:38 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-dns-security@ex.tis.com Precedence: bulk > >> A technical issue was raised in the secure dynamic update draft > >> (dnssec-update) as to the incompleteness of the specification of reverse > >> key lookups. > > > >Wrong. The issue is not on some imcomplete specification. > > Please tell me what words you want me to use and I'll do that. It should be: A serious technical flaw was found in the secure dynamic update draft (dnssec-update) as to the impossibility of hierarchical lookup of reverse key domain with *HASHED* key value. Though the DNSSEC chair proposed an extensive change to the draft, not enough time was assigned for the discussion and there was no consensus formed. > >> With the one editorial change it was the consensus of the working groups = > to > >> submit the secure dynamic update draft (dnssec-update) to the IESG to be > >> considered for publication as a Proposed Standard. > > > >I reconsider your proposal (as you gave the WGs only 5 seconds at the > >meeting to consider your proposal, it is difficult to call your proposal > >WG consensus). > > > >I now think that, as the issue raised is serious technical defect, > >it is impossible to call the change "one editorial change" and > >that one more WG last call is inevitable after the change. > > Whether or not the issue is a "serious technical defect", it is an > editorial change to remove it from the document and thus exclude it from > consideration. Are you joking? Any change is, of course, editorial. The problem is whether it is a simple and pure editorial change or not. Reconstruction of the document into two is already not simple. And, as one of the two can not proceed as is, it is a techical change. > It would be a technical change only if the removal of the functionality > resulted in a protocol that could not perform correctly. Not. The removal of some functionality is always a technical change. And, the question to be asked is that whether the removal, the technical change, needs some othere change for the entire specificaiton to make the specification work correctly, efficiently, meaningfully or ... Masataka Ohta From owner-dns-security Thu Dec 19 04:15:49 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA13280 for dns-security-outgoing; Thu, 19 Dec 1996 04:13:35 -0500 (EST) From: Masataka Ohta Message-Id: <199612190914.SAA11550@necom830.hpcl.titech.ac.jp> Subject: Re: draft Joint DNSSEC/DNSIND Meeting Minutes To: sra@epilogue.com (Rob Austein) Date: Thu, 19 Dec 96 18:13:51 JST Cc: mohta@necom830.hpcl.titech.ac.jp, galvin@east.commerce.net, namedroppers@internic.net, dns-security@tis.com, sra@epilogue.com In-Reply-To: <9612190351.aa06085@rurha-pente.epilogue.com>; from "Rob Austein" at Dec 19, 96 3:51 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-dns-security@ex.tis.com Precedence: bulk Rob; > Sorry, it wasn't James that proposed changing the draft, it was me. You personally communicated with several people at the front chairs in very weak voice and it's James who said it to the WG. > As I recall, you had two objections to the secure update draft: > > 1) It's much more complicated than you think is necessary. You misunderstand my first point. But, it's OK. > 2) The reverse key mapping tree. You're right about this being > flawed, Then, how could James say that: James> A technical issue was raised in the secure dynamic update draft James> (dnssec-update) as to the incompleteness of the specification of reverse James> key lookups. ???? The draft minute above means that your personal opinion was not understood by James and the WG. Hence, there is no WG consensus. > but as Donald pointed out, it's not an essential part of > the secure update mechanism, in fact it's totally unrelated and > should have been in a separate document all along. Did he? If it is so, I'm afraid Donald is making fool of himself that he can't write a proper document. That's a serious problem. And, no one can say that the resulting separated document can be good enough so that another round is absolutely necessary. So, if Donald actually said "should have been in a separate document all along", I'd like to propose replace the editor of the draft before making ANY editorial change. Anyway, there was not enough time given to judge whether the Donald's point was valid. Hence, there is no WG consensus. > At this point, I think the urgent need is to get some real field > experience with these protocols. That's not a valid reason to break procedural rules. > If they're flawed, I have faith that > the users (and the press, et al) will tell us so, perhaps with some > help from you. If? Haven't we agreed that it flawed? > But we've been designing this stuff for four years. So, we can wait for another four years (actually, it's less than four weeks, I'm AFRAID). > It's time to kick the protocols into the pool and see if they float. Let's move forward to throw flawed protocols away. Masataka Ohta From owner-dns-security Thu Dec 19 04:25:07 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA13335 for dns-security-outgoing; Thu, 19 Dec 1996 04:25:05 -0500 (EST) From: Masataka Ohta Message-Id: <199612190926.SAA11581@necom830.hpcl.titech.ac.jp> Subject: Re: key revocation (continued) To: ogud@tis.com (Olafur Gudmundsson) Date: Thu, 19 Dec 96 18:26:02 JST Cc: zam@niksula.hut.fi, dns-security@tis.com In-Reply-To: <2.2.32.19961210163813.00682bc8@popsrvr.hq.tis.com>; from "Olafur Gudmundsson" at Dec 10, 96 11:38 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-dns-security@ex.tis.com Precedence: bulk > >> Short answer, you can not !! > > > >As you are well aware there is a huge demand for a key exchange server on > the >market. If you are implementing such a server, why make it crippled? > > It is not crippled, It is crippled. > it is designed to fit within the existing DNS schema, > which relies on timers for data refreshing. The existing DNS schema is friendly to key revocation. > In the original DNSSEC draft It is the original DNSSEC draft which does not fit within the existing DNs schema, which is all the source of problems. > there was an KEY revocation schema, but there > where number of problems, including that it was deemed hard/impossible to > implement > and we where not sure that it could get rid of KEYs that had expired. It is possible, easy and simple to have secure DNS with key revocation capability. Masataka Ohta From owner-dns-security Thu Dec 19 07:53:03 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA14575 for dns-security-outgoing; Thu, 19 Dec 1996 07:51:06 -0500 (EST) To: Masataka Ohta cc: "James M. Galvin" , namedroppers@internic.net, dns-security@tis.com, sra@epilogue.com Subject: Re: draft Joint DNSSEC/DNSIND Meeting Minutes In-Reply-To: Message from Masataka Ohta dated "Thu, 19 Dec 96 12:33:01 +0200" <199612190333.MAA10948@necom830.hpcl.titech.ac.jp> References: <199612190333.MAA10948@necom830.hpcl.titech.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 19 Dec 1996 03:51:02 -0500 From: Rob Austein Message-ID: <9612190351.aa06085@rurha-pente.epilogue.com> Sender: owner-dns-security@ex.tis.com Precedence: bulk Ohta-san, Sorry, it wasn't James that proposed changing the draft, it was me. As I recall, you had two objections to the secure update draft: 1) It's much more complicated than you think is necessary. Not a surprising objection, you've diligently made essentially the same claim about the entire Eastlake-Kaufman DNSSEC architecture ever since it was proposed. You may even be right, but the WG came to "rough" consensus (meaning everybody but you either agreed or stood mute) quite some time ago, so this issue is basicly moot unless implementation and/or deployment experience proves your case. 2) The reverse key mapping tree. You're right about this being flawed, but as Donald pointed out, it's not an essential part of the secure update mechanism, in fact it's totally unrelated and should have been in a separate document all along. Hence my proposal, to move the reverse key mapping stuff into its own document. Unless you're claiming that the reverse mapping tree is an inseparable part of the secure update mechanism, I think that James is correct in calling this an "editorial change". At this point, I think the urgent need is to get some real field experience with these protocols. If they're flawed, I have faith that the users (and the press, et al) will tell us so, perhaps with some help from you. But we've been designing this stuff for four years. Another round of design at this point is unlikely to improve anything. It's time to kick the protocols into the pool and see if they float. --Rob From owner-dns-security Thu Dec 19 09:53:58 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA15402 for dns-security-outgoing; Thu, 19 Dec 1996 09:52:21 -0500 (EST) Date: Thu, 19 Dec 1996 09:50:06 -0500 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9612190950.ZM12623@seawind.bellcore.com> In-Reply-To: Masataka Ohta "Re: key revocation (continued)" (Dec 19, 6:26pm) References: <199612190926.SAA11581@necom830.hpcl.titech.ac.jp> X-Mailer: Z-Mail (3.2.1 10oct95) To: Masataka Ohta Subject: Re: key revocation (continued) Cc: dns-security@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-dns-security@ex.tis.com Precedence: bulk >> it is designed to fit within the existing DNS schema, >> which relies on timers for data refreshing. > >The existing DNS schema is friendly to key revocation. Well, let me cast a voice of support for the existing draft. I have some experience with the key revocation problem, based on our attempt to make X.509 key revocation work in the European Password project. To put it briefly, the revocation list approach is a lazy dog. It is a dog because it impose extra treatment each time you check a key. You have to go fetch the revocation list, check that it is the last one, etc. The impact on performances is by no means small. It is a lazy dog because it just cannot be guaranteed to work. There are umpteen denial of service type attacks that can be mounted so you will not have access to the most recent revocation list. You will then be faced with a choice to either take risks or wait forever. On the other hand, the current DNS security approach allows you to contain the risk by limiting the time validity of a given key. Managers will be aware, precisely because there is no revocation mechanism, that validty dates should be left short. That is, IMHO, a good design. -- Christian Huitema From owner-dns-security Thu Dec 19 10:42:01 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA15737 for dns-security-outgoing; Thu, 19 Dec 1996 10:41:44 -0500 (EST) Message-Id: <199612191544.KAA00110@itivax.fv.com> X-Mailer: exmh version 1.6.9 8/22/96 To: namedroppers@internic.net, dns-security@tis.com From: Steve Simmons Subject: Re: draft Joint DNSSEC/DNSIND Meeting Minutes Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 19 Dec 1996 10:44:30 -0500 Sender: owner-dns-security@ex.tis.com Precedence: bulk While I realize that concensus != voting, I'm nonetheless going to break my silence and vote for the separation of the issues. As someone said, it's time to throw the baby into the pool and see if it swims. From owner-dns-security Thu Dec 19 11:33:32 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA16070 for dns-security-outgoing; Thu, 19 Dec 1996 11:32:46 -0500 (EST) X-Sender: lewis@pop.hq.tis.com Message-Id: In-Reply-To: <199612191544.KAA00110@itivax.fv.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 18 Dec 1996 11:39:55 -0500 To: namedroppers@internic.net, dns-security@tis.com From: Edward Lewis Subject: Stirring the fire of consensus (was Re: draft...Minutes) Cc: lewis@tis.com Sender: owner-dns-security@ex.tis.com Precedence: bulk At 10:44 AM -0500 12/19/96, Steve Simmons wrote: >my silence and vote for the separation of the issues. As someone said, >it's time to throw the baby into the pool and see if it swims. Skimming RFC2026, Proposed Standards are stable, have made design choices, been reviewed, and are deemed valuable. IMHO these drafts meet these criteria. That RFC also goes on to say that further experience may result in a change or retraction of the spec. As an implementor of this already, I anticipate some changes. The drafts are not ready for Draft Standard - there aren't multiple interoperable implementations yet - much less Internet Standards. I can't see how anyone would want to delay moving the documents forward. Even Masataka Ohta! If there is a weakness in the specification, it will become more apparent as independent folks try to implement and deploy it. Relax - this only the first step towards a casting in concrete. Currently I am implementing in a near vacuum, and I'm not smart enough to do this. (Just myself and one other at this location, I only hear rumors of others working on the code too.) Ohta has already noted that: > On Tue, 26 Nov 1996, Masataka Ohta wrote: > > I'm afraid you misunderstand the Internet. Obviously he would support getting far more knowledgeable folks than I to join in. I welcome others to try their hand at the implementation - something a Proposed Standard RFC would presumably encourage. I'd certainly like to hear other's interpretation of the details in the specification. BTW, I do include Ohta's comment about me in total sarcasm. I do so understand all of the Internet: OSI, Ada, *and* Appletalk! ;) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: 301-854-5794 Email: lewis@tis.com From owner-dns-security Thu Dec 19 19:18:34 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA18723 for dns-security-outgoing; Thu, 19 Dec 1996 19:15:49 -0500 (EST) From: Masataka Ohta Message-Id: <199612200015.JAA13083@necom830.hpcl.titech.ac.jp> Subject: Re: draft Joint DNSSEC/DNSIND Meeting Minutes To: scs@aa.fv.com (Steve Simmons) Date: Fri, 20 Dec 96 9:14:56 JST Cc: namedroppers@internic.net, dns-security@tis.com In-Reply-To: <199612191544.KAA00110@itivax.fv.com>; from "Steve Simmons" at Dec 19, 96 10:44 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-dns-security@ex.tis.com Precedence: bulk > While I realize that concensus != voting, Whichever you might want, we need the WG thoroughly understand the issue. > I'm nonetheless going to break > my silence and vote for the separation of the issues. For the separation of the issues? So far, there is no one against it. But, the question is whether THE TECHNICAL CHANGE is possible and 1still keeps the protocol(s) correct, efficient, satisfiable, meaningful, operational etc. No understanding, no voting nor consensus. Right? And you are the living evidence second to James, the chair, that there is no understanding. Masataka Ohta From owner-dns-security Thu Dec 19 19:23:34 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA18769 for dns-security-outgoing; Thu, 19 Dec 1996 19:22:18 -0500 (EST) From: Masataka Ohta Message-Id: <199612200023.JAA13127@necom830.hpcl.titech.ac.jp> Subject: Re: key revocation (continued) To: huitema@bellcore.com (Christian Huitema) Date: Fri, 20 Dec 96 9:23:12 JST Cc: mohta@necom830.hpcl.titech.ac.jp, dns-security@tis.com In-Reply-To: <9612190950.ZM12623@seawind.bellcore.com>; from "Christian Huitema" at Dec 19, 96 9:50 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-dns-security@ex.tis.com Precedence: bulk Cristian; > >> it is designed to fit within the existing DNS schema, > >> which relies on timers for data refreshing. > > > >The existing DNS schema is friendly to key revocation. > Well, let me cast a voice of support for the existing draft. I have some > experience with the key revocation problem, based on our attempt to make > X.509 key revocation work in the European Password project. To put it > briefly, the revocation list approach is a lazy dog. It seems to me that you are assuming that X.509 has done its job perfectly well. You also assumes that DNS is not a lazy dog. Are you so sure that your assumptions are sound? > It is a dog because it impose extra treatment each time you check a key. > You have to go fetch the revocation list, check that it is the last one, > etc. The impact on performances is by no means small. What's wrong with you is that you "check that it is the last one". What we need to check, according to the lazy nature of "THE EXISTING DNS SCHEMA" is that the revocation list is "reasonably recent". And, "how recent" is determined zone by zone. That's all. Still, it's better than frequently resigining everything. > It is a lazy dog because it just cannot be guaranteed to work. When dealing with a lazy dog such as DNS, be lazy, check lazily. That's the exsiting DNS schema. > On the other hand, the current DNS security approach allows you to contain > the risk by limiting the time validity of a given key. Managers will be > aware, precisely because there is no revocation mechanism, that validty > dates should be left short. That is, IMHO, a good design. The problem without CRL is that resigning must be so frequent, which is an operational problem. It is not realistic to re-sign all the zones under ".com" everyday. Masataka Ohta From owner-dns-security Sat Dec 21 02:44:33 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA28938 for dns-security-outgoing; Sat, 21 Dec 1996 02:40:42 -0500 (EST) From: Masataka Ohta Message-Id: <199612210742.QAA01170@necom830.hpcl.titech.ac.jp> Subject: Re: Stirring the fire of consensus (was Re: draft...Minutes) To: lewis@tis.com (Edward Lewis) Date: Sat, 21 Dec 96 16:41:45 JST Cc: namedroppers@internic.net, dns-security@tis.com, lewis@tis.com In-Reply-To: ; from "Edward Lewis" at Dec 18, 96 11:39 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-dns-security@ex.tis.com Precedence: bulk Edward; > I can't see how anyone would want to delay moving the documents forward. > Even Masataka Ohta! The forward direction for bad specifications are, of course, disposal of them. Masataka Ohta From owner-dns-security Tue Dec 24 10:33:35 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA20894 for dns-security-outgoing; Tue, 24 Dec 1996 10:31:27 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce cc: dns-security@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnssec-update-03.txt Date: Tue, 24 Dec 1996 09:47:15 -0500 Message-ID: <9612240947.aa07239@ietf.org> Sender: owner-dns-security@ex.tis.com Precedence: bulk --NextPart A Revised 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 : Secure Domain Name System Dynamic Update Author(s) : D. Eastlake Filename : draft-ietf-dnssec-update-03.txt Pages : 13 Date : 12/23/1996 Domain Name System (DNS) protocol extensions have been defined to authenticate the data in DNS and provide key distribution services (draft-ietf-dnssec-secext-10.txt). DNS Dynamic Update operations have also been defined (draft-ietf-dnsind-dynDNS-*.txt>, but without a detailed description of security for the update operation. This draft describes how to use DNSSEC digital signatures covering requests and data to secure updates and restrict updates to those authorized to perform them as indicated by the updater's possession of cryptographic keys. 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-update-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-update-03.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o 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-update-03.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: <19961223140142.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-update-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-update-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961223140142.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dns-security Tue Dec 24 12:02:51 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA21284 for dns-security-outgoing; Tue, 24 Dec 1996 12:01:41 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <9612190950.ZM12623@seawind.bellcore.com> References: Masataka Ohta "Re: key revocation (continued)" (Dec 19, 6:26pm) <199612190926.SAA11581@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 24 Dec 1996 12:03:20 -0500 To: huitema@bellcore.com (Christian Huitema) From: Stephen Kent Subject: Re: key revocation (continued) Cc: dns-security@tis.com Sender: owner-dns-security@ex.tis.com Precedence: bulk Christian, I think you overstate the case against CRLs. With intelligent caching (using the next issue date contained in a CRL), one can probably have adequate confidence in the recency of a CRL for many applications without constantly fetching CRLs. Your characterization of the shortcomings of CRLS is accurate for the worst case, but the Internet works well with many solutions that would be horrible in worsty case scenarios. Note that the alternative, short cert lifetimes, trades frequent fetching of CRLs for frequent fetching of certs. Since a given CRL typically covers many certs, this is not necessarily a great tradeoff in practice. Moreover, the model of a short lifetime certs, can be implemented in X.509, on a per cert basis. So, if a CA believes that a particular group of certificates deserve to have short validity intervals for use in an access control (vs. non-repudiation) context, one can make the system work that way. Steve