Re: Keys at apex problem - New PUBKEY RR?

[Olafur Gudmundsson <ogud@ogud.com>]

At 19:42 20-04-2001, Havard Eidnes wrote:
> > Given that I have been off-line (and will be for a little while longer)
> > here is my summary of possible solutions:
> > 0. Only one type of keys and live with large key sets where multiple 
> types of
> >     KEYS (current spec).
> > 1. (DNS)KEY and APPKEY type (some call this pubkey)
> > 2. (DNS)KEY and a KEY type for every application that wants to use DNSSEC
> > 3. (DNS)KEY stored at name, applications store keys at _<app>.name
> > 4. some combination of 1+2+3.
> >
> > 4 is something we want to avoid like the plague if possible.
> > Any use of SRV records where SRV does not point to key server other
> > than DNS is equivalent to 3. at higher cost.
>
>I have problems making sense of that last sentence.  Could you be
>bothered to explain?  In particular I have problems understanding
>what you mean when you say "...does not point to key server other
>than DNS...".  What's "key server" in this context?  I'm confused.

anything you can think of such as PGP keys server, LDAP server,
special DNS zone for keys.
If SRV record is just pointing to a different name in the same zone
then all that has been accomplished is more names in the zone.


>I would have thought that the unsigned east.isi.edu ssh example with
>a SRV record for the ssh service provided by the host with the A
>record at the zone apex would be
>
>$origin east.isi.edu.
>@               IN      SOA     ...
>@                       NS      ...
>@                       A       38.245.76.2
>@                       KEY     <zone key>
>_ssh._tcp               SRV     0 0 @
>_ssh._tcp               KEY     <ssh host key material>

or it could be
_ssh._tcp               SRV     0 0 ssh-key-name
and key would be stored at ssh-key-name


> > Solution 2 KEY + <app>key type
> > cost:   same number of names
> >          one type for each application supported by name
> >          more types to sign
>
>Here I think you mean "introduce one new DNS record type for each
>type of application-specific key material which needs to be stored
>in the DNS".

YES


>Won't this have the potential to both chew significantly away at the
>DNS record type space, and significantly slow down the use of DNS
>for storing key material for new applications?!?


Yes it will eat some type numbers but we have about 0K used with
about 64K available last time I checked.
It may slow the deployment in the short run but once we get software
updated to handle unknown types gracefully the cost drops to nothing.
One of the main problems we have in DNS is the slow deployment of new types
and the only way to get that fixed is to create many new types fast
to get people to fix their software.

Only types that contain domain names or require additional section
processing should require software updates.


> > drawbacks: DNS servers and resolver must support unknown types for rapid
> >          deployment of new application key types.
>
>The current software doesn't do that, I presume?

Exactly.


> > Solution 3: KEY and _<app>.name KEY
> > cost:   extra name for every application
> >          extra NXT/NO set
> >          2 more signatures per key set.
> > drawbacks: same as 1. + the extra set
>
>Really? "...will cause large key sets" was listed under 1.  I don't
>think this proposal has that disadvantage.

you are right, and I forgot the control of the names space issue.



> > After much thought I do not think that 1 is radical enough to help
> > in the long run. Between 2 and 3 I vote for 2 as applications can
> > then use the flags for what ever they want to use the flags for
> > and do not affect anyone else, this will also force DNS providers to
> > support unknown types.
>
>I would rather go with 3 using SRV records, and reuse the KEY record
>type, since it requires no additional administrative wrangling
>involving the IETF and/or the IANA to deploy storage of key material
>for new applications.

With 3 there is no need for SRV records unless you want non DNS key servers.



>If you think I am needlessly nitpicking here, that's probably
>because I'm not an expert in this area, but merely a generalist
>trying to make heads and tails of all this.


All above are good questions that need to be answered.

         Olafur