IETF-SSH archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Fixing exchange of host keys in the SSH key exchange
>> if I may stick an oar in sideways: if you go to all the trouble,
>> could you add a mechanism by which the server could advise that the
>> host key used by the client was still valid but deprecated, and to
>> download the new host key once connected?
> OpenSSH documents this as a private extension: [...]
They say, when describing hostkeys-00%openssh.com@localhost and
hostkeys-prove-00%openssh.com@localhost, that "[i]t also supports graceful key
rotation: a server may offer multiple keys of the same type for a
period (to give clients an opportunity to learn them using this
extension) before removing the deprecated key from those offered".
I cannot see how this is even possible, at least not without a custom
kex algorithm. With, for example, Diffie-Hellman as defined in 4253
section 8, the server presents only one host key to the client, and
must choose which one to present before kex (and thus authentication)
completes. This then gives no room to "offer multiple keys of the same
type".
The only way I can see that making any sense at all is if the server
continues to use the old key, but advertises both keys with
hostkeys-00@ for a period before bringing the new key into use. Maybe
that's what they're talking about, but if so I think the wording is
rather confusing. I much prefer the client-specified list of host keys
such as is made possible by what we started out this thread discussing.
I also don't see anything in the OpenSSH stuff that allows the server
to indicate that certain of the keys listed in hostkeys-00@ are
deprecated, which is at least part of what I read spz as asking for.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Home |
Main Index |
Thread Index |
Old Index