Re: keys at apex (key points)

[Olafur Gudmundsson <ogud@ogud.com>]

At 08:42 04-05-2001, Scott Rose wrote:
><snip>
>
> >
> > I would like to suggest the following for the KEY record.  In the RFC 2535
> > revision, we leave the KEY format unchanged.  However, only the DNSSEC
> > protocol type will be explicitly defined.  For other protocol types, the
> > revision will reference a second document that will discuss the proper use
> > of application keys, the process for defining a new KEY protocol type, the
> > risks to consider, and general directions for application designers who
> > might choose to use this.   This app key document could present Jakob's
> > labeling approach or present any of the other alternatives or perhaps
> > Randy could convince the group that no other protocol type should be
> > allowed.  I would like to contribute to this document's discussion of the
> > risks and things to avoid.  (I think others are better suited to stating
> > the correct solution).  The consideration of this document should reflect
> > the bigger picture issues raised by Randy.
> >
>
>I think the "DNSSEC only" KEY description is the easiest way to go for now.
>The problem of how best to store application keys in the DNS (if at all) is
>a larger DNS issue, not strictly a DNSSEC issue.


Short history, and some comments afterwards.

DNSSEC design 1994,
         keys anywhere with certain bits set can sign their own data,
         create prefixes to their name and sign that, can even create new
         delegations.

DNSSEC dynamic update 1995,
         keys stored under wild card name can have strength values that
         allow them to create names
         I propose that we restrict the use of KEY records to DNS, proposal
         rejected.

DNSSEC design 1996 (memory fuzzy at this point on actual times)
         the ability to create delegations taken from most non zone keys.

DNSSEC work 1997
         Only keys with the Zone are now only keys allowed to sign the
         SOA NXT records.

DNSSEC 1998 Secure dynamic update document
         Brian, Ed and I convince each other that restricting signing of
         the zone to the zone key set held at the apex is a great
         simplification for resolvers.

DNSSEC 1999 Secure dynamic update evolves to basically outlaw non material
         key signatures but they are sill allowed (non zone keys)

At this point we have restricted use DNS of KEY record to delegation points
only. Non DNS KEY records can still be stored at any name.


DNSSEC 2000 Bind developers, and Verisign labs start complaining loudly
         about   the null keys and its complexity. NL Labs start proposing
         storing the signed child zone key set in the parent.  There are
         some proposals that come forward to address this, later they get
         merged/obsoleted.

DNSSEC 2001 people realize that once we start putting application specific
         KEY records at delegation points there might be large. That
         parents may not want to sign non DNS KEY records. The frequency of
         key set updates will increase and cause more key rollover requests.
         Suggested solutions are to separate the DNS key records from
         application key records.

After looking back through all the steps taken we are now proposing is
similar to what was proposed in 1995, KEY record is used for DNS and only
DNS.
After reflecting on this under the influence of too many beers I want to
float one more trial balloon:

The real issue we have is conflicts between information at parent and
child thus lets store something different at the parent than at the child.
Parent will store at delegations point DKEY (delegation key set) that
contains the DNS zone keys that are in use by the child, the child has
a KEY set at apex that MUST be signed by ONE of the keys in the DKEY set.
This way we can have a chain of trust, there is no issue who is responsible
for what data, resolvers can keep both sets from the delegation
we eliminate the need for NULL key at parent.
If a child wants to store multiple application keys in their key set that
is fine and the parent never sees them.
The resolver that trusts the KEY for "bar." and wants to verify data
in domain foo.bar. goes from
         "bar." KEY to
         "foo.bar." DKEY to
         "foo.com." KEY

This is one extra step but resolver can keep the full verification chain
NO DKEY is identical to NULL KEY.

For MarkK I can even go as far as saying that the rdata in DKEY is
SHA-1 hash of the key involved rather than the full key record.
Thus the child does not have to expose the public key that they intent
to use until just before it is used. I think this will be great for
the root keys, this may open up some vulnerabilities that can be
addressed by adding the key tag or another hash.

This proposal does not in any why address the problems that we see with
large key sets it only makes sure the pain is squarely on the child side.


>Do we have people to volunteer to write up each proposal as a lightweight
>draft for the WG?

If people think this is a good idea, I need someone to help edit this
document.

         Olafur