wrt joao damas' DLV talk on wednesday

Tue Jun 13 23:33:30 UTC 2006

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