Re: SSH keys in DNS

[Simon Josefsson <simon+dnssec@josefsson.org>]

Roy Arends <Roy.Arends@nominum.com> writes:

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

Right, sorry, my rant was really about the protocol field.

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

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

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.

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