ECDSA and first connection; bug?

[Damien Miller]

On Thu, 27 Jan 2011, Dan Kaminsky wrote:

> Not really.  ssh-keyscan is a leap of faith.

It was mentioned in the context of manually accepting hostkeys, where
trust-wise it is strictly equivalent.

> It's _technically_ feasible to do this:
> 
> 1) Detect that there are other host key types
> 2) After logging in, run new ssh sessions off a port forward to
> localhost:[original connection port, might not be 22]
> 3) Collect the new keys
> 
> Whether anyone wants to write this code, I don't know.  But it's
> completely possible.

That would let you do it without protocol extensions.

Using a protocol change, it should be more user-friendly. I think it would
be possible to do it reliably with a new transport message:

    #define SSH2_MSG_SERVER_HOSTKEYS    7
    
    byte SSH2_MSG_SERVER_HOSTKEYS
    string public_keys
    string signature
    
    Where "public keys" consists of:
    
    string first_hostkey
    string second_hostkey
    ...

And signature is S(session_id || public_keys) and made using the hostkey
that was actually used for KEX.

This should be safe to do because RFC4253 says:

> 11.4.  Reserved Messages
> 
>    An implementation MUST respond to all unrecognized messages with an
>    SSH_MSG_UNIMPLEMENTED message in the order in which the messages were
>    received.  Such messages MUST be otherwise ignored.  Later protocol
>    versions may define other meanings for these message types.
> 
>       byte      SSH_MSG_UNIMPLEMENTED
>       uint32    packet sequence number of rejected message

-d