Re: SSH keys in DNS

[Roy Arends <Roy.Arends@nominum.com>]

On Sat, 7 Jul 2001, Simon Josefsson wrote:

> Roy Arends <Roy.Arends@nominum.com> writes:
> > The protocol field has a reserved bit, that in the future could be
> > used to extend the fields usage. I see the advantage of being able
> > to query for a specific key, but I see also some disadvantage in
> > perhaps not being able to standardise name conventions. In the past
> > there has been discussions on storing protocol specific information
> > in owner names. I think the SRV RR is the _only_ one defined right
> > now, next to rfc-1035 specifying on what characters are allowed for
> > an owner name.
>
> Yes.  Should there be more of these, and where should they be defined?
> Will every protocol that wants to use DNS for key storage need to
> write a draft specifying the "_appX" tag they want to use?

Well, With zone-keys, you're absolutely stuck to the domain name itself.
With ipsec and ssh keys, you can specify them with a host. At this moment
there are a few different key-protocols that are host specific. i.e. ipsec
and ssh. A query for the hostname-keyset and identify the specific KEY by
its protocol field.  One query, one query-response, one identification by
matching protocol field. Thats it. I don't see the need for specifying
owner name requirements (for identification of host-KEYs ) for
applications.

Ofcourse, others may want such specification. If that should be done, this
could be documented in a BCP, or at least a FYI, but to specify it in a
standards-track draft, seems a bit overdone.

> >> But this might be bad, if applications are going to use owner names
> >> for differentiate the meaning of the RR, this should probably be
> >> standardized somewhere for interoperability.  Where?  BCPs?  But what
> >> this means is that we're replacing the well-defined IANA procedure for
> >> the "algorithm" field with something less well-defined.  Should IANA
> >> register "well known application domain names"?
> >
> > I hope not. Personally I don't like any restriction on owner-names, other
> > than that what is already there.
>
> So where is the "DNS application tag" to be specified?  What defines
> what "_ssh2" means?  (I mean in general, for each application wanting
> to use keys in DNS.)

In a BCP probably, if there's a need for specifying it.

> If DNS is going to provide a retrieval mechanism for application keys,
> it shouldn't just leave this part open IMHO.  There should be clear
> recomendations on how to store applications keys in DNS.

You absolutely have a point here. But I just wouldn't want to rule out the
protocol field just yet. For usage in DNS, a KEY needs to be identified by
some owner name. If this KEY is associated with some host, one can use
this host name. I do not see a problem on having ipsec, ssh, and kerberos
or what have you stored under the same owner name.

> >> (Hm... storing the KEY's used for DNSSEC with it's Key ID embedded in
> >> the owner name would also solve the recently discussed TTL
> >> problem... you would ask for _dnsseckey4711.example.org if you wanted
> >> example.org's KEY with Id 4711...)
> >
> > I think the TTL problem is a non issue. wrt to the TTL, one just has to
> > wait with rolling over keys until the old KEY TTL has expired. Same
> > problem as with rolling over NS Resource records at delegation points.
>
> Right.  You can leave it up to administrators to keep track of.  Or
> you can have the protocol be robust when it comes to these details,
> and do the job for the administrator.  Right now everything is pushed
> onto administrators, and that's probably one reason that few manages
> to run DNSSEC properly...

Wow, that is a bit strong. TTL's are simply for cache-usage, you _have_ to
wait until they expire if one wishes to change some RRset. Nothing to do
with protocol robustness.

One question though regarding your last sentence. What can be done
automagically wrt DNSSEC to relieve a administrator, without making DNSSEC
more complicated. If there are open fields (and there probably are) wrt
DNSSEC that has not been touched, we should eh, touch them.

Regards,

Roy Arends
Nominum