Re: wrt joao damas' DLV talk on wednesday
From: Randy Bush <randy@psg.com> Date: Tue, 13 Jun 2006 15:16:50 -0700 To: Paul Vixie <paul@vix.com> 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: ghicks@cadence.com 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
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.)
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
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
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
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 Center University of Oregon llynch @darkwing.uoregon.edu (541) 346-1774
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
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
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
[ 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
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.
You and I are in violent agreement. The problem is in understanding whether or not the crypto under the hood really does provide a TRUSTABLE system. And that is more to do with policies and procedures. This is the stuff that I don't see explained in plain English so that the decision makers who rely on DNS can make a decision on DNSSEC. Ed Lewis pointed out two presentations which he claims have no crypto. However his own presentation at Apricot is laced with technical jargon including crypto. Stuff like "hierarchy of public keys", "DNSSEC data", "hash of the DNSKEY", "certificates", and so on. This is fine for a technical audience but it won't help explain the issue to the decision makers who spend the money. I understand how the crypto works to the extent that I believe it is technically possible for something like DNSSEC to work. However, I don't see an explanation of the policies and procedures that convinvces me that it DNSSEC really does work. The history of crypto-based security is filled with flawed implementations. --Michael Dillon --Michael Dillon
At 11:11 +0100 6/15/06, Michael.Dillon@btradianz.com wrote:
"certificates", and so on. This is fine for a technical audience but it won't help explain the issue to the decision makers who spend the money.
We should be clear on who the decision makers are. I've spent a long time trying to trick folks with engineering budgets and policy roles into doing DNSSEC. As much as they have been sympathetic to the cause, they can't find the justification they need to make DNSSEC happen. It's not that they are "ignorant." It's that they answer to other authorities - not the *gasp* engineers. The people who have investments in the Internet are the decision makers here. The consumers of the Internet, those who buy its services and turn them around for a profit, are the decision makers. They are the ones exposed to risk, they are the ones to best judge if DNSSEC fills a need. Unfortunately, I don't speak their language. Shucks, I'm just a simple country engineer from the old days. I do not mean to say we should stop technical discussions of DNSSEC nor stop the education process happening today. I also don't mean to say that we ought to give up on developing tools that will make DNSSEC less onerous. I mean to say that the effort to deploy DNSSEC has to consider (or increase what's done now) reaching out to those who we think are the consumers or beneficiaries of DNSSEC. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain...
At 10:20 +0100 6/14/06, Michael.Dillon@btradianz.com 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...
On Tue, Jun 13, 2006 at 03:21:23PM -0700, Gregory Hicks wrote:
From: Randy Bush <randy@psg.com> Date: Tue, 13 Jun 2006 15:16:50 -0700 To: Paul Vixie <paul@vix.com> 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.
participants (9)
-
Edward Lewis -
Gregory Hicks -
Joseph S D Yao -
Lucy E. Lynch -
Michael.Dillon＠btradianz.com -
Paul Vixie -
Paul Vixie -
Randy Bush -
Rick Wesson