On Mon, Nov 21, 2005 at 08:42:07PM +0000, Paul Vixie wrote:
> # > dnssec only signs authority data. glue is (by definition) not authority
> # > data.
> #
> # not authority data for the zone in question. it is authority
> # data for some part of the heirarchy tho...
>
> in principle, then, a referring server could fetch, validate, and transmit
> the covering RRSIGs for any out-of-bailiwick glue it wants to hand out?


if such out-of-baliwick glue was in part of a signed heirarchy itself
-AND- the local system attempting the validation had associated Trust Anchors
for those parts of the signed heirarchy...

> # > according to (drum roll, please) "local policy".
> #
> # yes, yes... the presumption of fully signed heirarchy and/or locally
> # maintained TA's... Is that -ALL- there is for choice?
>
> the decision was made about a decade ago to force trust to follow delegation.
> while it'd be a nicer security market if anybody could sign anybody else's key,
> that's not what we ended up deciding.


so for the dnssec trust model, self-signed or third-party signatures are
not to be used/trusted. but does this lema preclude the existance of
such signatures?

> # > because we have to stop adding requirements some day. let's start now?
> #
> # er... because we have to stop is not, IMHO, a credible reason.
>
> if you think endless design and redesign and requirement change is credible,
> then i want some of whatever funding YOU'RE smoking. (mine isn't like that.)


dns (and dnssec) have been inthe process of "endless design and redesign"
since their inception. i'm not asking for anything more than status quo.
if you -WANT- the kind of funding that supports and encourages research
(where its ok to have novel ideas that may not fly in the commercial world)
then that kind of funding is there... but there are downsides... as is
true w/ nearly all funding models.

> i'm suggesting that we have to call it deployable, and deploy it, and then we
> can go right on changing it. just like was done with dns, which was a total
> trainwreck when deployed, by today's lofty standards.


dns was never frozen while it was being deployed. and i suspect dnssec
won't be either.

--bill

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: