Re: SSH keys in DNS

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

On Fri, 6 Jul 2001, Simon Josefsson wrote:

> Roy Arends <Roy.Arends@nominum.com> writes:
>
> > This approach has its up and downsides. Upsides are for instance being
> > able to store all pgp related material in a single subzone. Downsides are
> > PGP specific, and have nothing to do with presentation format.
>
> I see an standardization "issue" with this _appX.foo.example.org
> approach, and I'm not sure if it's an advantage or disadvantage.
>
> By storing stuff in the owner names, the "algorithm" field in the KEY
> RR is basicly replaced.  I mean, applications will start to use owner
> names to differentiate between different kind of KEYs, instead of the
> "algorithm" field.
>
> This could be good, the algorithm field is only 8bit while owner names
> allow for more values, so there's no need to go through IANA and
> reserve a bit in the DNSSEC RR's.  Also, one MAJOR feature of moving
> this stuff into the owner name is that the client can actually ASK for
> a specific KEY, instead of parsing through all responses looking for
> the KEY with the right "algorithm" field.  Storing application keys in
> DNS doesn't scale well with the current model.

The algorithm field refers to the cryptographic algorithm. 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.

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

> > I have a feeling that the _ssh2, _pgp etc stuff is re-inventing and
> replacing the "algorithm" field.  Perhaps I'm the only one that didn't
> see that coming, and if so, fine, but otherwise perhaps it needs some
> pondering on how this idea should stand wrt the "algorithm" field.

I do not think that _pgp stuff is re-inventing some wheel or replacing the
protocol field. The protocol field implies PGP. The presentation of the
PGP key-id in an owner name is merely to prevent collision with existing
owner names. Next to that, storing PGP material (or any other non lowlevel
infra-info) in a specific subzone (or, away from critical domain RR types)
seems like a good idea.

I guess that if one wants to use a propriaty definition (as in
outside iana), one can do that. There is a protocol value of "any" and the
specs for any owner-name based representation can be stored in a BCP. But
IMHO not as a requirement (standards track).

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

Regards,

Roy Arends
Nominum