Re: Where are we (metaphorically speaking)?

[Edward Lewis <lewis@tislabs.com>]

At 8:11 AM -0500 12/7/01, Olaf Kolkman wrote:
>  t=1 start of rollover: child introduces new key with tag=2 and signs
>                         keyset with both key 1 and key 2
>
>
>  parent.       KEY tag=1234    |         child	KEY	tag=1
>  child.parent. DS  tag=1	|		KEY	tag=2
>  child.parent. SIG DS parent	|		KEY	tag=10
>		       tag=1234	|		KEY	tag=11
>				|		SIG	KEY child
>                                |			    tag=1
>			        |		SIG	KEY child
>			        |			    tag=2
>				|
>				|     data.child A	10.1.1.1
>				|     data.child SIG    A child
>				| 			  tag=10
>

There is the alternative to have two DS records at the parent.  This would
be the same as having two SIG's at the child.  (Of course, I assume that
the child key set will be self-signed by all keys in it - it is just easier
to code and understand that way.)

>  What needs to be filled in here is how the signals at t=2 and t=3
>  are being communicated.

I think that this is the true problem to solve.

>  We propose a light weight mechanism;
>
>  At t=2 The signal is sent either by a special DNS NOTIFY or by
>  another mechanism like a signal to a robot.
>
>  The parent zone administrator then queries for the special label:
>  QNAME= _pep.child.parent QTYPE=DS  (pep: parental entry point)
>
>  This returns a DS record that is signed by the child and that points
>  to the key in the child zone that is SHOULD be used for configuring
>  the DS record in the parent zone.
>
>  The signal at t=3 is not really needed. The child can periodically
>  query the parent zone to see if the new DS record pointing to tag=2
>  has appeared with proper signature. Once that DS RR appeared key
>  tag=1 can safely be removed.

I've been mulling an alternative that does not use DNS as the signalling
mechanism.  The reason I began thinking this was that in the steps of
validating a zone key, the private keys at the child (key generation) and
the parent (signing something) are involved.  Neither of these are in the
name servers.

Another alternate point I have been considering is to place a key
collection service at the parent.  I.e., when a child wants a new key set,
the set is sent to the parent's place.  The parent then has to consult this
place when signing (keys, zone).  Although this collection service becomes
a single point of a possible attack, it reduces the load on the parent when
it comes to signing data.  Leaving out details of how the service is
implemented, it comes down to an age old issue of network latency vs.
computational overhead.

(I've not yet hammered enough of this other approach to publically document
it, but I wanted to raise the main differences.)

>2.2. Rollover of resolver entry point.

Without picking particular issues, what about the use of SNMPv3 here?
Configured keys are a touchy subject because they are so crucial in the
process of validating an answer.  I don't know if an in-band approach is
wise here.

One other consideration is that we need to begin thinking in terms of the
four elements at a delegation, not just two.  Registrants, registries,
registrars, and server operators have emerging roles in this.  One thing
learned from the ICANN meeting was that registrars operate in many
different ways, this may be an reason to examine our approaches to work for
different models of interaction.  Just a thought.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: lewis@tislabs.com

Opinions expressed are property of my evil twin, not my employer.