Re: Fixing exchange of host keys in the SSH key exchange
Mouse <[email protected]> Fri, 7 Apr 2017 11:29:32 -0400 (EDT)
| Newsgroups | gmane.ietf.secsh |
|---|---|
| Message-ID | <[email protected]> |
>> 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 [email protected] and [email protected], 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 [email protected] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B