Re: Keys at apex problem - New PUBKEY RR?

[Olafur Gudmundsson <ogud@ogud.com>]

At 17:33 25-04-2001, Havard Eidnes wrote:
> > > > ...
> > > > 3. (DNS)KEY stored at name, applications store keys at _<app>.name
> > > > ...
> > > > 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.
>
>Ah, but as such these don't really apply to the problem at hand,
>which I understood was "how do we store the (public) key material
>of SSH (and possibly other applications) in the DNS".
>
>I'd also like you to quantify the increased cost imposed by the
>suggested SRV solution.

There is no benefit to use the SRV if the KEY data is stored in DNS,
in the best case there will be one more RR set, in the worst case there
will be three more names and one more RR sets.
The schema of using predefined name prefix to look up keying material
is cheaper and cleaner (just like Jakob says).


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

In this case the SRV record is redundant.

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

In this case the SRV record is needed but what is the point.


>The name ssh-key-name would in that case have to have an A record
>(to conform to the SRV record specification, if I do not mis-
>remember the specification), and the registered IP address would
>have to be the IP address of the intended SSH server.
>
>I thought the whole point of suggesting to use another name to
>was to have an opportunity to move the application-specific
>public key material away from the zone apex, with the added
>benefit of reducing the KEY RRset size to only contain the
>(public) keys required for that application, and what better
>place to store that key material than at that application's
>application-specific name?


SRV is one way to do that, the current argument is which solution is
the best one.


>Therefore I don't quite understand what the point of both using
>SRV records but storing the SSH public key material together with
>the pointed-to name with the A record would be, which could in
>theory be yet another name not otherwise used for other stuff (if
>you wanted to avoid the KEY RRset size issues (growth with the
>number of applications-specific keys).

see above that I think that is redundant.

> > 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.
>
>While I might agree, that's a separate problem, I think, and one
>where we should not try to piggyback the requirement and solution
>onto another problem/solution if it is not really a requirement
>imposed by the best solution to the original problem.

The in my mind the optimal solution (absent of all constraints) is to
use separate inherited type for each protocol.
The mailing list consensus is towards a well defined prefix name.

There are 5 different solutions on the table, the Internet draft that Jakob
and others have offered to write would document the solutions and attempt
to quantify the advantages, benefits, cost, drawbacks, effort, failures,
greatness, ... of each one and make a recommendation on how protocol
specific public keys SHOULD be added to DNS.
SSH and IPSEC are the first protocols, PGP and SSL will come soon and
we need to figure this one out sooner than later.

         Olafur