Re: SSH_MSG_KEXGSS_HOSTKEY (was: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt)

["Joel N. Weber II" <ietf-secsh%joelweber.com@localhost>]

> I think I'd call this "implicit revocation."  The server tells the
> clients what all its publick keys (and certs) are after authenticating
> itself to the clients and the clients update their database of known
> server host keys, adding new ones and removing old ones.

You don't want to remove the old ones.  You want to mark them as
permanently unusable.

Consider a host foo.example.com which has a GPG host key.  Assume it
gets compromised, and the attacker copies the private key, and gets a
copy of the public key which has a signature made by the sysadmin's
public key.  Assume that my client doesn't store the compromised key.
There is nothing to require the attacker to send the revocation
certficate along with the key, and so if I don't have the revocation
certificate cached locally and pay attention to only what the attacker
sends me, it's entirely possible that I'll get something that looks
like a valid key.

Another way to try to solve this problem is by contacting a keyserver.
If you connect to a keyserver using TLS, and you trust the keyserver
to keep the revocation certificate for forever once it gets it, this
can be secure.  But I don't know any keyservers that support this
level of security, and it's desireable to not depend on being able to
contact a key server when authenticating an ssh server, for various
reasons related to performance, reliability, and denial of service
tradeoffs.  Contacting a keyserver in this fashion may be a feature
worth implementing someday, but being able to send revocation
certificates in the ssh protocol is still useful.