Re: wrt joao damas' DLV talk on wednesday
actually, in a brilliant demonstration of fair use of copyrighted lyrics, paul was quoting directly from the song about alice's restaurant. well, actually, despite saying so, it's not much about the restaurant at all. and the restaurant is not called alice's restaurant, that's just the name of the song. And this whole discussion about DNSSEC and DLV reminds me of a bunch of 8 x 10 glossy photographs with the circles and arrows and a paragraph on the back of each one. Just another case of American blind justice I suppose. Has anyone ever considered trying to come up with a way that these crypto projects could be explained in plain English? I think a lot of the problem with adoption of DNSSEC stems from the fact that most people who might make a decision to use it, haven't got a clue what it is, how it works, or whether it even works at all. And it's not their fault that they don't understand. It's the fault of a technical community that likes to cloak its discussions in TLAs and twisted jargon. --Michael Dillon
Re: wrt joao damas' DLV talk on wednesday
Has anyone ever considered trying to come up with a way that these crypto projects could be explained in plain English? yes. I think a lot of the problem with adoption of DNSSEC stems from the fact that most people who might make a decision to use it, haven't got a clue what it is, how it works, or whether it even works at all. then they should go read steve crocker and russ mundy's most excellent www.dnssec-deployment.org. And it's not their fault that they don't understand. It's the fault of a technical community that likes to cloak its discussions in TLAs and twisted jargon. that's just bitterness, though. -- Paul Vixie
Re: wrt joao damas' DLV talk on wednesday
On Tue, 13 Jun 2006, Randy Bush wrote: snip how about cctlds, which are of great interest to me? i suspect that iana will not play, so how would cctlds play in way in which i can bet my bippies? and how it would be rolled would be of interest. key-roll through DLV is no different, from the high level, that key roll through non-DLV. either way you have to instantiate a new key and get it to your registry somehow (either through your registrar or otherwise) before you start using it. how do i enroll NG in a way that third parties can reasonably know is trustable? from the policy and process pov, how will we move it to a new zone set and server set when i get rid of it? along these lines - there seem to be a huge number of smallish tools related to DNSSEC, but I don't find anything that looks like a package with a couple of tools and scripts that would be usable by a small ccTLD - recommendations and good written exercises that step a newbie through the process would be very useful - any pointers? I've already looked at: http://www.dnssec-deployment.org./ http://www.dnssec.net/software http://www.ripe.net/disi/dnssec_howto/ http://www.dnssec-tools.org/ lots of info - but a cheat sheet and some recommendations for basic tools are needed to get this deployed and used. is this the current state-of-the-art? http://www.dnssec-tools.org/docs/step-by-step-dnssec-tools/sbs-dt.pdf similarly, how do i enroll psg.com in a way third parties can trust? how do we handshake in a clearly documented process- and key-wise exchange that gives third parties reason to be confident in the validity of the key isc hands out for psg.com? and anyone whose registrar won't play, will have to follow the procedure outlined on www.isc.org/ops/dlv/, which involves much manual labour, but can be done. (see http://www.isc.org/ops/dlv/#how_register in particular.) says not much about how things will actually be verified. only that isc will vet, i will fly, ... heck, for an org, it does not even state that corp docs of the flavors rirs use for transfers will be needed/used. i suspect that where we may be differing, other than restaurant lore, is that you may be saying the underlying technology is documented, and isc are good folk and if we say it's vetted you can trust us. problem is that, though i may want to trust isc (heck, i run isc's code!), for a security exercise, i should not. an example of some rigor in policy and process needs to be set. randy -- Lucy E. Lynch Academic User Services Computing CenterUniversity of Oregon llynch @darkwing.uoregon.edu (541) 346-1774
Re: wrt joao damas' DLV talk on wednesday
At 10:20 +0100 6/14/06, [EMAIL PROTECTED] wrote: Has anyone ever considered trying to come up with a way that these crypto projects could be explained in plain English? I think a lot of Over and over and over and over again. (Not to say we've done enough! but we've done all we can think of.) 1) Google for DNSSEC introduction 2) Look at http://www.dnssec.net/ 3) This has no crypto: http://apricot.net/apricot2005/slides/T11-3.pdf (a discussion of what it means to registries to pull it off) 4) Or this, for a NANOG presentation: (NANOG 32) http://www.nanog.org/mtg-0410/pdf/crocker.pdf If what you see isn't clear, ask the respective presenters. Maybe we haven't been clear enough. But, many have considered...maybe the only beneficiary has been the travel industry (through our buying of tickets/rooms). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain...
Re: wrt joao damas' DLV talk on wednesday
[ dunno to whom you are replying, but they miss the point, imiho ] Has anyone ever considered trying to come up with a way that these crypto projects could be explained in plain English? yes. to the best of my limited knowledge, the crypto has never been an issue with dnssec. it was done well from day zero, and has not changed. how it has been *used*, i.e. key management and use, have been the issues. e.g., the embarrassing deployment show-stopper (everything would have to roll at once) that delegation signer addressed. what still seems to remain poorly addressed is trust anchor management, e.g., roll and revocation of the root key. as far as i can tell, dlv attempts to address this by bypassing the root (from the dnssec aspect only). one half of what we seem to be trying to sort out is that it seems to have actually left the same problem, merely moving it to key management for the dlv servers' trust anchors. i don't know if there is hope for this one in the current design. is it like bogon filters, all who want to play are responsible for keeping abreast of changes and keeping their configs up to date? and dlv seems to add a new problem, needing to understand and feel comfortable with the policies and procedures by which dlv services vet and insert keys into their service. we know the policies of the iana and the root, whether we like them or not. i suspect and hope that this one can be relatively easily addressed, at least as far as isc's proposed service goes, by some specs from isc, joao's jet lag permitting and if the water don't rise (tm sra). dlv also sidesteps the layer 8..42 issues with the iana taking responsibility and authority for signing the root zone. reading drc's posts, this seems to be a wise move, though sad and somewhat embarrassing to see. but it ain't the crypto. never has been. and it is not always easy to explain math in plain english. so let's focus on where work needs to be done. randy
Re: wrt joao damas' DLV talk on wednesday
lurkmodeoffofftopicmodeon Shoes for Industry! - Joe Beets :-) /lurkmodeoff/offtopicmodeon At 01:04 PM 6/12/2006, you wrote: Paul may be special ... nope. we're all just bozos on this bus.
Re: [nanog] Re: wrt joao damas' DLV talk on wednesday
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 ---
Re: wrt joao damas' DLV talk on wednesday
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
Re: wrt joao damas' DLV talk on wednesday
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. HankinsIf 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
pgp9Ou6ZZGlFt.pgp
Description: PGP signature
Re: wrt joao damas' DLV talk on wednesday
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
Re: wrt joao damas' DLV talk on wednesday
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
Re: wrt joao damas' DLV talk on wednesday
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
Re: wrt joao damas' DLV talk on wednesday
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
Re: wrt joao damas' DLV talk on wednesday
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
Re: wrt joao damas' DLV talk on wednesday
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
Re: wrt joao damas' DLV talk on wednesday
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
Re: wrt joao damas' DLV talk on wednesday
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.
Re: wrt joao damas' DLV talk on wednesday
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...
Re: wrt joao damas' DLV talk on wednesday
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. -- Paul Vixie
Re: wrt joao damas' DLV talk on wednesday
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. HankinsIf 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 pgpPZ8bhnevTH.pgp Description: PGP signature
Re: wrt joao damas' DLV talk on wednesday
... 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.
Re: wrt joao damas' DLV talk on wednesday
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.
Re: wrt joao damas' DLV talk on wednesday
[EMAIL PROTECTED] (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 [EMAIL PROTECTED] -- Paul Vixie
Re: wrt joao damas' DLV talk on wednesday
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
Re: wrt joao damas' DLV talk on wednesday
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
Re: wrt joao damas' DLV talk on wednesday
... 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.
Re: wrt joao damas' DLV talk on wednesday
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
Re: wrt joao damas' DLV talk on wednesday
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
Re: wrt joao damas' DLV talk on wednesday
From: Randy Bush [EMAIL PROTECTED] Date: Tue, 13 Jun 2006 15:16:50 -0700 To: Paul Vixie [EMAIL PROTECTED] Cc: nanog@merit.edu Subject: Re: wrt joao damas' DLV talk on wednesday 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. :-) Actually, Paul might have been talking about Alice, Bob, and Mike. Well knows personages in cryptography circles. Alice and Bob want to exchange keys Mike is in the middle trying to figure out what alice and Bob are up to and also trying to thwart the exchange if possible. Or at the very least, gain knowledge of the keys so that Mike can read Alice's and Bob's message traffic. 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 --- Gregory Hicks| Principal Systems Engineer Cadence Design Systems | Direct: 408.576.3609 555 River Oaks Pkwy M/S 6B1 | Fax: 408.894.3400 San Jose, CA 95134 | Internet: [EMAIL PROTECTED] I am perfectly capable of learning from my mistakes. I will surely learn a great deal today. A democracy is a sheep and two wolves deciding on what to have for lunch. Freedom is a well armed sheep contesting the results of the decision. - Benjamin Franklin The best we can hope for concerning the people at large is that they be properly armed. --Alexander Hamilton
Re: wrt joao damas' DLV talk on wednesday
thanks for actual technalia. i've also been warned that this isn't ops-related and told to move elsewhere. ( first, i suspect much of the confusion could come from your thinking that the place up on skyline is *the* alice's restaurant. *the* alice's restaurants are the ones in our own private idaho's. 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. i feel sure that joao said at the podium that he would do that and put it on the www.isc.org/ops/dlv/ web site. so, you're just selling after the close. 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. it's possible that no trust path can be found for some domains. for example, i cannot imagine who could represent the root zone for the purpose of sending in a key for it. (not that DLV has a way to publish the root key; it doesn't; i'm just using the root as the ideal strange example of this problem.) and how it would be rolled would be of interest. key-roll through DLV is no different, from the high level, that key roll through non-DLV. either way you have to instantiate a new key and get it to your registry somehow (either through your registrar or otherwise) before you start using it. either way you have to remove your old keys after you've stopped using them. either way you'll have two keys in your key registry (either DLV or DNS) during the rollover. the only thing that changes with DLV is that you actually *have* someone to send your key to even if your DNS registrar and/or DNS registry isn't ready to accept/publish them yet. and say psg.com, registered through retsiger, who we might assume, for sake of example, will not play. anyone whose registrar won't play, will have to follow the procedure outlined on www.isc.org/ops/dlv/, which involves much manual labour, but can be done. (see http://www.isc.org/ops/dlv/#how_register in particular.)
Re: wrt joao damas' DLV talk on wednesday
therefore registrars (like alice's... remember alice? this is a song about alice) ( 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. :-) Actually, Paul might have been talking about Alice, Bob, and Mike. Well knows personages in cryptography circles. Alice and Bob want to exchange keys Mike is in the middle trying to figure out what alice and Bob are up to and also trying to thwart the exchange if possible. Or at the very least, gain knowledge of the keys so that Mike can read Alice's and Bob's message traffic. actually, in a brilliant demonstration of fair use of copyrighted lyrics, paul was quoting directly from the song about alice's restaurant. well, actually, despite saying so, it's not much about the restaurant at all. and the restaurant is not called alice's restaurant, that's just the name of the song. although i occasionally slum in the security community, i am not aware of a similar song about alice, bob, and mike; though i am more used to other attackers than mike. it might help if you were a 20-something in the '60s. then again, it is not helping me a lot these years. but perhaps we have gone adrift. randy
OT!!! Re: wrt joao damas' DLV talk on wednesday
On Tue, Jun 13, 2006 at 03:21:23PM -0700, Gregory Hicks wrote: From: Randy Bush [EMAIL PROTECTED] Date: Tue, 13 Jun 2006 15:16:50 -0700 To: Paul Vixie [EMAIL PROTECTED] Cc: nanog@merit.edu Subject: Re: wrt joao damas' DLV talk on wednesday therefore registrars (like alice's... remember alice? this is a song about alice) ... ... ( 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. :-) Actually, Paul might have been talking about Alice, Bob, and Mike. ... While Vixie segued into one of our old fav'rite songs from back when, he was actually originally talking about http://www.ar.com/. Look at the context. [And if Rick Wesson wasn't thinking about that song when he named the registry, and about twenty-seven eight-by-ten colour glossy pictures with circles and arrows and a paragraph on the back of each one, and a judge with a seeing-eye dog (blind justice), and the American draft, and getting injected, inspected, detected, infected, neglected, and selected, and ending the war by a movement of singers of Arlo Guthrie's song ... well then, I'll tell you, I don't know W H A T he was thinking. ;-)] -- Joe Yao --- This message is not an official statement of OSIS Center policies.
Re: wrt joao damas' DLV talk on wednesday
thanks for actual technalia. i've also been warned that this isn't ops-related and told to move elsewhere. if it was not from the ml committee, tell whoever to foad. they would not know ops if it bit them on the bleep. 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. i feel sure that joao said at the podium that he would do that not really. he misunderstood my question and then waffled off into something directed at sam weiler that i think one needed to be steeped in ivtf bleep to understand. no blame. it was as if my question was off the wall, or i had stepped on a sore toe. i am good at both. it's possible that no trust path can be found for some domains. for example, i cannot imagine who could represent the root zone for the purpose of sending in a key for it. (not that DLV has a way to publish the root key; it doesn't; i'm just using the root as the ideal strange example of this problem.) how about cctlds, which are of great interest to me? i suspect that iana will not play, so how would cctlds play in way in which i can bet my bippies? and how it would be rolled would be of interest. key-roll through DLV is no different, from the high level, that key roll through non-DLV. either way you have to instantiate a new key and get it to your registry somehow (either through your registrar or otherwise) before you start using it. how do i enroll NG in a way that third parties can reasonably know is trustable? from the policy and process pov, how will we move it to a new zone set and server set when i get rid of it? similarly, how do i enroll psg.com in a way third parties can trust? how do we handshake in a clearly documented process- and key-wise exchange that gives third parties reason to be confident in the validity of the key isc hands out for psg.com? and anyone whose registrar won't play, will have to follow the procedure outlined on www.isc.org/ops/dlv/, which involves much manual labour, but can be done. (see http://www.isc.org/ops/dlv/#how_register in particular.) says not much about how things will actually be verified. only that isc will vet, i will fly, ... heck, for an org, it does not even state that corp docs of the flavors rirs use for transfers will be needed/used. i suspect that where we may be differing, other than restaurant lore, is that you may be saying the underlying technology is documented, and isc are good folk and if we say it's vetted you can trust us. problem is that, though i may want to trust isc (heck, i run isc's code!), for a security exercise, i should not. an example of some rigor in policy and process needs to be set. randy
howto deploy DNSSEC [was: Re: wrt joao damas' DLV talk on wednesday]
I'm ashamed to call myself a participant in NANOG, IETF and ICANN. every once in a while I get to participate in something that moves forward the network just a bit; please refrain from this thread -- a few folks are attempting to move DNSSEC ahead; we will fail, but would appreciate any constructive criticism on the pitfalls to deploy before we are all dead. -rick
re howto deploy DNSSEC [was: Re: wrt joao damas' DLV talk on wednesday]
I'm ashamed to call myself a participant in NANOG, IETF and ICANN. every once in a while I get to participate in something that moves forward the network just a bit; please refrain from this thread -- a few folks are attempting to move DNSSEC ahead; we will fail, but would appreciate any constructive criticism on the pitfalls to deploy before we are all dead. -rick I'm not. Consensus usually comes after the party, not before. -M -- Martin Hannigan(c) 617-388-2663 Renesys Corporation(w) 617-395-8574 Member of Technical Staff Network Operations [EMAIL PROTECTED]
Re: re howto deploy DNSSEC [was: Re: wrt joao damas' DLV talk on wednesday]
On Tue, 13 Jun 2006, Martin Hannigan wrote: I'm not. Consensus usually comes after the party, not before. I guess you've never been to IETF ... -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: howto deploy DNSSEC [was: Re: wrt joao damas' DLV talk on wednesday]
please refrain from this thread -- a few folks are attempting to move DNSSEC ahead; we will fail, but would appreciate any constructive criticism on the pitfalls to deploy before we are all dead. i am amazed that you do not consider open discussion of security policies and procedures to be used in the deployment of a security protocol to be constructive. imiho, over the years, dnssec has repeatedly suffered from not facing the reality of the sticky bits of deployment. so you may have to suffer folk discussing this, even though it may detract from dnssec marketing. randy
Re: wrt joao damas' DLV talk on wednesday
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 corporationchief 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
Re: wrt joao damas' DLV talk on wednesday
attending nanog wasn't an option. i hadn't realized that sitting in on joao's talk so i could be there for QA 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
Re: wrt joao damas' DLV talk on wednesday
michael, all, On Mon, Jun 12, 2006 at 10:43:16AM +0100, [EMAIL PROTECTED] 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 corporationchief 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 corporationchief of operations security [EMAIL PROTECTED] http://www.renesys.com/blog/todd.shtml
Re: wrt joao damas' DLV talk on wednesday
If Paul is present specifically and only for QA 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 bg or bofs or other portions of the conference. i was at the BG, 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.
Re: wrt joao damas' DLV talk on wednesday
Paul Vixie wrote: If Paul is present specifically and only for QA 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 bg or bofs or other portions of the conference. i was at the BG, 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
Re: wrt joao damas' DLV talk on wednesday
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
Re: wrt joao damas' DLV talk on wednesday
Paul Vixie wrote: I have not seen any writings that indicate that Paul was at bg or bofs or other portions of the conference. i was at the BG, 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 bg after checking with the host 2) You attempted to attend a qa 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.
RE: wrt joao damas' DLV talk on wednesday
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 smime.p7s Description: S/MIME cryptographic signature
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.
Re: wrt joao damas' DLV talk on wednesday
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
Re: wrt joao damas' DLV talk on wednesday
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
Re: wrt joao damas' DLV talk on wednesday
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 corporationchief of operations security [EMAIL PROTECTED] http://www.renesys.com/blog/todd.shtml
Re: wrt joao damas' DLV talk on wednesday
Paul may be special ... nope. we're all just bozos on this bus.
Re: wrt joao damas' DLV talk on wednesday
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
Re: wrt joao damas' DLV talk on wednesday
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
Re: wrt joao damas' DLV talk on wednesday
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
Re: wrt joao damas' DLV talk on wednesday
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
Re: wrt joao damas' DLV talk on wednesday
[EMAIL PROTECTED] (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
Re: wrt joao damas' DLV talk on wednesday
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 [EMAIL PROTECTED]
Re: wrt joao damas' DLV talk on wednesday
On Mon, Jun 12, 2006 at 09:41:03PM +, 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. HankinsIf 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 pgpTTO0IQk1fQ.pgp Description: PGP signature
wrt joao damas' DLV talk on wednesday
i intended to be present for the QA 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 QA 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
Re: wrt joao damas' DLV talk on wednesday
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
Re: wrt joao damas' DLV talk on wednesday
On Sun, Jun 11, 2006 at 06:50:05AM +, Paul Vixie wrote: i intended to be present for the QA 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 corporationchief of operations security [EMAIL PROTECTED] http://www.renesys.com/blog/todd.shtml
Re: wrt joao damas' DLV talk on wednesday
i intended to be present for the QA 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 QA 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.)
