wrt joao damas' DLV talk on wednesday

Wed Jun 14 15:19:35 UTC 2006

[ 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