ECDSA and first connection; bug?

[Dan Kaminsky]

What you'd want is a protocol to upgrade from an old host key to a new host key, leveraging the existing trust in the old key. 

Everything else is just a new leap of faith, including ssh-keyscan.

Sent from my iPhone

On Jan 27, 2011, at 5:20 AM, Markus Friedl <markus.r.friedl at arcor.de> wrote:

> I agree with Damien:
> 
> The current behaviour reduces the risks of a MITM attack and using
> ssh-keyscan to collect the 'new' ECDSA is perfectly reasonable.
> 
> -m
> 
> On Tue, Jan 25, 2011 at 09:25:02AM +1100, Damien Miller wrote:
>> On Mon, 24 Jan 2011, Phil Pennock wrote:
>> 
>>> Folks,
>>> 
>>> I read the 5.7 release announcement and updated, to try out ECDSA.  Most
>>> parts worked very smoothly.  The inability to create SSHFP records is
>>> understandable, since IANA haven't allocated a code yet.
>>> 
>>> One apparent bug: I think StrictHostKeyChecking=ask is broken for ECDSA.
>>> 
>>> % ssh -o HostKeyAlgorithms=ecdsa-sha2-nistp256 localhost
>>> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
>>> @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
>>> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
>> 
>> This is deliberate. 
>> 
>> Previously, a malicious server could arrange for ssh(1) to display a
>> less-scary message for a changed hostkey if its host key happened to
>> be a different type to one that has already been learned.
>> 
>> Now there should be no surprises since ssh(1) will automatically request
>> hostkey type matching keys that are already known, though this does not
>> occur when you override HostkeyAlgorithms (like you did). We talked about
>> whether we should retain the old message in this case or not, but thought
>> the safest thing to do would be consistent with the non-explicit-
>> HostkeyAlgorithms case.
>> 
>> For learning different hostkey types, we recommend ssh-keyscan. I'd like to
>> do a protocol message for a server to send all its hostkeys to the client,
>> but this would require a KEX extension and I'm not sure how compatible
>> this would be with non-OpenSSH implementations.
>> 
>> -d
>> 
>> _______________________________________________
>> openssh-unix-dev mailing list
>> openssh-unix-dev at mindrot.org
>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev