Subject: Re: Fixing exchange of host keys in the SSH key exchange

From: "S.P.Zeidler" <[email-masked]>
Date: Mon, 3 Apr 2017 22:02:51 +0200

Hi,

if I may stick an oar in sideways: if you go to all the trouble,
could you add a mechanism by which the server could advise that
the host key used by the client was still valid but deprecated,
and to download the new host key once connected?

Speaking as an admin of a bunch of servers whose users -do- ask
when the host key changes, I currently feel a need for a better
mechanism for updates to longer keys than "send mail".

regards,
	spz
-- 
[email-masked] (S.P.Zeidler)

---

From: "denis bider \(Bitvise\)" <[email-masked]>
Date: Tue, 4 Apr 2017 01:27:25 -0600

OpenSSH documents this as a private extension:

https://github.com/openssh/openssh-portable/blob/master/PROTOCOL#L286

Our SSH Server and Client do not implement this mechanism at this time, but it’s something I would like us to support.

denis

From: S.P.Zeidler 
Sent: Monday, April 3, 2017 14:02
To: denis bider (Bitvise) 
Cc: [email-masked] ; [email-masked] ; Simon Tatham 
Subject: Re: Fixing exchange of host keys in the SSH key exchange

Hi,

regards,
spz

---

From: Mouse <[email-masked]>
Date: Tue, 4 Apr 2017 18:06:58 -0400 (EDT)

> could you add a mechanism by which the server could advise that the
> host key used by the client was still valid but deprecated, and to
> download the new host key once connected?

That actually is a very interesting argument I hadn't thought of for
something operationally like the proposed scheme: it permits the server
to support multiple host keys at once for a single algorithm.  (The
client, of course, already can, since in the current design it's the
one judging host key validity.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Mouse <[email-masked]>
Date: Fri, 7 Apr 2017 11:29:32 -0400 (EDT)

> OpenSSH documents this as a private extension: [...]

They say, when describing [email-masked] and
[email-masked], that "[i]t also supports graceful key
rotation: a server may offer multiple keys of the same type for a
period (to give clients an opportunity to learn them using this
extension) before removing the deprecated key from those offered".

I cannot see how this is even possible, at least not without a custom
kex algorithm.  With, for example, Diffie-Hellman as defined in 4253
section 8, the server presents only one host key to the client, and
must choose which one to present before kex (and thus authentication)
completes.  This then gives no room to "offer multiple keys of the same
type".

The only way I can see that making any sense at all is if the server
continues to use the old key, but advertises both keys with
hostkeys-00@ for a period before bringing the new key into use.  Maybe
that's what they're talking about, but if so I think the wording is
rather confusing.  I much prefer the client-specified list of host keys
such as is made possible by what we started out this thread discussing.

I also don't see anything in the OpenSSH stuff that allows the server
to indicate that certain of the keys listed in hostkeys-00@ are
deprecated, which is at least part of what I read spz as asking for.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 8 Apr 2017 03:48:32 +0000

Mouse <[email-masked]> writes:

>They say, when describing [email-masked] and hostkeys-
>[email-masked], that "[i]t also supports graceful key rotation: a
>server may offer multiple keys of the same type for a period (to give clients
>an opportunity to learn them using this extension) before removing the
>deprecated key from those offered".
>
>I cannot see how this is even possible, at least not without a custom kex
>algorithm. With, for example, Diffie-Hellman as defined in 4253 section 8,
>the server presents only one host key to the client, and must choose which
>one to present before kex (and thus authentication) completes.  This then
>gives no room to "offer multiple keys of the same type".

I assumed the offered keys are via "[email-masked]", not in the
keyex.  As the text says, it offers those for awhile, then when it seems all
clients have got a copy it switches the keyex from the old to the new key.

Peter.

---

From: "denis bider \(Bitvise\)" <[email-masked]>
Date: Sat, 8 Apr 2017 05:00:31 -0600

Yes – that is my understanding as well.

From: Peter Gutmann 
Sent: Friday, April 7, 2017 21:48
To: Mouse ; [email-masked] 
Subject: Re: Fixing exchange of host keys in the SSH key exchange

Peter.

---

From: Mouse <[email-masked]>
Date: Mon, 24 Apr 2017 22:55:05 -0400 (EDT)

Back on March 25th, I wrote (in the thread about making the client tell
the server what host keys it's able to authenticate using, pre-kex)

> Hmm, I think I'll give moussh a configuration option to send things
> before the ID string, for exactly that reason.

I've now done this.  See the -pre-banner command-line option and the
pre-banner config-file variable.

As the manpage notes,

                             Generating a line beginning `SSH-' with this
             mechanism will break the protocol; moussh contains no checks to
             ensure this isn't done.

I'm not sure whether I think this is the Right Thing.  I came down in
favour of this behaviour, but not by much; if anyone cares to argue in
favour of either position (either the above stance or making sure that
doesn't happen), I'd be interested.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign