To:
Wesley Griffin <wgriffin@tislabs.com>
Cc:
Dan Massey <masseyd@isi.edu>, <dnssec@cafax.se>
From:
Roy Arends <Roy.Arends@nominum.com>
Date:
Sat, 7 Jul 2001 17:12:01 +0200 (CEST)
Delivery-Date:
Sun Jul 8 21:41:08 2001
In-Reply-To:
<20010707095846.C25300@tislabs.com>
Sender:
owner-dnssec@cafax.se
Subject:
Re: SSH keys in DNS
On Sat, 7 Jul 2001, Wesley Griffin wrote: > * Dan Massey <masseyd@isi.edu> [07/06/01 16:29]: > > On Friday, July 06, 2001 at 03:58PM, Wesley Griffin wrote: > > | So I've been working on modifying the OpenSSH client to lookup host keys > > | via DNS and I've run into an issue with the KEY record and > > | protocol/algorithm octects. > > | > > | I thought that perhaps the way to proceed would be to request 2 protocol > > | values from IANA: an SSHv1 protocol value and SSHv2 protocol value. But > > | I'm wondering if since it is still the SSH protocol, just a different > > | version, whether this is the appropriate method. > > > Right now, at worst, you get two RSA keys for ssh. Try the first RSA > > key and if matches the key presented by the host then you are done. > > Otherwise try the second RSA key. > > One of the actions of the client is to detect when a host key has > changed, and print out an appropriate warning message. As an example, > let's say there is a server that has a v1 RSA key in DNS and the > administrator has just upgraded the server and created a v2 RSA key and > added it to DNS as well. > > The client, which is using a caching nameserver, connects to the server, > and uses the v2 protocol. When the client requests the keys from DNS, it > gets back the cached answer and tries to compare the only RSA key in > DNS. > > Obviously the compare fails, but it is not correct for the client to say > the host key has changed. In fact, the host key is not in DNS. But the > client cannot know this because all it has is an SSH RSA key from DNS. Sorry to burst this again, but this is a standard rollover issue. Whenever you roll a keyset over, take the TTL in account. i.e. wait for a certain amount of time before obsoleting the old key. If one is concerned with emergency key rollovers, always advertise a key with TTL=0. Note that name-convention for the owner name does not solve caching problems. I would still have to query for _sshv2.example.com. KEY while there still can be the old _sshv2.example.com. KEY cached. Ofcourse, one can define that a keyID should be in the owner name, that would solve it. Regards, Roy Arends Nominum