From bmanning@ISI.EDU Wed Jan 15 21:43:52 2003 From: bmanning@ISI.EDU (Bill Manning) Date: Wed, 15 Jan 2003 13:43:52 -0800 (PST) Subject: [vet-DS] workshops In-Reply-To: <200212272314.gBRNEcNW032602@sandelman.ottawa.on.ca> from Michael Richardson at "Dec 27, 2 06:14:38 pm" Message-ID: <200301152143.h0FLhqk29676@boreas.isi.edu> % There was talk in Atlanta about having another workshop either before % or after IETF56. i.e. in March. I generally prefer to give my family % as much advance notice as possible (not to mention the airlines are cheaper) % of what is going on. % % Bill, can we decide: % 1) if we are having one. % 2) more clearly, what we will be doing at it. % 3) if it should be before or after the IETF. % % % My comments: % 1) yes, we should. % % 2) I think that we should do what Bill initially wanted, which was to % setup a test bed that is *out there*. Doing it over IPv6 is fine with % me, but we need a lot more advance coordination of things. % % 3) I do not have a problem with it being before. In fact, we might just % find it easiest to help setup the network ourselves so that we can use % it. For that reason, arrival on Thursday, with work on Friday/Saturday % might be best. % I think that keeping the IETF network around longer is harder, than % getting it alive earlier. % % {I wonder if some of the lists might be renamed. I have: % % dnssec - deployment issues for .nl % dnssec \ not sure how these differ % dnssec / anymore. % } okydoky. 1) I've put in for a room, in venue, for 13-15 march 2) what... kind of depends on the fate of DS, but I expect to try and nail down participants that are willing to do more with the persistant v6 testbed. If so, much can be done prior to the actual mtg. 3) before... (I'm expecting to be coming back from Oz on the 12th) wrt list rename... the dnssec@isi.edu is primarly for coordinating of public w/s activities. dnssec@cafax.se seems to have a different charter. --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From olaf@ripe.net Thu Jan 16 09:33:10 2003 From: olaf@ripe.net (Olaf M. Kolkman) Date: Thu, 16 Jan 2003 10:33:10 +0100 Subject: [vet-DS] workshops In-Reply-To: <200301152143.h0FLhqk29676@boreas.isi.edu> References: <200212272314.gBRNEcNW032602@sandelman.ottawa.on.ca> <200301152143.h0FLhqk29676@boreas.isi.edu> Message-ID: <20030116103310.3910deeb.olaf@ripe.net> > > 1) I've put in for a room, in venue, for 13-15 march > 2) what... kind of depends on the fate of DS, but I expect > to try and nail down participants that are willing to > do more with the persistant v6 testbed. If so, much > can be done prior to the actual mtg. I am willing (actually eager :-) to partake in a workshop. But joining a persistent testbeb, with a production domain, under the test-root is something that I am hesitant about. The main reason is that I think that except for the added security the two namespaces (the one from the test and the IANA root) should be exactly identical. I am afraid that I do not have the resources to guarantee consistency in the long run. That said, I can off course participate with non-production, i.e. a toy forward domain. Let me know if I am welcome so I can start arranging travel. > 3) before... (I'm expecting to be coming back from Oz on the > 12th) > See you soon... --Olaf --------------------------------------------| Olaf M. Kolkman | www.ripe.net/disi From bmanning@ISI.EDU Thu Jan 16 14:44:00 2003 From: bmanning@ISI.EDU (Bill Manning) Date: Thu, 16 Jan 2003 06:44:00 -0800 (PST) Subject: [vet-DS] workshops In-Reply-To: <20030116103310.3910deeb.olaf@ripe.net> from "Olaf M. Kolkman" at "Jan 16, 3 10:33:10 am" Message-ID: <200301161444.h0GEi0w13834@boreas.isi.edu> % % > % > 1) I've put in for a room, in venue, for 13-15 march % > 2) what... kind of depends on the fate of DS, but I expect % > to try and nail down participants that are willing to % > do more with the persistant v6 testbed. If so, much % > can be done prior to the actual mtg. % % I am willing (actually eager :-) to partake in a workshop. But joining % a persistent testbeb, with a production domain, under the test-root is % something that I am hesitant about. The main reason is that I think % that except for the added security the two namespaces (the one from % the test and the IANA root) should be exactly identical. I am afraid % that I do not have the resources to guarantee consistency in the long % run. % % That said, I can off course participate with non-production, i.e. a % toy forward domain. % % Let me know if I am welcome so I can start arranging travel. of course you are welcome. let me spend a couple of hours constructing a testbed structure that can be de-linked from the live space. we'll need this anyway for other workshops. % % % > 3) before... (I'm expecting to be coming back from Oz on the % > 12th) % > % % See you soon... % % % --Olaf % % --------------------------------------------| Olaf M. Kolkman % | www.ripe.net/disi % -- --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From brunner@nic-naa.net Thu Jan 16 15:35:22 2003 From: brunner@nic-naa.net (Eric Brunner-Williams in Portland Maine) Date: Thu, 16 Jan 2003 10:35:22 -0500 Subject: [vet-DS] workshops In-Reply-To: Your message of "Thu, 16 Jan 2003 06:44:00 PST." <200301161444.h0GEi0w13834@boreas.isi.edu> Message-ID: <200301161535.h0GFZMZ2016695@nic-naa.net> what is the DS snapshot this time? 20021113? From bmanning@ISI.EDU Thu Jan 16 16:23:39 2003 From: bmanning@ISI.EDU (Bill Manning) Date: Thu, 16 Jan 2003 08:23:39 -0800 (PST) Subject: [vet-DS] workshops In-Reply-To: <200301161535.h0GFZMZ2016695@nic-naa.net> from Eric Brunner-Williams in Portland Maine at "Jan 16, 3 10:35:22 am" Message-ID: <200301161623.h0GGNds16887@boreas.isi.edu> % what is the DS snapshot this time? 20021113? the most recent I have is: bind-9.3.0s20021217.tar.gz --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From mcr@sandelman.ottawa.on.ca Thu Jan 16 19:14:19 2003 From: mcr@sandelman.ottawa.on.ca (Michael Richardson) Date: Thu, 16 Jan 2003 14:14:19 -0500 Subject: [vet-DS] workshops In-Reply-To: Your message of "Wed, 15 Jan 2003 13:43:52 PST." <200301152143.h0FLhqk29676@boreas.isi.edu> Message-ID: <200301161914.h0GJEL0q010896@marajade.sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Bill" == Bill Manning writes: Bill> % Bill, can we decide: Bill> % 1) if we are having one. Bill> % 2) more clearly, what we will be doing at it. Bill> % 3) if it should be before or after the IETF. Bill> okydoky. Bill> 1) I've put in for a room, in venue, for 13-15 march Excellent. Bill> 2) what... kind of depends on the fate of DS, but I expect Bill> to try and nail down participants that are willing to Bill> do more with the persistant v6 testbed. If so, much Bill> can be done prior to the actual mtg. Agreed. I have poor v6 connectivity (i.e. 2002: only) at this time, since IPv6 died at crc.ca. I am hoping to fix that soon. I have zones alive that are signed and are available via IPv6. I thought that were were going to have to sign arpa. already. I think that we can avoid the grandparent problem for the moment now that we know about it. Bill> 3) before... (I'm expecting to be coming back from Oz on the Bill> 12th) Bill> wrt list rename... the dnssec@isi.edu is primarly for coordinating of public Bill> w/s activities. dnssec@cafax.se seems to have a different charter. May I suggest dnssec@isi.edu be renamed to dnssec-workshops@isi.edu or dnssec-testbed@isi.edu or something? ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPicEiIqHRg3pndX9AQEXUgQAi6BhMN6zxI3Zfsqb0jI+Dnu1uqW4amhY GcjqNDRwj9yAPFTjMXkH6naSJhmvZy7Gi+WJmLuJsAfW0hi9ak3AWsqqmKmB7nDj 0fYT1/Wfg0xPZw4k8iUXBHX5GRGM7Vqt1BFJNieswuQyiJSS/ZSJKUpffYdEKYae uBlhyGMcXxI= =6RvS -----END PGP SIGNATURE----- From scottr@antd.nist.gov Thu Jan 16 20:05:24 2003 From: scottr@antd.nist.gov (Scott Rose) Date: Thu, 16 Jan 2003 15:05:24 -0500 Subject: [vet-DS] workshops References: <200301161914.h0GJEL0q010896@marajade.sandelman.ottawa.on.ca> Message-ID: <005d01c2bd9a$9b5e58a0$b9370681@antd.nist.gov> > > Bill> wrt list rename... the dnssec@isi.edu is primarly for coordinating of public > Bill> w/s activities. dnssec@cafax.se seems to have a different charter. > > May I suggest dnssec@isi.edu be renamed to dnssec-workshops@isi.edu or > dnssec-testbed@isi.edu or something? > If I'm not mistaken, dnssec@cafax.se is an older list used to discuss "dnssec general stuff" that would bog down the namedroppers list - ie sidbar discussions, wild ideas, etc... It was used in the past to talk about workshops also, but that was before workshops became a cottage industry in dnssec land. There are multiple dnssec related lists. changing the dnssec@isi.edu list name gets my vote - if it ends up more descriptive that is :) Scott From edlewis@arin.net Thu Jan 16 20:07:30 2003 From: edlewis@arin.net (Edward Lewis) Date: Thu, 16 Jan 2003 12:07:30 -0800 Subject: [vet-DS] workshops In-Reply-To: <200301161623.h0GGNds16887@boreas.isi.edu> References: <200301161623.h0GGNds16887@boreas.isi.edu> Message-ID: Be forewarned - never, never, never rely on the(se=9.3) snapshots for anything other than testing...no excuses allowed. At 8:23 -0800 1/16/03, Bill Manning wrote: >% what is the DS snapshot this time? 20021113? > >the most recent I have is: > > bind-9.3.0s20021217.tar.gz > > >--bill >Opinions expressed may not even be mine by the time you read them, and >certainly don't reflect those of any other entity (legal or otherwise). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer From mcr@sandelman.ottawa.on.ca Thu Jan 16 23:53:59 2003 From: mcr@sandelman.ottawa.on.ca (Michael Richardson) Date: Thu, 16 Jan 2003 18:53:59 -0500 Subject: [vet-DS] workshops In-Reply-To: Your message of "Thu, 16 Jan 2003 10:33:10 +0100." <20030116103310.3910deeb.olaf@ripe.net> Message-ID: <200301162354.h0GNs02T017632@marajade.sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Olaf" == Olaf M Kolkman writes: Olaf> I am willing (actually eager :-) to partake in a workshop. But joining Olaf> a persistent testbeb, with a production domain, under the test-root is Olaf> something that I am hesitant about. The main reason is that I think Olaf> that except for the added security the two namespaces (the one from Olaf> the test and the IANA root) should be exactly identical. I am afraid I agree as well. This is why it is useful to start with .arpa, with ARIN and RIPE's cooperation. How big are these zones? ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPidGFIqHRg3pndX9AQEOvwQAsHOeRo31+r2hJzSlneokCkJzwRvML9qh GygbCitVmXb6Q8HWvSTpiDNup1ROENMw1oHnSpzld0+njeKdbYAn31BsB1tOilcw 3FRCvmgQhYQTEAkB2eofhpMhfMt6SHrwIqtCVS/lH+gikStQFqW6+0f+ZJsSmiXE U4fnaFfny2E= =AweW -----END PGP SIGNATURE----- From mcr@sandelman.ottawa.on.ca Fri Jan 17 14:16:32 2003 From: mcr@sandelman.ottawa.on.ca (Michael Richardson) Date: Fri, 17 Jan 2003 09:16:32 -0500 Subject: [vet-DS] workshops In-Reply-To: Your message of "Thu, 16 Jan 2003 12:07:30 PST." Message-ID: <200301171416.h0HEGWhS007658@marajade.sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Edward" == Edward Lewis writes: Edward> Be forewarned - never, never, never rely on the(se=9.3) snapshots for Edward> anything other than testing...no excuses allowed. Nice to say. In order to convince me, I need to see a release schedule for bind9. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPigQP4qHRg3pndX9AQHB/gQAu/8AWV5xF+yijhKTS3uv4BYiydx1M2tI vlliZBdCc9HFNHhMz/TxOswt4webJEL8mPXlaM7qW27xBC2eNkW3SpCk4VFWpxzm pkyMtuPkfnq8akSkEG3qkAEhpXhjBBrKc9ODJcQvH3iL0bh8TJrhOcdQtuhno7p1 WSZTUNCz0fo= =dH7Q -----END PGP SIGNATURE----- From edlewis@arin.net Tue Jan 21 14:51:19 2003 From: edlewis@arin.net (Edward Lewis) Date: Tue, 21 Jan 2003 09:51:19 -0500 Subject: [vet-DS] workshops In-Reply-To: <200301171416.h0HEGWhS007658@marajade.sandelman.ottawa.on.ca> References: <200301171416.h0HEGWhS007658@marajade.sandelman.ottawa.on.ca> Message-ID: At 9:16 -0500 1/17/03, Michael Richardson wrote: > Nice to say. > In order to convince me, I need to see a release schedule for bind9. I understand, but still, Bind 9.3snaps *are* dangerous to the user. We still need to define the DS RR correctly, it's not just a software development issue. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer From bmanning@ISI.EDU Tue Jan 21 15:57:31 2003 From: bmanning@ISI.EDU (Bill Manning) Date: Tue, 21 Jan 2003 07:57:31 -0800 (PST) Subject: [vet-DS] workshops In-Reply-To: <200301162354.h0GNs02T017632@marajade.sandelman.ottawa.on.ca> from Michael Richardson at "Jan 16, 3 06:53:59 pm" Message-ID: <200301211557.h0LFvVE02641@boreas.isi.edu> % Olaf> something that I am hesitant about. The main reason is that I think % Olaf> that except for the added security the two namespaces (the one from % Olaf> the test and the IANA root) should be exactly identical. I am afraid % % I agree as well. % This is why it is useful to start with .arpa, with ARIN and RIPE's cooperation. % How big are these zones? we have the arpa zone (very small) and some of the in-addr.arpa zones (with some delay) --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From mcr@sandelman.ottawa.on.ca Tue Jan 21 17:41:02 2003 From: mcr@sandelman.ottawa.on.ca (Michael Richardson) Date: Tue, 21 Jan 2003 12:41:02 -0500 Subject: [vet-DS] workshops In-Reply-To: Your message of "Tue, 21 Jan 2003 09:51:19 EST." Message-ID: <200301211741.h0LHf2eZ005519@marajade.sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- (dropping CC's because I'm pretty sure all are on the dnssec list) >>>>> "Edward" == Edward Lewis writes: Edward> At 9:16 -0500 1/17/03, Michael Richardson wrote: >> Nice to say. >> In order to convince me, I need to see a release schedule for bind9. Edward> I understand, but still, Bind 9.3snaps *are* dangerous to the user. Edward> We still need to define the DS RR correctly, it's not just a software Edward> development issue. well, there is a proposal for how to fix DS RR on the table. I'm not entirely convinced, because it seems so simple, so I want to see it work. No progress will be made until the software development problem is straightened out. I'll write code if I have to, but getting it accepted is hard. We were supposed to finish this work already. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPi2GLIqHRg3pndX9AQHHxQP/YRx7deQkAJ91m/coEb9PtIgR8u+va+O5 JOr1L+lfTMuHDBGR+QbYkwNFUfvdyE1wAuUGDnsYWa+29NZuUStzB9hhkLUzZoUP sow4I5mjurXs0aOQagbViBRshwDMSYyA8bIxI1apo9uvkQuwJtzYm8F2jFrLcRRM WS0cNvfKn8s= =v0Ks -----END PGP SIGNATURE----- From edlewis@arin.net Tue Jan 21 18:04:28 2003 From: edlewis@arin.net (Edward Lewis) Date: Tue, 21 Jan 2003 13:04:28 -0500 Subject: [vet-DS] workshops In-Reply-To: <200301211741.h0LHf2eZ005519@marajade.sandelman.ottawa.on.ca> References: <200301211741.h0LHf2eZ005519@marajade.sandelman.ottawa.on.ca> Message-ID: At 12:41 -0500 1/21/03, Michael Richardson wrote: > well, there is a proposal for how to fix DS RR on the table. I'm not >entirely convinced, because it seems so simple, so I want to see it work. There's also this problem that is not addressed in -12: How do you deny the existence of a DS RR set in a referral in such a manner that does not confuse pre-DS RR yet DNSSEC aware resolvers into believing that such a situation is not a denial of existence data (via no referral)? A collection of us have seen this happen - when you sign (say) the root with DS semantics and use an older resolver. The resolver will first observe the NXT record before looking for the NS record. This is not a software glitch, the older resolver complies with the older specification (2535++) which never considered the case of having an NXT and NS in a noerror/noanswer message. Ergo - we need to fix the DS "era" DNSSEC to handle this. "We" have an idea how to do this, but not baked enough to expose to wider group just yet. That, and it's encouraging if others might have independent ideas that might shed light on other approaches. > No progress will be made until the software development problem is >straightened out. I'll write code if I have to, but getting it accepted is >hard. Yeah. The problem I am concerned about is the eternal supply of corner cases. I've branched off the mainline and am trying to write an analysis of DNS to be used as a checklist against new proposals to stem corner cases quicker. I have a version of it, but it failed to catch the corner case above. When I get a chance to edit again, I know what to include. I should probably do an example checklist of the DS versus it to demonstrate. > We were supposed to finish this work already. It's impossible to reliably schedule any engineering effort that is not following a cookie cutter design. It's also impossible to forecast the resources available to achieve a goal when every thing is donated/volunteered. No one is holding up progress intentionally, nor is anyone derailing progress. I've mentioned this to a few folks - we are messing with the most important part of the most critical element of the Internet. The loose coupling at delegation points is the most important part of DNS - with out this it would not have scaled to where we are. To acheive scaleable security we are paying the price of tightening the coupling. Not to mention that we are doing this on the name service. Kind of like triple bypass open heart surgery. Performed by volunteers. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer From miekg@atoom.net Tue Jan 21 19:00:30 2003 From: miekg@atoom.net (Miek Gieben) Date: Tue, 21 Jan 2003 20:00:30 +0100 Subject: [vet-DS] workshops In-Reply-To: References: <200301211741.h0LHf2eZ005519@marajade.sandelman.ottawa.on.ca> Message-ID: <20030121190030.GB23368@atoom.net> [On 21 Jan, @19:04, Edward wrote in "Re: [vet-DS] workshops ..."] > At 12:41 -0500 1/21/03, Michael Richardson wrote: > > well, there is a proposal for how to fix DS RR on the table. I'm not > >entirely convinced, because it seems so simple, so I want to see it work. > > There's also this problem that is not addressed in -12: > > How do you deny the existence of a DS RR set in a referral in such > a manner that does not confuse pre-DS RR yet DNSSEC aware resolvers ^^^^^^^^^^^^^^^^^^^^ why are we making that a problem? Officially there has been no DNSSEC deployment until now. It seems weird to me to be backwards compatible with stuff that never should be used for DNSSEC. On the other hand... a lot of people have bind9.2.x and don't do DNSSEC (until we deploy it). grtz Miek From mcr@sandelman.ottawa.on.ca Tue Jan 21 19:03:22 2003 From: mcr@sandelman.ottawa.on.ca (Michael Richardson) Date: Tue, 21 Jan 2003 14:03:22 -0500 Subject: [vet-DS] workshops In-Reply-To: Your message of "Tue, 21 Jan 2003 13:04:28 EST." Message-ID: <200301211903.h0LJ3Nuo012206@marajade.sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Edward" == Edward Lewis writes: Edward> At 12:41 -0500 1/21/03, Michael Richardson wrote: >> well, there is a proposal for how to fix DS RR on the table. I'm not >> entirely convinced, because it seems so simple, so I want to see it work. Edward> There's also this problem that is not addressed in -12: Edward> How do you deny the existence of a DS RR set in a referral in such Edward> a manner that does not confuse pre-DS RR yet DNSSEC aware resolvers Edward> into believing that such a situation is not a denial of existence data Edward> (via no referral)? Okay, you postulate: 1) DNSSEC aware 2) non-DS aware 3) they have a configured trusted key that would cause them to even be able to confirm this situation. While there are many recursive resolvers that are #1/#2, the longer we defer this issue, the less likely there are any of #3. The only trusted keys that I have configured into production DNS servers are my own. As such, I do not need either parent KEY, or DS record, so it doesn't matter. The only people who have configured me as a trusted key are my business partners, and I can update them bilaterally. So, is this really an issue that we have to resolve? Yes, it causes a theorectical flag day. In practice, I do not think so. Edward> A collection of us have seen this happen - when you sign (say) the Edward> root with DS semantics and use an older resolver. The resolver will Edward> first observe the NXT record before looking for the NS record. This Edward> is not a software glitch, the older resolver complies with the older Edward> specification (2535++) which never considered the case of having an Edward> NXT and NS in a noerror/noanswer message. Ergo - we need to fix the Edward> DS "era" DNSSEC to handle this. Edward> "We" have an idea how to do this, but not baked enough to expose to Edward> wider group just yet. That, and it's encouraging if others might Edward> have independent ideas that might shed light on other approaches. Great. Let me say that I'm profoundly annoyed by any concern here about 2535. If "we" care so much about 2535 era DNSSEC customers, WHY DID "we" SCREW UP THE KEY RECORD FOR EXISTING USERS without a replacement already implemented? 2535 is already obsolete, as the IESG already published restrict-key. They showed no concern for any people out there using it, why should you? Honestly, I think I've been running more secure, production zones longer than many. We will not find all the corner cases by thought alone. I *experience* aol.com and others who think that tcp port 53 is evil EVERY DAY. Not all of my secondaries are running bind9 with EDNS0 support. *I* tell you, that this corner case is not real. We won't find the others by thought alone. We will find them by putting things into production. That means that we get software that isn't marked "snapshot", and documents that are marked "draft standard". Nobody said to put this on f.root-servers.net today. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPi2Zb4qHRg3pndX9AQGtdQQA1QCKrkxcNkCez5EspRAiJT1rPo/GG+x5 8nQL/SO8W7HO3FsPEDA/NdwqGUrt7l5xktt0Oi556X6OfvlMowkA/sHOHjo/x7r3 6Bz6usgMLjr4/Auw/6yVWBt11HiQWte0OVDdj6sQJHKYmXnblcVtwUDOfFaNh+0L 2IQeM5Zf+to= =vMnO -----END PGP SIGNATURE----- From wgriffin@jtan.com Tue Jan 21 19:21:06 2003 From: wgriffin@jtan.com (wes) Date: Tue, 21 Jan 2003 14:21:06 -0500 Subject: [vet-DS] workshops In-Reply-To: <20030121190030.GB23368@atoom.net> Message-ID: <7D125B44-2D75-11D7-A21E-0003938125CC@jtan.com> I very much agree with Miek on this, worrying about 2535 resolvers is not worthwhile. We've been saying there will be a flag-day for DS and as such we should not worry about 2535 code. On Tuesday, January 21, 2003, at 02:00 PM, Miek Gieben wrote: > [On 21 Jan, @19:04, Edward wrote in "Re: [vet-DS] workshops ..."] >> >> How do you deny the existence of a DS RR set in a referral in such >> a manner that does not confuse pre-DS RR yet DNSSEC aware resolvers > ^^^^^^^^^^^^^^^^^^^^ > > why are we making that a problem? Officially there has been no DNSSEC > deployment until now. > It seems weird to me to be backwards compatible with stuff that never > should be > used for DNSSEC. > > On the other hand... a lot of people have bind9.2.x and don't do > DNSSEC (until > we deploy it). > > grtz Miek -- wes / wgriffin@jtan.com / 000f1a2f From bmanning@ISI.EDU Tue Jan 21 19:24:51 2003 From: bmanning@ISI.EDU (Bill Manning) Date: Tue, 21 Jan 2003 11:24:51 -0800 (PST) Subject: [vet-DS] workshops In-Reply-To: from Edward Lewis at "Jan 21, 3 01:04:28 pm" Message-ID: <200301211924.h0LJOpI24171@boreas.isi.edu> % I've mentioned this to a few folks - we are messing with the most % important part of the most critical element of the Internet. "There are no urgent DNS problems." - Hotz % Edward Lewis +1-703-227-9854 % ARIN Research Engineer --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From edlewis@arin.net Tue Jan 21 19:40:27 2003 From: edlewis@arin.net (Edward Lewis) Date: Tue, 21 Jan 2003 14:40:27 -0500 Subject: [vet-DS] workshops In-Reply-To: <20030121190030.GB23368@atoom.net> References: <200301211741.h0LHf2eZ005519@marajade.sandelman.ottawa.on.ca> <20030121190030.GB23368@atoom.net> Message-ID: At 20:00 +0100 1/21/03, Miek Gieben wrote: >why are we making that a problem? Officially there has been no >DNSSEC deployment until now. >It seems weird to me to be backwards compatible with stuff that >never should be >used for DNSSEC. The problem is that if, say, www.ripe.net is from a DS-aware zone, and I'm running a BIND 9.2. cache without DNSSEC, my server might mark ripe.net as a lame zone because of the DS record if the answers arrive as are defined in 9.3 snapshots. Then there is also the problem that if www.arin.net is from an unsigned arin.net with a signed net, then my cache will be confused by the NXT in the referral. So, even though my 9.2. is not explicitly running DNSSEC, the DS record changes so far will confuse it. By explicit: no configured keys, no authoritative signed zones. > >On the other hand... a lot of people have bind9.2.x and don't do DNSSEC (until >we deploy it). And that's the problem...;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer From olaf@ripe.net Wed Jan 22 06:43:08 2003 From: olaf@ripe.net (Olaf Kolkman) Date: Wed, 22 Jan 2003 07:43:08 +0100 Subject: [vet-DS] workshops In-Reply-To: Message from Miek Gieben of "Tue, 21 Jan 2003 20:00:30 +0100." <20030121190030.GB23368@atoom.net> Message-ID: <200301220643.h0M6h8Aq028570@birch.ripe.net> * * why are we making that a problem? Officially there has been no DNSSEC deplo * yment until now. * It seems weird to me to be backwards compatible with stuff that never should * be * used for DNSSEC. But the problem is that deploying DNSSEC with DS gives problems with a set of resolvers that do not have DNSSEC turned on. They just get confused about a NXT RR being returned. --Olaf From mcr@sandelman.ottawa.on.ca Wed Jan 22 20:08:39 2003 From: mcr@sandelman.ottawa.on.ca (Michael Richardson) Date: Wed, 22 Jan 2003 15:08:39 -0500 Subject: [vet-DS] workshops In-Reply-To: Your message of "Wed, 22 Jan 2003 07:43:08 +0100." <200301220643.h0M6h8Aq028570@birch.ripe.net> Message-ID: <200301222008.h0MK8eGa004427@marajade.sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Olaf" == Olaf Kolkman writes: Olaf> * Olaf> * why are we making that a problem? Officially there has been no DNSSEC deplo Olaf> * yment until now. Olaf> * It seems weird to me to be backwards compatible with stuff that never should Olaf> * be Olaf> * used for DNSSEC. Olaf> But the problem is that deploying DNSSEC with DS gives problems with a Olaf> set of resolvers that do not have DNSSEC turned on. They just get Olaf> confused about a NXT RR being returned. I didn't get this until Ed Lewis, painfully, explained this to me on the phone yesterday. Our scenario, I ask a.root-servers.net, about www.mycompany.no. Right now, I get: marajade-[~] mcr 1077 %dig @a.root-servers.net. www.mycompany.no. a ; <<>> DiG 9.3.0s20021115 <<>> @a.root-servers.net. www.mycompany.no. a ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60207 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 6 ;; QUESTION SECTION: ;www.mycompany.no. IN A ;; AUTHORITY SECTION: no. 172800 IN NS IFI.UIO.no. no. 172800 IN NS NAC.no. no. 172800 IN NS NN.UNINETT.no. no. 172800 IN NS SLAVE1.STH.NETNOD.SE. no. 172800 IN NS NJET.NORID.no. no. 172800 IN NS NOT.NORID.no. ;; ADDITIONAL SECTION: IFI.UIO.no. 172800 IN A 129.240.64.2 NAC.no. 172800 IN A 129.240.2.40 NN.UNINETT.no. 172800 IN A 158.38.0.181 SLAVE1.STH.NETNOD.SE. 172800 IN A 192.36.144.116 NJET.NORID.no. 172800 IN A 198.133.199.105 NOT.NORID.no. 172800 IN A 198.133.199.104 I.e. a referall to the .no root servers. Assume that .no is not secure yet. If we make a.root-servers.net DS aware, then, as part of the referral, it has to tell is that there are no DS records for no: no. 172800 IN NXT np. SIG NXT no. 172800 IN SIG blah. (np comes after no alphabetically. No clue if np. exists) The problem turns out to be that bind9 with (Ed assures me) some support from RFC2536, sees the NXT (does not examine it in detail), assumes that this *proof* that no. does not exist, and then determines that no. does not exist. bind9 does this even though it has no key that it could use to verify the SIG. The fact that it is DNSSEC capable is what screws things up. (This really feels like a bug in bind9, but I'm told it isn't really, and in any case, it is widely enough deployed that we probably have to work around it) In fact, the NXT is simply attesting to the fact that the DS does not exist. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPi76RIqHRg3pndX9AQGScgQA8Dq9rTN2UqE6iHt/KlkHRnaePUpU2e7B vPGxCBIAd+PoUVS+lb4Te7eVCcLKm3ZcK6GOMgINkff/lcDQh5dT6+eMEpffX6EV 4gfSC5ajqQ7g/7oFRXJy6zuiJ8dYkvMH0/Yibqjg3RNCekNI75hcjX0lrUFZr7qY vbcv7kmN80M= =fkLS -----END PGP SIGNATURE----- From gnu@toad.com Thu Jan 23 11:34:57 2003 From: gnu@toad.com (John Gilmore) Date: Thu, 23 Jan 2003 03:34:57 -0800 Subject: [vet-DS] DNSSEC problem In-Reply-To: Message from Michael Richardson of "Wed, 22 Jan 2003 15:08:39 EST." <200301222008.h0MK8eGc004427@marajade.sandelman.ottawa.on.ca> References: <200301222008.h0MK8eGc004427@marajade.sandelman.ottawa.on.ca> Message-ID: <200301231134.h0NBYvC24150@new.toad.com> [Anti-spam crap will probably bounce this message from dnssec@isi.edu, so MCR, if you don't see it appear there, please forward the msg.] > If we make a.root-servers.net DS aware, then, as part of the referral, it > has to tell is that there are no DS records for no: > > no. 172800 IN NXT np. SIG NXT > no. 172800 IN SIG blah. > > (np comes after no alphabetically. No clue if np. exists) > > The problem turns out to be that bind9 with (Ed assures me) some support > from RFC2536, sees the NXT (does not examine it in detail), assumes that this > *proof* that no. does not exist, and then determines that no. does not exist. > bind9 does this even though it has no key that it could use to verify the > SIG. The fact that it is DNSSEC capable is what screws things up. > (This really feels like a bug in bind9, but I'm told it isn't really, and > in any case, it is widely enough deployed that we probably have to work > around it) The problem-behind-the-problem is that the original DNSSEC violated in small ways one of the basic design constraints of the DNS -- that there's a single authoritative source for a given set of RRs. The NXT record violated that constraint, in a small way, which lead to misunderstandings and outright bugs. The people who misdesigned "DS" didn't even *understand* this basic design constraint, so they started tossing RRsets for the same name (e.g. ".no") into all sorts of different zones (both the root zone and the ".no" zone). This REALLY doesn't work. The original 1970s DNS (pre DNSSEC) made the child zone the authoritative source for ALL of the RRsets. For a domain name of "X.Y.Z", the authoritative zone file for all RRsets with domain names that end in "X.Y.Z" is the one that begins with the "X.Y.Z SOA" record. No exceptions. In other words, the root zone consists of almost nothing authoritative. It contains a ". SOA" record, which it is authoritative for. But the NS records in it for its subdomains are just "hints" about the real NS records. Any "A" records in the root zone are also just "hints" about the real A records for those names. To get the real answers, you have to go to tha authoritative sources (the subdomains). The COM domain is similar -- it contains almost nothing that it is authoritative for. The 'hint' records at the parent domain permit a resolver to bootstrap. These hints are not authoritative. Any trace of them is replaced in the resolver's cache as soon as the real authoritative records arrive. (The security model of the 1970s DNS was that a single "believe-me-I'm-authoritative" bit defined which records were secure and which were not. This is still the operative model, *because* we have been gridlocking for years on DNSSEC.) The NS-record hints let the parent zone point a resolver toward the name servers that are authoritative (contain the SOA) for the child zone. But an NS isn't all you need. The A-record hints untangle the nasty problem of referring someone looking for "toad.com" to the name servers at "ns1.toad.com" or "ns2.toad.com". To send a query to "ns1.toad.com" you need its IP address, which you would normally get from the name server for toad.com. But that is who you were looking for in the first place! Using the hint sent by a parent zone, a resolver will send a packet to the purported IP address of purported name server ns1.toad.com, and (with luck) get back an authoritative answer that gives the full set of toad.com's NS records, and also the A records for the names in those NS records (ns1.toad.com and ns2.toad.com). These will come from "the horse's mouth" and have the right TTLs, for example. The resolver will throw away the hint records. It will now authoritatively know how to route queries for any other records it needs from the toad.com zone. OK, so that was the original DNS. Now let's see how DNSSEC changed it. The original DNSSEC (discounting NXT records), made the child zone the authoritative source for ALL of the RRsets. This was the correct decision, in line with basic design philosophy. The original DNSSEC signature model is that the child zone (e.g. toad.com) would somehow pass its KEY records up to the parent zone (e.g. who I bought my domain from). The parent would return a SIG record that signs those KEY records with the parent's zone key. The ***CHILD*** would then publish these SIG records along with the KEY records (and any other SIG records of its own that it wished to publish). The child would be the authoritative source for all of these records. This design works, but requires out-of-band communication with your parent domain, so they can sign your KEY records. (Of course, registering a domain at all, updating your NS records or your contact info, paying for it, etc, all require out-of-band communication with your parent domain. By out-of-band I mean "not using a defined DNS protocol".) The NXT record messed up the basic design decision about who's authoritative for a given RRset. The problem is that a "no." NXT record must exist in the parent zone (root), saying what the next alphabetical record is in the parent. A "no. NXT" must also exist in the child, saying what alphabetical record is next in the child (it's probably a subdomain like "say.no", while in the parent it's another TLD like ".oz"). This caused lots of hair in BIND 9, some of which we are probably still debugging. My strong suggestion is to move forward with: * The original design of DNSSEC (no DS records, just KEY and SIG) * DO NOT DEPLOY the problematic NXT records. 99% of what we care about is to secure the REAL EXISTING DNS records. Not to securely say that NONEXISTENT records really, securely, DON'T EXIST. * DO NOT DEPLOY the problematic DS records. Let's solve the part of the problem that we can easily solve and deploy -- and get it deployed and protecting us. And leave the stuff that's still "research" for later design and deployment. Let's NOT hold security for real records hostage to the decoy goal of securing the unreality of nonexistent records. John Gilmore From miekg@atoom.net Thu Jan 23 14:13:28 2003 From: miekg@atoom.net (Miek Gieben) Date: Thu, 23 Jan 2003 15:13:28 +0100 Subject: [vet-DS] DNSSEC problem In-Reply-To: <200301231134.h0NBYvC24150@new.toad.com> References: <200301222008.h0MK8eGc004427@marajade.sandelman.ottawa.on.ca> <200301231134.h0NBYvC24150@new.toad.com> Message-ID: <20030123141328.GF31857@atoom.net> [On 23 Jan, @12:34, John wrote in "Re: [vet-DS] DNSSEC problem ..."] > SIG record that signs those KEY records with the parent's zone key. > The ***CHILD*** would then publish these SIG records along with the > KEY records (and any other SIG records of its own that it wished to > publish). The child would be the authoritative source for all of > these records. > > This design works, but requires out-of-band communication with your > parent domain, so they can sign your KEY records. (Of course, > registering a domain at all, updating your NS records or your contact > info, paying for it, etc, all require out-of-band communication with > your parent domain. By out-of-band I mean "not using a defined DNS > protocol".) but this does not scale at the TLDs. You register a domain once, you update your nameserver records not very frequent. But with DNSSEC you will have to resign your (child) zone monthly or even more often and you will have to rollover your zone key twice a year. This scaling problem prompted us (NLnetLabs) to develop a solution to reduce the parent/child communication. This was the sig@parent draft (www.nlnetlabs.nl/dnssec/dnssec-parent-sig-01.txt). Olufar came up with a more general solution which resulted in the DS draft. grtz Miek NLnetLabs From edlewis@arin.net Thu Jan 23 14:51:29 2003 From: edlewis@arin.net (Edward Lewis) Date: Thu, 23 Jan 2003 09:51:29 -0500 Subject: [vet-DS] DNSSEC problem In-Reply-To: <200301231134.h0NBYvC24150@new.toad.com> References: <200301222008.h0MK8eGc004427@marajade.sandelman.ottawa.on.ca> <200301231134.h0NBYvC24150@new.toad.com> Message-ID: At 3:34 -0800 1/23/03, John Gilmore wrote: >OK, so that was the original DNS. Now let's see how DNSSEC changed it. You are so very right in your analysis of old DNS and what makes it strong. I disagree with: >The people who misdesigned "DS" didn't even *understand* this basic design >constraint, so they started tossing RRsets for the same name (e.g. ".no") into >all sorts of different zones (both the root zone and the ".no" zone). This >REALLY doesn't work. I will not counter you on your assessment of 'the people who misdesigned "DS"' - it is hard to argue what was in a person's mind when they made a decision - but I have become convinced that the damage done by the DS record is the least impact on the system while adding the desired security services promised by DNSSEC. The deal is that DNS zones are loosely coupled, and this I believe is the biggest asset of the DNS design. Now we want to add security. There are two paths here. One is that each autonomous, loosely coupled zone establish security associations with each resolver pulling its information (or chaining trust through a series of concatenated hop-to-hop associations). This sounds much like IPsec, and why this hasn't been pursued has been discussed over the years, i.e., it doesn't scale well. The option we have chosen to pursue is to use the domain tree as a lever to scale security. We have postulated all along that we now need the parent to make a statement about the child's state (all the while genuflecting to the desire to have a non-tree path to validation and verification). By this very fact we are tightening the coupling between parent and child, so there will be a price to pay. >My strong suggestion is to move forward with: > > * The original design of DNSSEC (no DS records, just KEY and SIG) > * DO NOT DEPLOY the problematic NXT records. 99% of what we care about is > to secure the REAL EXISTING DNS records. Not to securely say > that NONEXISTENT records really, securely, DON'T EXIST. > * DO NOT DEPLOY the problematic DS records. > In tightening the loose coupling we will need to pay a price. Like a physics problem, to raise a mass against a gravitational force, energy is going to be expended. No matter whether we use a lever, a screw, a system of pulleys, etc., the same amount of energy is going to be needed to move the mass. The two variables are the amount of energy that will be wasted (friction) and the amount of power needed to accomplish the task in a given period of time. So, DS or SIG @ child, both require work (energy). One question is which will incur the least amount of friction. (We can't control power - we are all in volunteer mode here.) You have added another twist - dropping denial of existence altogether, which amounts to moving less mass, hence should require less energy. I liked the SIG @ child model, it certainly was a clean design. It adhered to the principles of loose coupling in that it was easy on the name server that served the parent and child. But recall that the price was the .PARENT file because name servers of that vintage laid one zone over the other at the cut point. SIG @ child also exhibits a nasty side effect that hinders growing systems - the need for a feedback loop. The child sends to the parent, the parent returns. In the small we have seen the failure of this feedback loop, in particular at a workshop in Uppsala Vasby in September 2000. This experience led to the search for an alternative that has wound up in DS. There was also an experience with the CAIRN test bed sometime in 2001 that showed the congestive collapse of the model. That experience has not been documented. (And I am not in position to document it.) SIG @ child is an approach to tightening the coupling that is rather attractive from a protocol design point of view. But it has proven to be an operational nightmare. Standing on it's own, I believe it is dead. Yes, the DS approach is unattractive in its impact on the protocol. I am already convinced that there will be no perfect approach to adding DNSSEC services, I am resigned to there being some element of unattractiveness. So, forgiving that the DS is introducing some ugliness into DNS, is it better or worse than SIG @ child? I think it is proving to be so. DS is much easier to manage from an administration perspective, which is important for the continued scale of DNS. DS has to address many issues overlooked to date, that is very true. I've been working on a document that analyzes the architecture of DNS in the hopes of stamping out the "corner case" crisis plaguing DS and other modification efforts. Although the document isn't done, I'm becoming convinced that with a bit more work, DS can be hammered into shape. (Why is DS taking so long, why are we only slowly finding 'corner cases?' Not many folks have been funded [or had spare time to contribute] to work on it.) Now, as far as removing secure denial of existence from the table, it seems like you might prefer the opt-in approach, but making it mandatory - that zone cuts are never signed. This won't work for the DS approach, of course, as that approach requires signed data to be at the zone cut. But it would work for the SIG @ child approach. I'm unconvinced that dropping secure denial of existence is necessary (although the NXT violates the zone cut rule, it has not proven to be harmful in any way), but the thought of requiring opt-in like semantics to SIG @ child is interesting. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer