wrt joao damas' DLV talk on wednesday
i intended to be present for the Q&A after joao's DLV talk but i was told that being there without having registered was rude. as i was exiting the room, i heard sam weiler at the Q&A mic repeating his prior comments as to how ISC should not be a DLV registry, and i saw mark kosters in line at another mic probably as a followup to my followup to his earlier question. i apologize for the length of this note, and for the fact that it says more about DNS bits and kibble than anybody really ever wanted to know, and also for my rudeness in attending joao's talk without having registered for nanog. first, sam weiler's question. let me answer, here on the mailing list where rudeness is an art form, that ISC intends to follow through on DLV. while we solicited (and got!) much design input (from sam weiler among others including david conrad who gave me the idea for DLV in the first place), ISC holds "change control". this isn't an IETF effort. just a cooperative based on some source code. both the source code (bind9.3 and bind9.4) and the DLV specification are completely forkable in the BSD tradition-- anyone else who wants to do this differently is welcome to any of the ideas or code ISC has published. and if someone else with similar resources and similar trust tells me that they are going to run a DLV registry (starting immediately-- ours is open NOW) then we would possibly re-evaluate the need to do a DLV registry inside ISC. none of that appears likely. to me, continued nondeployment of dnssec is what seems likely, seasoned with periodic 11th hour "oh no, the secure dns spec isn't done, let's re-open all the issues we thought were closed" parties. sam also wanted to know how ISC planned to verify zone ownership for the purpose of knowing whether or not we should accept a proferred key for, say, "bankofamerica.com". i think sam also echoed randy bush's earlier concern as to how we would secure our DLV registry against data loss, hacking, and so on. joao damas already answered those, and he's the programme manager for DLV, so we can all trust his answers. so i've heard sam's comments before, and had i actually registered for nanog i would surely have answered them as i've answered before, and now you all know what i would have said. second, mark kosters' additional question. i have no idea what mark kosters' additional question was, but if it had to do with my followup to his previous question, it was probably "what's the real difference, if any, between a TLD registry putting their key in ISC's DLV registry vs. running a DLV registry themselves?" if so, then i'm glad he asked, it's a favorite topic of mine. if a TLD registry (such as mark kosters' employer, verisign, for "COM" and some other TLDs) wants to sign their zone but their desire is irrelevant because the root zone is not yet signed, then they could meet some of the same requirements by sending ISC a DLV RR. their customers (VIX.COM in my case) would not have to do anything special -- we could just sign our zones and send our keys to our registrar (alice's registry in my case) who would then forward them to the TLD registry via some proposed EPP extensions. this is the best case scenario since there's only one key held by DLV, which is the one for COM, and once IANA gets around to signing the root zone, the only change will be that verisign will send its COM key to IANA rather than to ISC. no registrar or registrant ("zone holder") would have to know or make any changes to their software or procedures. if on the other hand a TLD registry (such as verisign) was not planning, for reasons such as subdomain enumeration or size-of-metadata (both of which are proposed to be solved by NSEC3, now in early preproduction), to sign their TLD (for example, COM), then that registry would have no key to send to IANA (if the root was signed) or to ISC for the DLV registry (if the root remains unsigned, as appears likely for the near term.) in this less-than-best case, registrars could send ISC blocks of registrant keys for the DLV registry, or registrants could send ISC zone keys directly. the reason this is less-than-best is that ISC would have to verify zone ownership before publishing a zone's key, unless we can get registrars to do this for us and send us blocks of keys). since we aren't charging any fees for DLV registrations, we're currently putting the burden of proof of zone ownership on the zone owners. (they have to contact joao damas or come to ISC's main office and present credentials, ideally using strong-chain PGP.) there is some question in my mind as to why a TLD registry would choose to run a DLV registry rooted at their TLD, rather than just signing their TLD. perhaps it's because DLV, even as ugly as it is, avoids the same subdomain enumeration ("zone walking") and metadata-size problems that NSEC3 avoids, but DLV is in its late stages whereas NSEC3 is in its early stages. or perhaps a TLD registry might not want to see other companies, even 501(c)(3) public benefit companies like ISC, carrying data for their registrants or having direct relationships with their registrants and registrars. i dunno. but to now repeat my earlier answer with this additional context: if every TLD registry wants to run its own DLV registry, then the world's validator population will probably experience "cut and paste fatigue". there are about 250 TLD's, and there are potentially many millions of validators. if one TLD per month needs to update its static DLV validation key, that's a whole lot of cutting and pasting that'll never happen after month 2 or so. that's why a clearinghouse, such as IANA for the root zone as called for in the dnssec-bis specification, or ISC's DLV registry until the root zone is signed, is necessary. ISC's actions in undertaking this without sharing change control in the usual IETF way have been called controversial. my advice to those of you who think we are doing the wrong thing is, pick one of the following and execute: 1. figure out why the root zone isn't signed and fix whatever it is. 2. design your own version of DLV (as sam weiler has done, long before ISC's although i didn't learn this until later), publish it, and urge adoption (find someone to run a DLV registry, implement the validator side, and so on.) 3. rubber-stamp ISC's DLV design, adopt our BSD-licensed source code for the validator side, start your own DLV registry. 4. go to IETF and say "i think something DLV should be a standard but i don't like ISC's, so let's make an RFC together." what you should note in common with all of these things is that ISC could never prevent alternatives from coming into existence (nor would we wish to), and indeed all of our work on DLV is directly forkable/leveragable by any alternative effort, even potentially proprietary or commercial ones. so, go for it! (my concern is, DLV is an evolutionary dead end, a deployment aid, and pissing away even more time and money on it seems like a waste of time compared to finishing NSEC3, signing the root, y'know, important stuff.)
my question was a bit simpler. what is the security policy that isc plans to use over the content of the isc dlv registry? and how will the dvl trust key roll-over and revocation be handled? as providing a tld key registry is tantamount to emulating the root key responsibilities of the iana, potential users should be rather concerned. randy
On Sun, Jun 11, 2006 at 06:50:05AM +0000, Paul Vixie wrote:
i intended to be present for the Q&A after joao's DLV talk but i was told that being there without having registered was rude.
you were attending nanog without registering and paying? that is rude. have you offered to pay retroactively? that would be the honorable thing to do. t. -- _____________________________________________________________________ todd underwood +1 603 643 9300 x101 renesys corporation chief of operations & security todd@renesys.com http://www.renesys.com/blog/todd.shtml
i intended to be present for the Q&A after joao's DLV talk but i was told that being there without having registered was rude.
you were attending nanog without registering and paying? that is rude. have you offered to pay retroactively? that would be the honorable thing to do.
attending nanog wasn't an option. i hadn't realized that sitting in on joao's talk so i could be there for Q&A equalled attendance, and so i neither paid nor offered retroactively to pay. do you really think i should? (i asked everybody i met on site, and was universally told by those i asked to "stop worrying about it".)
attending nanog wasn't an option. i hadn't realized that sitting in on joao's talk so i could be there for Q&A equalled attendance, and so i neither paid nor offered retroactively to pay.
Sounds to me like your intent was to be a "Speaker"
do you really think i should? (i asked everybody i met on site, and was universally told by those i asked to "stop worrying about it".)
If Merit had simply given you a "Speaker's Badge" then all this tempestuous teapot wouldn't have dribbled a single drop. --Michael Dillon
Paul Vixie wrote:
i intended to be present for the Q&A after joao's DLV talk but i was told that being there without having registered was rude. you were attending nanog without registering and paying? that is rude. have you offered to pay retroactively? that would be the honorable thing to do.
attending nanog wasn't an option. i hadn't realized that sitting in on joao's talk so i could be there for Q&A equalled attendance, and so i neither paid nor offered retroactively to pay. do you really think i should? (i asked everybody i met on site, and was universally told by those i asked to "stop worrying about it".)
Having not been present at this nanog, I'm going to respond at face value based upon what I've read. If Paul is present specifically and only for Q&A that pertains to subject matter with which he is knowledgeable, his presence helps the ops community. I have not seen any writings that indicate that Paul was at b&g or bofs or other portions of the conference. Based upon that data, I am inclined to support Paul. The proper procedure would have been to let Merit know that he would be there to support the individual presenting the talk. Other than that, I see no offense.
If Paul is present specifically and only for Q&A that pertains to subject matter with which he is knowledgeable, his presence helps the ops community.
I have not seen any writings that indicate that Paul was at b&g or bofs or other portions of the conference.
i was at the B&G, having first checked with the host to find out if visitors were welcome. while my intent was to pick somebody up for dinner, i admit that i also ate and drank and socialized.
Based upon that data, I am inclined to support Paul.
The proper procedure would have been to let Merit know that he would be there to support the individual presenting the talk.
Other than that, I see no offense.
now that you know the whole story, perhaps you'll reevaluate your position. my own feeling on this is that if i'm attending a nanog in some distant city and there are ops people living/working in that city who do not have time to "attend", then i would rather that they came to the nanog social events than either (a) not see them at all, or (b) have to meet them elsewhere. however, this is not a debate about facts (which aren't in dispute), but rather manners, a social-subjective matter. what is or isn't "rudeness" varies somewhat with time, location, culture, "society's mood", and so on. lacking a "miss manners" to gauge the nanog society's "mood" in this time and place, we all have to just use our own best judgement. mine failed me, and i've already apologized for that.
Paul Vixie wrote:
If Paul is present specifically and only for Q&A that pertains to subject matter with which he is knowledgeable, his presence helps the ops community.
I have not seen any writings that indicate that Paul was at b&g or bofs or other portions of the conference.
i was at the B&G, having first checked with the host to find out if visitors were welcome. while my intent was to pick somebody up for dinner, i admit that i also ate and drank and socialized.
Based upon that data, I am inclined to support Paul.
The proper procedure would have been to let Merit know that he would be there to support the individual presenting the talk.
Other than that, I see no offense.
now that you know the whole story, perhaps you'll reevaluate your position.
my own feeling on this is that if i'm attending a nanog in some distant city and there are ops people living/working in that city who do not have time to "attend", then i would rather that they came to the nanog social events than either (a) not see them at all, or (b) have to meet them elsewhere.
however, this is not a debate about facts (which aren't in dispute), but rather manners, a social-subjective matter. what is or isn't "rudeness" varies somewhat with time, location, culture, "society's mood", and so on. lacking a "miss manners" to gauge the nanog society's "mood" in this time and place, we all have to just use our own best judgement. mine failed me, and i've already apologized for that.
Wow, are there no outstanding technical, networking, product subjects left to talk about that this has been the most active subject in the last few days? It happened, but that doesn't necessarily mean that others will take advantage of this in the future. Some make small mistakes and others have no honor. This seems to be a case of a small mistake. GET OVER IT! --Payam T Chychi
Paul Vixie wrote:
I have not seen any writings that indicate that Paul was at b&g or bofs or other portions of the conference.
i was at the B&G, having first checked with the host to find out if visitors were welcome. while my intent was to pick somebody up for dinner, i admit that i also ate and drank and socialized.
Based upon that data, I am inclined to support Paul.
now that you know the whole story, perhaps you'll reevaluate your position.
Let's see: 1) You attended a b&g after checking with the host 2) You attempted to attend a q&a with the purpose of providing additional input for the ops community and that provided support for a speaker. Is there a better way to have handled the situation? Perhaps. The positive outcome of this issue is that we are discussing how to handle "drop-ins" (freebie conference attenders?). I still don't see that you fall into this category with regard to this incident.
now that you know the whole story, perhaps you'll reevaluate your position.
While I have a number of opinions on the subject (who on this list does not have opinions?), I suggest that the program committee members take this on as "todo" to formulate some sort of acceptable practice for future NANOG meetings. Paul has made a number of good points, as have others. Paul may be special (are we not all?), but just because he is special should not mean different expectations in behavior and actions at these meetings. Many good points have been raised. Make some choices, and stick with them for future meetings. Gary
On Mon, 12 Jun 2006, Buhrmaster, Gary wrote: > I suggest that the > program committee members take this on as "todo" to formulate > some sort of acceptable practice for future NANOG meetings. Taking the liberty of speaking for the rest of the PC, I've heard your suggestion, and will bring it up at our next meeting. -Bill
you were attending nanog without registering and paying? that is rude. have you offered to pay retroactively? that would be the honorable thing to do. todd underwood +1 603 643 9300 x101 renesys corporation chief of operations &security
There was a similar comment from another Renesys employee on nanog-futures. Is it possible that this is some sort of commercial dispute between two companies, Renesys and ISC, who are not network operators, but who offer services to network operators? In any case, it doesn't seem to be on topic for the NANOG list. If Renesys really doesn't like ISC, why don't you sue him instead of whining on this list? --Michael Dillon
michael, all, On Mon, Jun 12, 2006 at 10:43:16AM +0100, Michael.Dillon@btradianz.com wrote:
you were attending nanog without registering and paying? that is rude. have you offered to pay retroactively? that would be the honorable thing to do. todd underwood +1 603 643 9300 x101 renesys corporation chief of operations &security
There was a similar comment from another Renesys employee on nanog-futures. Is it possible that this is some sort of commercial dispute between two companies, Renesys and ISC, who are not network operators, but who offer services to network operators?
as far as i know ISC and renesys have no overlapping businesses at all. we certainly don't consider them competitors and as far as i know, they don't even know who we are.
In any case, it doesn't seem to be on topic for the NANOG list. If Renesys really doesn't like ISC, why don't you sue him instead of whining on this list?
odd and harsh words. i have no beef with the ISC at all, no intention to sue them, and no idea what i would sue them for. i do have a problem with people attending nanog for free without paying and without being speakers (speakers are not those selected at random by Merit, but rather people whose presentations or panels are approved by the program committee as part of the official program). but indeed, aside from answering these oddly delusional comments on this list, this topic is better handled on nanog-futures. t. -- _____________________________________________________________________ todd underwood +1 603 643 9300 x101 renesys corporation chief of operations & security todd@renesys.com http://www.renesys.com/blog/todd.shtml
michael, all,
[ if you can't use procmail, could you at least respond to non-ops trolls on the nanog-futures list? ] but todd, you have a bit of clue. do you have a clue at all regarding the question i asked on-list the other day? what is the security policy that isc plans to use over the content of the isc dlv registry? and how will the dvl trust key roll-over and revocation be handled? if the above can not be very clearly answered (by isc?), then this proposal is techno-political hubris at best. randy
randy, all, On Mon, Jun 12, 2006 at 06:37:01AM -1000, Randy Bush wrote:
michael, all,
[ if you can't use procmail, could you at least respond to non-ops trolls on the nanog-futures list? ]
indeed. i don't use the former but i should have used the latter. apologies.
but todd, you have a bit of clue. do you have a clue at all regarding the question i asked on-list the other day?
what is the security policy that isc plans to use over the content of the isc dlv registry? and how will the dvl trust key roll-over and revocation be handled?
i don't. i've been reading the spec recently and trying to catch up on the contents of the recent nanog meeting that i was unable to attend. i've been a long-term sceptic of dns-sec due to the lack of any movement on the issuing of a root key (and the multiple, incompatible changes in the protocol itself), but this effort looks interesting.
if the above can not be very clearly answered (by isc?), then this proposal is techno-political hubris at best.
yes, or an interesting proof-of-concept that can be taken-up and completed by someone else. t. -- _____________________________________________________________________ todd underwood +1 603 643 9300 x101 renesys corporation chief of operations & security todd@renesys.com http://www.renesys.com/blog/todd.shtml
what is the security policy that isc plans to use over the content of the isc dlv registry? and how will the dvl trust key roll-over and revocation be handled? if the above can not be very clearly answered (by isc?), then this proposal is techno-political hubris at best.
yes, or an interesting proof-of-concept that can be taken-up and completed by someone else.
actually, i suspect that the issues of dlv are exactly those of iana root signing, key management and tld signature policy. and hence dlv is hoisted on the same petard it attempts to avoid, and then devolves to a simple power play of isc vs iana with neither having a good answer to the real technical and security issues. randy
Randy, On Jun 12, 2006, at 10:08 AM, Randy Bush wrote:
actually, i suspect that the issues of dlv are exactly those of iana root signing, key management and tld signature policy.
Nope. Oh sure, from a technical perspective, the problems are pretty much the same, but I think they are solvable (if not in a way that will please everyone). However, one of the major layer-9 or above issues having to do with signing the root is "who is going to sign the root", which translates to "who owns the root". The answer, from a political perspective, isn't as obvious as one might wish. When you push down a layer in the DNS hierarchy, then the layer-9 or above issue becomes _much_ clearer and easier to solve. ccTLD admins and folks like PIR, Verisign, Neustar, etc., have clear and unambiguous authority over their zones (not getting into the argument of whether they should have clear and unambiguous authority) and thus, there is no question who should sign those zones (how is a mere implementation detail). The problem is, if you push down a layer, you have to figure out how to get the appropriate keying information into the caching server's "trusted-key" (or moral equivalent) statement. I personally think some sort of automated non-DNS out-of-band mechanism would be better than recreating the "who gets to sign X" problem, but there are lots of annoying details to deal with.
and hence dlv is hoisted on the same petard it attempts to avoid, and then devolves to a simple power play of isc vs iana with neither having a good answer to the real technical and security issues.
Can you have a power play when at least one party doesn't play? IANA's role is really easy: people tell us what to do, we try to do it. When somebody tells IANA how to deal with root signing, key management, and tld signature policy, we do what is necessary to implement what is asked of us. Until then, I'm a bemused bystander... Rgds, -drc
drc@virtualized.org (David Conrad) writes:
Can you have a power play when at least one party doesn't play?
what i find fascinating by the whole "why don't you and him fight?" angle being played out here is that there is *no* trusted entity for this. drc, can you check with your corporate masters to find out whether ICANN, ISOC, ITU, NRO, and the other alphabet-soup denizens of your choice could somehow do a joint venture around DLV? it seems to me that if we dilute the stew with enough disparite international unaligned interests, we'll eventually reach a point where the result appears so dilute as to be powerless and therefore trustworthy, but still barely potent enough to operate a DLV zone. -- Paul Vixie
On Mon, 12 Jun 2006, Randy Bush wrote:
what is the security policy that isc plans to use over the content of the isc dlv registry? and how will the dvl trust key roll-over and revocation be handled? if the above can not be very clearly answered (by isc?), then this proposal is techno-political hubris at best.
yes, or an interesting proof-of-concept that can be taken-up and completed by someone else.
actually, i suspect that the issues of dlv are exactly those of iana root signing, key management and tld signature policy. and hence dlv is hoisted on the same petard it attempts to avoid, and then devolves to a simple power play of isc vs iana with neither having a good answer to the real technical and security issues.
Unless I misunderstood the issues are not some-kind of power-play but that in order to use DNSSEC right now you need to be within the zone/TLD that itself is using DNSSEC and these are almost non-existent right now with zone maintainers unwilling to take necessary financial and other risks associated with upgrading to fully support DNSSEC. So DLV offers potential for individual domain owners to start using DNSSEC without waiting for the registry operator of their domain's TLD or SLD. This seems good to me and I'm happy ISC as non-profit organization is taking the initiative as I don't want the same situation as was with domains and certificates at the end of 1990s where profit-driven companies were acting as virtual monopoly in domain business. -- William Leibzon Elan Networks william@elan.net
participants (12)
-
Bill Woodcock -
Buhrmaster, Gary -
David Conrad -
J Bacher -
Michael.Dillon＠btradianz.com -
Paul Vixie -
Paul Vixie -
Payam T Chychi -
Randall Pigott -
Randy Bush -
Todd Underwood -
william(at)elan.net