Re: Keys at apex problem - New PUBKEY RR?

[Havard Eidnes <he@runit.no>]

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

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

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?

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

It might help to think that what we're storing is the "*SSH* host
key", not the "SSH *host key*", i.e. the emphasis is on the
application, not primarily the fact that the key is tied to the
host in question.

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

Regards,

- Håvard