Re: Keys at apex problem - New PUBKEY RR?

[Olafur Gudmundsson <ogud@ogud.com>]

At 17:06 19-04-2001, Dan Massey wrote:
>Based on the discussion and attempts to make the ssh keys work,
>I'm convinced of the following:
>
>DNSSEC infrastructure keys have special signing rules that involve
>the parent zone.  Maintaining these keys requires cooperation between
>the zone and its parent.  Resolvers must use these keys during
>the DNS authentication process and typically don't pass these keys
>back to the end applications.
>
>Application keys should not have any special signing rules and should
>be signed by the zone that owns them.  Maintaining these keys is
>something that should be done by the individual zone.  Resolvers must
>not use these keys during the DNS authentication process and should
>treat these keys like any other data that is passed back to some end
>application.

I agree 100% with what you have said so far, please send this to
namedroppers ASAP.

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.


>Combining these two different things into one KEY record creates
>problems.  Putting an application KEY at the apex illustrates the
>differences and results in problems for zone signing, zone
>administration, and leads to complicated/confusing rules for
>resolvers.

To quote Rob Austein, "Every time we have allowed subtypes in DNS it has
come back to bite us, hard"


>There is serious concern about redesigning or delaying DNSSEC,
>but I think we can avoid major problems here.  Keep the KEY record
>format as it is,  only restrict the protocol types so only DNSSEC
>infrastructure keys are allowed (i.e. drop email and ipsec from 2535).
>Technically bind9 would not be compliant with this new spec because
>it would let you load a KEY with the (no longer valid) IPSEC type into
>your zone (even at the apex!)  However, adjusting the next version of
>BIND or patching the old version should be fairly simple.  Also, you
>can run the existing BIND, don't enter KEY records with the invalid
>type into your zone file and complain to any zone that does this
>and pollutes your cache.
>
>There are very few, if any, fully developed and widely deployed
>applications that rely on the application KEY record.   These few
>applications will have to change.  The open question is change to
>what...  One option is to use the CERT record.  Another option is
>create a new PUBKEY record for application keys.   I think the
>infrastructure KEY is fundamentally different than the CERT and
>PUBKEY records because of the way KEYs are signed, authenticated,
>and used.  I don't know if CERT should be used for general public
>keys or if having both CERT and PUBKEY would be duplication.  However,
>CERT/PUBKEY belong in their own documents.


DO NOT use CERT to publish KEY record.


>So I guess that is the very long way of saying I'm in favor of
>separating DNS infrastructure keys from application keys. I think
>either CERT only or CERT+PUBKEY would work, but I don't know which
>of those two is better.
>
>Dan



I think we should pick one of 1, 2 or 3 and suggest that in an ID as soon as
possible.
Solution 1 (KEY + APPKEY) has the lowest cost,
cost:   same number of names
         one more type regardless of number of application keys
         one more signature
drawbacks:  many security aware applications will cause large key sets.
         if applications want to define use of flags we may run out of flags
         or overload flags between applications.
advantages: simple to deploy one time cost.

Solution 2 KEY + <app>key type
cost:   same number of names
         one type for each application supported by name
         more types to sign
drawbacks: DNS servers and resolver must support unknown types for rapid
         deployment of new application key types.
advantages: small key sets that are easy to find no searching in key list
         Each type has clean slate on use of flags and does not affect any
         other applications.

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
advantages: small keys sets (just like 2).


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.

Side bar: do we need to now fragment the DNS type space into types that
DNSSEC can handle without knowing contents or can we REQUIRE that all
new types will be propagated by authoritative servers in canonical format?

         Olafur