ECDSA and first connection; bug?

[Markus Friedl]

yes, this is what Damien wrote.

Am 27.01.2011 um 17:38 schrieb 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