Re: rrsig(qtype)

[Roy Arends <[e-mail]>]

On Thu, 17 Jun 2004, Rob Austein wrote:

> General issue with sign-on-the-fly, not limited to Roy's proposal.
>
> What happens to the data-producer to data-consumer end-to-end trust
> model with these online signing models?  Is the response cachable?  Is
> this the thin edge of a conversion of DNSSEC from object security into
> channel security?

Since the response would be a negative response in all aspects, its just
as cachable as any other negative response. This is undoubtedly object
security, not channel security. The proposal is to sign a non-existent
object. A none existent object is logically an object with name type
class, neg-ttl, no rdata. That is what is signed.

> Color me concerned about depth of water and strength of undertow.
>
> Note that while DNSSEC combined with dynamic update shared some of
> these properties, the conceptual model in that case is that the data
> producer for DNSSEC purposes is what RFC 2136 calls the "primary
> master server".  That is, in the dynamic update case there are (at
> least) two separate trust relationships: one is between the update
> client and the primary master server for the dynamic update protocol;
> the other is between the dynamic update engine (which has been
> configured to act on behalf of the zone admin) and the DNSSEC
> validator.
>
> I do not (yet?) understand what the trust relationships look like in
> these sign-on-the-fly-to-avoid-real-NSEC proposals.
>
> Who is trusting whom to do what?

A primary master trusts(1) the update client to update zone.
A DNSSEC validator trusts(2) the master-in-zone-mode-B to update zone.
A DNSSEC validator trusts(3) the signing oracle at the master to sign
empty objects.

(1) The trust is established by message authentication (rfc3007) using
    either TSIG or SIG(0)
(2) Since a DNSSEC validator is oblivious that a zone is subject to secure
    dynamic update, trust is established by standard DNSSEC operation.
    The trust between the primary master and the 'dynamic update engine'
    is done oob, or might be converged to a single elephant.
(3) The trust is established by DNSSEC operation (if DNSSEC-bis is
    ammended to trust signed epty objects)

Since (2) and (3) have different properties (signed objects with data vs
signed objects without data) different keys could be used (not required).

Roy

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>