key rotation on ssh servers

[Daniel Kahn Gillmor]

On 05/15/2013 01:11 AM, Damien Miller wrote:

> Right. The protocol only supports sending a single host key as part of 
> key exchange. E.g. RFC4253 section 8 (search for "K_S")

hm, right; and i don't see a way for the client to say "no thanks, try
again, but with the same key type".  if the key exchange fails, it fails.

> We've toyed with an extension to express "since you trust this one,
> here all my other keys" but never implemented it. To my mind, it would
> look something like:
> 
>   byte    SSH_MSG_HOSTKEYS
>   string  hostkeys
>   string  signature
> 
> Where "hostkeys" contains:
> 
>   string  hostkey[0]
>   ...
>   string  hostkey[n]
> 
> and "signature" is made with the hostkey that was used to sign the last
> KEX exchange.

Depending on how you specify hostkey[n], this would let you rotate keys
across key types as well, which is a nice feature.

I'm assuming this is wrapped inside the DH layer, after the key exchange
so that it is authenticated, encrypted, and bound to the session.

this sounds like it is similar to (but simpler than) the TACK proposal
currently under consideration for TLS [0].  I wonder if any of the
additional semantics considered for TACK would be useful for this sort
of extension for SSH.  certainly the form you're proposing has the
advantage of simplicity :)

Do you imagine that the server would just send this message to any
connected client blindly after each keyexchange, or should the client
signal its willingness to receive such a message first? (e.g. with an
otherwise empty SSH_MSG_HOSTKEYS message?)  client signalling seems like
it would reduce bandwidth costs initially (no bulk keys would be sent to
clients who don't want them) but might increase them in the long run (an
extra packet from the client that is not needed).

Is there any interest in an implementation of this?  Should i open an
issue for it on the bug tracker?

	--dkg

[0] https://tools.ietf.org/html/draft-perrin-tls-tack

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1027 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20130515/6d42b4bc/attachment.bin>