Re: Keys at apex problem - New PUBKEY RR?

["Scott Rose" <scottr@antd.nist.gov>]

----- Original Message -----
From: "Jakob Schlyter" <jakob@crt.se


> On Fri, 20 Apr 2001, Olafur Gudmundsson wrote:
>
> > I think we should pick one of 1, 2 or 3 and suggest that in an ID as
soon as
> > possible.
>
> I would be interested in working on a ID describing this, but I need
> assistance. Dan?
>

Jakob - I can volunteer too, if you want help.


> > 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.
>
> should we consider the risk of large key sets a big problem?
>

Possibly a problem, That depends on the adoption of using the DNS to
distribute keys.  Public keys can be very large, and even with EDNS, there
will be a lot of truncated responses (and TCP queries) when there are
several APPKEYs for a name.

> > 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.
>
> are the drawbacks perhaps so large that people will not use this for
> applications?
>

I think that the adminstration problems of getting a new type deployed makes
this unattractive.  App developers will have to get a new type defined (and
deployed to DNS implementers) for every new protocol.  It's not a problem,
but will slow rapid adoption of protocols using DNS for support.  Maybe this
is a good thing ;-)

> > 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).
>
> I like this more and more. perhaps more realistic that 1. _app should be
> defined in a document per application, but that is needed anyway to
> describe the RDATA format
>
>

This is probably the easiest solution, since the structure is already in
place and only requires admins to change zone files. How hard can that be
;-) ?

This makes queries made by DNS servers to get DNSSEC keys untouched, if EDNS
is used, I don't think the drawback will be a problem.  Unless there are a
lot of keys a host must use with a particular application.

Scott