ECDSA and first connection; bug?

[Dan Kaminsky]

On Thu, Jan 27, 2011 at 3:03 PM, Damien Miller <djm at mindrot.org> wrote:
> 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.

I'm saying that if you already know the RSA or DSA host key, you
should not need to downgrade to another leap of faith to get the ECC
key.

>
>> 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.

Which is sort of nice.

>
> 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

Would this add a RTT?  SSH is a little slow as is.

This is unquestionably a more elegant solution.

>
> -d
>
>