Re: Keys at apex problem - New PUBKEY RR?

[Havard Eidnes <he@runit.no>]

> 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.

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>

> 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".

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?!?

> 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?

> 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.

I think the extra resources spent are probably not significant; this
will typically happen at the leaves of the DNS space where
additional resources are easiest to add as needed.

> advantages: small keys sets (just like 2).

Right, and that contradicts what you said above.

> 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.


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.


Regards,

- Håvard