Re: wrt joao damas' DLV talk on wednesday
Is there a better way to have handled the situation? Perhaps.
indeed, i should have registered as a speaker and sat behind joao while he spoke.
The positive outcome of this issue is that we are discussing how to handle "drop-ins" (freebie conference attenders?).
agreed, there's a salient issue underlying all of this chaff. for example, if someone only wants to come to nanog for the hallway discussions and not attend any of the meetings or bofs (or eat any of the food, or use the wireless), are they welcome? before last week i'd've said "yes." manners in this case means "what should others be allowed to do" rather than "what each of us would like to be able to do", or in other words, "what will scale?"
I still don't see that you fall into this category with regard to this incident.
from my personal e-mail so far, that view is in the minority. ("this is not your grandfather's nanog.") on the other hand i really would rather talk about DLV than "meeting manners."
i really would rather talk about DLV than "meeting manners."
cool! or we should at least take meeting manners and registration policies over to nanog-futures. but, if you want to talk about dlv, could you answer my questions? 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
Randy, On Jun 12, 2006, at 9:56 AM, Randy Bush wrote:
as providing a tld key registry is tantamount to emulating the root key responsibilities of the iana,
While I might wish otherwise, IANA does not have root key responsibilities.
potential users should be rather concerned.
If they're concerned, then I would imagine they can wait until the root is signed. Rgds, -drc
Paul Vixie wrote: [some other stuff]
on the other hand i really would rather talk about DLV than "meeting manners."
I'd like to hear about DLV. For example, Randy Bush asked (twice) the following:
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?
I would also like to understand the security policy, and to hear how DLV at ISC will handle key roll-over and revocation.
as providing a tld key registry is tantamount to emulating the root key responsibilities of the iana, potential users should be rather concerned.
-- "...any language that actually pays attention to white space is the spawn of pure oozing black evil from the 29th layer of the deepest hell imaginable" --Phil Dibowitz, on Python
I'd like to hear about DLV. For example, Randy Bush asked (twice) the following:
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?
I would also like to understand the security policy, and to hear how DLV at ISC will handle key roll-over and revocation.
since joao is probably still sleeping-off the time shift from san jose to madrid, i'll chime in here. the last plan i saw was the same as the last draft i heard about for what any other "important" zone would do with a key that has to be hard coded in a lot of places: allocate more than one KSK and an infinite lifetime. use this KSK offline (only), to generate ZSK's with short lifetimes that are in turn used online to sign the zone. many are those argue that DNSSEC-bis, having failed to address key-rollover, is unimplementable. DNSSEC-ter may or may not come about (depending on the contining faith and patience of those who funded DNSSEC and DNSSEC-bis) in order to (a) prevent zone-walking, (b) allow for unsecured subdelegations, and (c) automate key-rollover. (that's NSEC3 and TAKREM in a nutshell.) on the other hand i believe that DNSSEC-bis is good enough to solve some real world problems, and that the thing that makes it unimplementable is merely its dependence on cooperation between US-DoC, ICANN, and VeriSign around the myriad issues touched on by the "sign the root zone" work item. that's why ISC is helping (under contract to VeriSign and Nominet) with NSEC3 and stands ready to help with automated trust anchor work as well-- these are important problems. if hand-edited trust anchors backed by infinite-lifetime offline KSK's are unacceptable to you, then you are already not a candidate for DNSSEC-bis and you're going to be waiting for DNSSEC-ter. so, no complaints about the fact that DLV uses the only thing DNSSEC-bis specifies in that area, unless you have a proposal for automated rollover that's as easy to implement as DLV was, and IPR-unencumbered, in which case, send it over!
as providing a tld key registry is tantamount to emulating the root key responsibilities of the iana, potential users should be rather concerned.
"tantamount" is an unruly word, it accuses without specification. in any case anyone who is concerned about DLV should seek alternatives, such as: | 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." and i forgot to mention: 5. forget about DNSSEC until all these problems are solved by others. whichever (or whatever else related) you want to do, you can count on ISC's support. just don't count on ISC's inaction; ISC isn't adept at inaction. that URL again is <http://www.isc.org/ops/dlv/>. -- Paul Vixie
On Mon, Jun 12, 2006 at 09:41:03PM +0000, Paul Vixie wrote:
since joao is probably still sleeping-off the time shift from san jose to madrid, i'll chime in here. the last plan i saw was the same as the last draft i heard about for what any other "important" zone would do with a key that has to be hard coded in a lot of places: allocate more than one KSK and an infinite lifetime. use this KSK offline (only), to generate ZSK's with short lifetimes that are in turn used online to sign the zone.
At NANOG 37, possibly after you had left the room, Randy actually asked if we were writing a document describing ISC's operational guidelines and policies for the dlv zone. All those things DRC recently said no one has told him to do yet. It's in that context I think that he asks these questions now. I got the idea Randy was looking for info like appears in the BCP that describes root server operations requirements, except as applies to our DLV zone (and probably not an IETF document). So, how many boxes have the private keys? What barriers lock them away? How many people have access to the raw keys? How many authoritative servers give out dlv.isc.org and where do they sit in the network and on the globe? Do you pre-publish or double-sign (or triple-sign (or quintuple-sign (or ...)))? I have no idea if such a thing exists or plans to exist, or what might appear inside it.
| 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 | 3. rubber-stamp ISC's DLV design, adopt our BSD-licensed source code | 4. go to IETF and say "i think something DLV should be a standard but 5. forget about DNSSEC until all these problems are solved by others.
Even if I choose not to do any of those 5 things and adopt ISC's DLV registry, I probably would want some basis to compare ISC's DLV registry with Acme's DLV registry. Having a basis to compare ourselves with...an imagined ideal of ourselves...is a bit of an intellectual excercise, but it does set the bar for future work in similar operations, such as signing TLDs and the root zone (wether it is IANA who is asked to do it or not). And it helps people decide if they want to throw in or wait it out for someone with stronger practices (or deploy a DLV with stronger practices). I personally think Randy's request (or my imagined version of same) would be good reading, if someone could be found who had both the time and knowledge to write it, and if doing so wouldn't be construed as giving away the keys to the castle. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins
I got the idea Randy was looking for info like appears in the BCP that describes root server operations requirements, except as applies to our DLV zone (and probably not an IETF document).
actually, i think it most important that a proposed dlv service make very clear its security policy and process in vetting the correctness of the data it serves, i.e. the trust anchors for dependent zones. once one can have confidence in the correctness of the data served, one might then become inclined to worry about the reliability of the service :-). randy
On Tue, Jun 13, 2006 at 01:18:06AM -0700, Randy Bush wrote:
actually, i think it most important that a proposed dlv service make very clear its security policy and process in vetting the correctness of the data it serves, i.e. the trust anchors for dependent zones.
Oh, you're asking specifically for more detail than is on our web page, then ('Registering your zone key in the DLV tree'). You mentioned that this would have relevance to future practices should the root be signed, and I can't for the life of me see how. I think this is an artificial problem that arises only for ISC since we're out of the delegation loop (except where we can authenticate registries and receive trust anchors from them). Do you imagine that, if IANA/ICANN/USDOT/someone were told to implement a policy to sign the root, that they would have trouble identifying the owners of the TLD's reliably? If so, wouldn't this problem already exist today in the information already present in the root zone?
once one can have confidence in the correctness of the data served, one might then become inclined to worry about the reliability of the service :-).
-- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins
Hi, On Jun 13, 2006, at 8:47 AM, David W. Hankins wrote:
Do you imagine that, if IANA/ICANN/USDOT/someone were told to implement a policy to sign the root, that they would have trouble identifying the owners of the TLD's reliably?
Yes. And it isn't a question of signing the root -- that just makes it more ... fun. It is a generic authentication problem that crops up anytime there is any change to the root. Fortunately, the root community is relatively small and well defined and IANA has evolved processes that, while sub-optimal, do generally work.
If so, wouldn't this problem already exist today in the information already present in the root zone?
Yes. However, I believe you all are proposing to remove the "relatively small and well defined" component that helps IANA deal with the issue on a daily basis. A hard problem. Rgds, -drc
I think this is an artificial problem that arises only for ISC since we're out of the delegation loop (except where we can authenticate registries and receive trust anchors from them).
if other non-delegators run dlv services, they will have the same issues. and if you are a delegator, why play dlv as you can directly sign?
Do you imagine that, if IANA/ICANN/USDOT/someone were told to implement a policy to sign the root, that they would have trouble identifying the owners of the TLD's reliably?
how they validated that the keys they sign are correct would be an issue, for sure. but we have some idea of the iana's relationship with the tld zone holders, though, like many things, that could certainly be improved. the isc web page now says Before it is accepted into the dlv.isc.org zone, ISC will perform checks to ensure the keys are being used in the requested zone, that the persons making the request are who they claim to be and that they are authorised by the domain holder to request the inclusion of the keys in the zone. This check will require an in-person meeting with authorised ISC staff to verify documentation. so, there will be strange travel costs incurred, but we have no idea what actual checks will be done. when charles mussisi flies from kampala to redwood city, will he be expected to have brougt the zone key with him on cdrom or something, and you'll check his passport against the iana cctld registry and then accept the key? and, when the iana redelates the UG zone, how will you know this and stop handing out a bogus key?
If so, wouldn't this problem already exist today in the information already present in the root zone?
yep. and iana goes through some non-trivial exercises to validate that they are delegating 'correctly' as defined by 1591 and other documents. and those of us in the tld game are aware of them in some detail, irrespective of our opinion of them. luckily, they do not require people to pay airlines. all i am asking is that isc publish *how* it will validate the correctness of the zone trust keys they sign and provide under their proposed dlv service. e.g., how do you propose to check that the cctld, e.g. NG or UG, for which your proposed dlv service might yield a key is indeed the real NG or UG zone key? randy
On 13-Jun-2006, at 13:27, Randy Bush wrote:
the isc web page now says
Before it is accepted into the dlv.isc.org zone, ISC will perform checks to ensure the keys are being used in the requested zone, that the persons making the request are who they claim to be and that they are authorised by the domain holder to request the inclusion of the keys in the zone.
This check will require an in-person meeting with authorised ISC staff to verify documentation.
so, there will be strange travel costs incurred, but we have no idea what actual checks will be done. when charles mussisi flies from kampala to redwood city, will he be expected to have brougt the zone key with him on cdrom or something, and you'll check his passport against the iana cctld registry and then accept the key?
I don't profess to speak for ISC here, but it may be worth noting that ISC staff continue to spend a lot of time travelling to operator meetings, workshops, root server installations and RIR and ICANN meetings. Outreach and community participation is one of the core things that ISC does. It's not unreasonable to think that for a lot of zone operators (ccTLD or otherwise), the mountain will eventually come to Mohammed, and travel by the zone operator won't be necessary. In the case of Uganda, by way of example, I've met Charles in person several times, and I'm sure we will do so again. I remain on ISC's books as an unpaid volunteer. If I can help Charles and ISC on some mutually-agreeable project I would of course be happy to. The social tendrils of ISC run longer and deeper than many people realise. Perhaps this is one of the things that makes ISC a good organisation to anchor projects like DLV.
and, when the iana redelates the UG zone, how will you know this and stop handing out a bogus key?
I can't answer that question. My expertise in this area is less about the crypto, and more about the beer :-) Joe
I don't profess to speak for ISC here, but it may be worth noting that ISC staff continue to spend a lot of time travelling to operator meetings, workshops, root server installations and RIR and ICANN meetings. Outreach and community participation is one of the core things that ISC does.
It's not unreasonable to think that for a lot of zone operators (ccTLD or otherwise), the mountain will eventually come to Mohammed, and travel by the zone operator won't be necessary.
can you say "does not scale?" or how about "works poorly when a zone is transferred?" i think there is no question that you and isc mean well. but we've entered the the twisty passages of security. randy
On 13-Jun-2006, at 14:37, Randy Bush wrote:
I don't profess to speak for ISC here, but it may be worth noting that ISC staff continue to spend a lot of time travelling to operator meetings, workshops, root server installations and RIR and ICANN meetings. Outreach and community participation is one of the core things that ISC does.
It's not unreasonable to think that for a lot of zone operators (ccTLD or otherwise), the mountain will eventually come to Mohammed, and travel by the zone operator won't be necessary.
can you say "does not scale?"
Indeed. With the current trust policy, it seems to me that DLV is a bootstrap mechanism intended to promote bottom-up pressure for DNSSEC deployment, and to give people a chance to get to grips with things like key rollover and zone signing. It's a frog dressed up as a chicken which is being rolled out because people are fed up waiting for an egg. In that context, perhaps it doesn't need to scale very far. Joe
With the current trust policy, it seems to me that DLV is a bootstrap mechanism intended to promote bottom-up pressure for DNSSEC deployment, and to give people a chance to get to grips with things like key rollover and zone signing.
well, unlike ipv6 marketing efforts, at least it does not create an unrecoverable mess in routing.
It's a frog dressed up as a chicken which is being rolled out because people are fed up waiting for an egg.
In that context, perhaps it doesn't need to scale very far.
perhaps the bottom line is whether it makes us more vulnerable. while an incorrectly secured zone is arguably no worse than one which is not secured, it seems to create a focus for attack. but what leaves me wondering is why this is all so difficult. why can isc not simply say "we plan to vet zones as follows:. and we plan to manage maintenance of key rollover as follows: etc.?" randy
On Jun 13, 2006, at 11:55, Randy Bush wrote:
but what leaves me wondering is why this is all so difficult.
Possibly because many people find writing formal security policies, which I think is what we're really talking about here, to be a dry and unpleasant experience, much less fun that code-hacking or packet- analyzing or whatever else you can find to do instead.
why can isc not simply say "we plan to vet zones as follows:. and we plan to manage maintenance of key rollover as follows: etc.?"
Would it help if I volunteered to talk to folks and help write something up? I mean, if there's some other issue that is preventing ISC from nailing this down, then that's one thing. But if it's just a case of "never seems to bubble up to the top of the stack", then maybe a little outside assistance can do the trick. Besides, now that the semester's over, I need something besides just firing off resumes (gotta fill that summer time, and not completely lose touch with the Real World!) to keep myself entertained. You may flame when ready, Gridley. -- Brian McMahon <brian dot mcmahon at cabrillo dot edu> Computer Networking and System Administration Instructor Cabrillo College, Aptos, California
brmcmaho@cabrillo.edu (Brian McMahon) writes:
why can isc not simply say "we plan to vet zones as follows:. and we plan to manage maintenance of key rollover as follows: etc.?"
Would it help if I volunteered to talk to folks and help write something up?
not at the moment. joao heard this question at the podium, and i've touched on it since then, and there doesn't seem to be any reason (yet) to assume that the answer won't be posted to www.isc.org/ops/dlv/ soon.
I mean, if there's some other issue that is preventing ISC from nailing this down, then that's one thing.
i believe it's called "jet lag".
But if it's just a case of "never seems to bubble up to the top of the stack", then maybe a little outside assistance can do the trick.
i don't think so. no bank in its right mind, for example, would allow its identity to be held or represented by a middleman whose security policies weren't auditable. on the other hand, joao heard this question at the podium and i don't think it's time yet to declare USC "late" answering it.
Besides, now that the semester's over, I need something besides just firing off resumes (gotta fill that summer time, and not completely lose touch with the Real World!) to keep myself entertained.
You may flame when ready, Gridley.
isc depends on a lot of volunteers, i'm happy to hear of your availability and i assume that joao will also be happy to hear it when he catches up on nanog@. -- Paul Vixie
please reconcile
no bank in its right mind, for example, would allow its identity to be held or represented by a middleman whose security policies weren't auditable.
with
this is why we're trying to sign up some registrars, starting with alice's, who can send us blocks of keys based on their pre-existing trust relationships.
i think you might see why i am confused. do you propose to audit alice? as rick says, this is unfortunately trivial, as the signed registrations are zero <sigh>. btw, i fully admit that i have not thought through a detailed policy and process for a dlv registry. then again, i am not proposing to deploy one. yep, criticism is cheap. but then, i have not charged much :-). like some other technologies i'll not mention in this message, dnssec has been a typical non-deployable ivtf mis-design by committee for half the lifetime of the internet itself. [ i left a long trail of "this is badly broken. someone should have listened to masataka." but have no idea if his 1/3 baked scheme would have flown. ] and i sympathize with your desire to get any useful flight milage out of the disaster. but, as this is a security service, please register your flight plan. randy
... and alice has been working on deploying the .org DNSSEC testbed for 6 months now. Thus far my experence with deploying DNSSEC is: its just hard, not fun and for a lack of a better word... it SUCKS. In the last 6months since we deployed it, not one sole has clicked on the [now broken] _SECURE DOMAIN_ link to enable .ORG dnssec capabilities. I know we are a tiny registrar but none of our clients thought it important enough to even try clicking on the _SECURE DOMAIN_ link. So, even DLV is going to take a tremendous marketing effort to get folks to differentiate it from LOCK_DOMAIN which merely prevents the domain from being updated or transfered. DLV is a huge task so be supportive because it will probably fail just like DNSSEC is ...but we might just learn something. -rick Paul Vixie wrote:
can you say "does not scale?" Indeed.
this is why we're trying to sign up some registrars, starting with alice's, who can send us blocks of keys based on their pre-existing trust relationships.
On Tue, 13 Jun 2006, Rick Wesson wrote:
... and alice has been working on deploying the .org DNSSEC testbed for 6 months now. Thus far my experence with deploying DNSSEC is: its just hard, not fun and for a lack of a better word... it SUCKS.
In the last 6months since we deployed it, not one sole has clicked on the [now broken] _SECURE DOMAIN_ link to enable .ORG dnssec capabilities.
I know we are a tiny registrar but none of our clients thought it important enough to even try clicking on the _SECURE DOMAIN_ link. So, even DLV is going to take a tremendous marketing effort to get folks to differentiate it from LOCK_DOMAIN which merely prevents the domain from being updated or transfered.
DLV is a huge task so be supportive because it will probably fail just like DNSSEC is ...but we might just learn something.
Not every domain out there needs what DNS-SEC can give. Not every domain out there is for a legit site, even if it will use DNS-SEC. A site that cares about its domain being verified as being the right site, would use DNS-SEC. Banks, the root servers, eCommerce, etc. Problem is, in the days of attacks against organizations being directed at users, the verifying client can be thrown aside. That said, it's less problems to fight and makes one front more secure - which is the infrastructure. Strike, that, less of a wh*re for everyone to (ab)use. Gadi.
-rick
Paul Vixie wrote:
can you say "does not scale?" Indeed.
this is why we're trying to sign up some registrars, starting with alice's, who can send us blocks of keys based on their pre-existing trust relationships.
can you say "does not scale?" Indeed. this is why we're trying to sign up some registrars, starting with alice's, who can send us blocks of keys based on their pre-existing trust relationships.
so a key roll or change of delegation requires two levels of human intervention to work? randy
On Tue, 13 Jun 2006, Randy Bush wrote:
can you say "does not scale?" Indeed. this is why we're trying to sign up some registrars, starting with alice's, who can send us blocks of keys based on their pre-existing trust relationships.
so a key roll or change of delegation requires two levels of human intervention to work?
DNS-SEC will live and die on the business model. How user-friendly it is vs. how necessary it is against what alternatives there are. To be honest, waiting for so many years for DNS-SEC, if these questions were not answered by now...
randy
... we're trying to sign up some registrars, starting with alice's, who can send us blocks of keys based on their pre-existing trust relationships.
so a key roll or change of delegation requires two levels of human intervention to work?
no. in the normal, non-DLV DNSSEC-bis model, a registrant informs its registrar of new KSK's before existing KSK's expire (or perhaps during revocation events) using the same authenticated automation they would use to change NS RRs or arrange for payment of fees or whatever. the registrar (like alice's for ISC) then tells the appropriate registry (like Afilias-PIR-UltraDNS, for .ORG) the new DS RR data using the same (EPP? RRP? fax? carrier pigeon?) authenticated automated model they would use when changing NS RR data. no human intervention at all. in the DLVified DNSSEC-bis model, the DNS registry (like VeriSign for .COM) is not yet accepting DS RR data via their EPP interface to their registrars, although i note with admiration that VeriSign has led the effort to add new EPP protocol elements to support this new data. as far as i know, no existing DNS registry will accept DS RR data. therefore registrars (like alice's... remember alice? this is a song about alice) have no place to go with registrant KSK data at this time. this in turn keeps most registrars from bothering to collect or store this "useless" data. ISC proposes to accept this KSK data (in the form of DLV RRs) via authenticated automated processes whereby "lots of keys" can be sent to us by interested/participating registrars. we do not have a good way of knowing whether somebody is or isn't the registrant for bankofamerica.com, but we think that bank of america's registrar does have a way of authenticating the registrant. and we know how to authenticate bankofamerica.com's registrar. so there IS a more scalable, untouched-by-human-hands, trust path available. until we get that working, we're left with the least desireable alternative, which is accepting keys directly from registrants, and authenticating these folks the hard way, with human hands and eyeballs. alas, i repeat myself. i've said this already. and if folks aren't going to read the explainations i really need to discipline myself into not repeating them.
DNS-SEC will live and die on the business model. How user-friendly it is vs. how necessary it is against what alternatives there are.
To be honest, waiting for so many years for DNS-SEC, if these questions were not answered by now...
to be equally honest, i'm now weary of hearing what can't be done or shouldn't be done. anyone who wants to not do dnssec is free to do that, they don't need to shout it from the rooftop. anyone else who wants to wait until the root is signed and NSEC3 is done and automated trust key rollover is done is welcome to wait -- no shouting is required from any rooftop by those, either.
therefore registrars (like alice's... remember alice? this is a song about alice) have no place to go with registrant KSK data at this time. this in turn keeps most registrars from bothering to collect or store this "useless" data. ISC proposes to accept this KSK data (in the form of DLV RRs) via authenticated automated processes whereby "lots of keys" can be sent to us by interested/participating registrars. we do not have a good way of knowing whether somebody is or isn't the registrant for bankofamerica.com, but we think that bank of america's registrar does have a way of authenticating the registrant. and we know how to authenticate bankofamerica.com's registrar. so there IS a more scalable, untouched-by-human-hands, trust path available.
thanks for actual technalia. ( first, i suspect much of the confusion could come from your thinking that the place up on skyline is *the* alice's restaurant. it isn't. the real one was in stockbridge, mass, and rather short-lived. so you can see why one might wonder about isc's validation methods. :-) i think if you amplified on and detailed the above, and went into how re-delegation and key changes would handled, it would go a long way to clarifying the isc dlv registry's security process. you're also welcome to use some of the cctlds and other zones i manage as outlying/strange examples. e.g. NG, which i could sign, but neither ng nor i have an established relationship to isc. and then i hope to get rid of it soon (been working with the in-country folk for five years on this, and the illumination at the end of the tunnel might be a light as opposed to a train!), and how it would be rolled would be of interest. and say psg.com, registered through retsiger, who we might assume, for sake of example, will not play. randy
On Tue, Jun 13, 2006 at 11:37:08AM -0700, Randy Bush wrote: ...
can you say "does not scale?" ... ...
I think ISC very clearly already said that. They do not WANT it to scale. They _WANT_ DNSSEC to succeed and take over. This is a bootstrap mechanism to get DNSSEC rolling. -- Joe Yao ----------------------------------------------------------------------- This message is not an official statement of OSIS Center policies.
At 11:37 -0700 6/13/06, Randy Bush wrote:
can you say "does not scale?" or how about "works poorly when a zone is transferred?"
There are two ways to look at "scaling". Scaling in volume and scaling across generations. DLV definitely does not scale across generations with such a person-to-person protocol backing it up. But if it's just a bootstrap mechanism, then I think it's acceptable. As far as volume scale, DLV puts more work onto whomever configures DLV repository data in resolvers. A DLV per TLD might lower the work for the TLD, and possibly remove the need to develop NSEC3 and opt-in. (As DLV only lists the DNSSEC'd zones.)
i think there is no question that you and isc mean well. but we've entered the the twisty passages of security.
DLV at least lets those who are able and willing to take the risk to gain first hand experience. If the ISC DLV runs for 5 years without an incident, even with the non-scalable approach as documented, it'll be seen as a winner. The longer it runs without incident, the more trustworthy it'll (appear to) be, right up until the point that it no longer scales. If there's an incident, then it won't be trusted but we will probably learn from the experience. Hopefully the lesson will come cheap. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain...
On Tue, 13 Jun 2006, Randy Bush wrote:
I don't profess to speak for ISC here, but it may be worth noting that ISC staff continue to spend a lot of time travelling to operator meetings, workshops, root server installations and RIR and ICANN meetings. Outreach and community participation is one of the core things that ISC does.
It's not unreasonable to think that for a lot of zone operators (ccTLD or otherwise), the mountain will eventually come to Mohammed, and travel by the zone operator won't be necessary.
can you say "does not scale?" or how about "works poorly when a zone is transferred?"
Almost anyone on this list would have been at the NANOG meeting -- in my case, I'd spoken with Joao weeks ago about establishing this for my own zone -- suggesting that since I'm in NYC (right near the F-root) that someone should be close. While ISC doesn't have anyone routinely in NYC, that was actually one of his questions "are you going to be at NANOG?" -- and had it not been for a conflict of vacation time for something I have to attend THIS weekend, I would likely have been there, and this would heva been a done deal, at least on my end. People's PGP keys get signed by people they know and meet in person, but people don't allocate travel budgets to get it done (unless your name was Phil Zimmerman back in the day when PGP was the indespensible sellable "product"). -Dan
i think there is no question that you and isc mean well. but we've entered the the twisty passages of security.
randy
-- "I love you forever eternally." -Connaian Expression --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org ---------------------------
On Tue, Jun 13, 2006 at 10:27:49AM -0700, Randy Bush wrote:
if other non-delegators run dlv services, they will have the same issues.
Absolutely.
and if you are a delegator, why play dlv as you can directly sign?
I think Paul answered this question (it's because of the way DNSSEC-bis proves non-existence). I basically can't answer your other questions. I don't know the answers to most of them and don't want to guess at the others. And as for IANA applicability, I guess I'll have to give up and defer to you and DRC. It still sounds wonky to me that you would operate the root's authentication chain out-of-band like a DLV registry when in-band seems so much more useful and reliable. But clearly I don't know enough about the root's (scary) problems.
when charles mussisi flies from kampala to redwood city,
I think our staff in Europe are closer to Kampala than 950 Charter, and I assume at least one of them would be authorized, and I assume that there are some events somewhere that both Mr. Mussisi and some authorized member of our staff are likely to both attend. But if you would like to imagine for a moment that we actually require people to meet us in a faraday cage embedded 30 feet under the Arctic ice in an undisclosed location - just take a metal detector with you and knock on the ice when you think you've found us - then which of Paul's list of 5 other options would you prefer? Or is there a 6th? How soon can you start? That's an important open question in this dialogue. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins
participants (13)
-
Brian McMahon -
Dan Mahoney, System Admin -
David Conrad -
David W. Hankins -
Edward Lewis -
Etaoin Shrdlu -
Gadi Evron -
Joe Abley -
Joseph S D Yao -
Paul Vixie -
Paul Vixie -
Randy Bush -
Rick Wesson