wrt joao damas' DLV talk on wednesday

Mailman List Mirror (Read Only)
1

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. :slight_smile:

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.

2

> 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.)

3

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. :slight_smile:

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

4

> 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. :slight_smile:

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/&gt;\. 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. ;-)]

5

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

6

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

7

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

8

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

9

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.

10

<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?

11

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).

12

[ 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

13

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

14

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.