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

["denis bider \(Bitvise\)" <ietf-ssh3%denisbider.com@localhost>]

Peter:


> > this prevents the situation where the client will present
> > the user with a host key verification dialog, and the user
> > will just click through it.
>
> It also makes things a lot more painful for the user.

It helps ensure secure host key configuration. There are administrators who 
would prefer this.

If this involves more pain than previously, the user was most likely not 
managing host key trust to the same standards.


> If you regularly need to SSH into a dozen different devices
> to administer them, it gets even worse.

This is meant for administrators who would want to enable this policy. This 
would be a server-side policy, so if you're administering machines, you 
could avoid configuring this policy.


> > drive-by password guessing becomes largely impossible,
> > since unknown attackers do not know the server’s host key.
>
> This is really just an awkward form of port-knocking.

Yes, and we have other mechanisms for this (e.g. protocol obfuscation). In 
this case, it's a nice effect you get for free, in case you enable this 
policy.


> > Server implementations that do not know about this extension,
> > but correctly implement the spec,
>
> How do we know what percentage of servers do this?

We don't, it would be necessary to test this.

Which means, probably, I would have to test this.

Mouse pointed out I was wrong about the spec. It turns out RFC 4253 provides 
for text before version string when sent by servers, not by clients. It's 
definitely necessary to test.

As discussed with Mouse, if this exact method doesn't work, there are 
alternatives. Server could send "expect-key" host key alg in KEXINIT, and 
client could send a new message SSH_MSG_EXPECT_KEYS after its KEXINIT. This 
would still solve the primary objective, but would not have all the same 
nice properties. E.g. the server could not use that to avoid fingerprinting.


> it has the potential to break lots of things

That seems to be the main potential downside of the method as presented.

But there are other ways to do it, and the suggested approach could be 
proven safe in testing.


denis


----- Original Message -----
From: Peter Gutmann
Sent: Friday, March 24, 2017 01:22
To: denis bider (Bitvise) ; ietf-ssh%netbsd.org@localhost
Cc: djm%mindrot.org@localhost ; Simon Tatham
Subject: Re: Fixing exchange of host keys in the SSH key exchange

denis bider (Bitvise) <ietf-ssh3%denisbider.com@localhost> writes:

> (1) Security benefit: although the client could still not verify the server’s
> signature during key exchange, or could do any number of other things
> incorrectly; under reasonable assumptions, if the client has to communicate
> one or more fingerprints of the server’s host key(s) before KEXINIT, this
> prevents the situation where the client will present the user with a host 
> key
> verification dialog, and the user will just click through it.

It also makes things a lot more painful for the user.  If you regularly need
to SSH into a dozen different devices to administer them, it gets even 
worse.

> (2) Security benefit: on servers that enable this policy, and prevent
> connections where the client does not communicate a correct server host 
> key,
> drive-by password guessing becomes largely impossible, since unknown
> attackers do not know the server’s host key.

This is really just an awkward form of port-knocking.  If you want to use a
port-knocking-style mechanism, you should probably do it properly.  If you
want to bind a client to a server ("only this client, only this server") 
then
there are better ways of doing it than this.

> Server implementations that do not know about this extension, but correctly
> implement the spec,

How do we know what percentage of servers do this?  It's true that the spec
says you should expect other stuff in the textual data, but since pretty 
much
everything out there only ever sends the SSH ID string, it's quite likely 
that
lots of implementations will choke on unexpected extra lines of text.  Even 
in
cases where the code does try and handle non-SSH-ID lines, the absence of
anything that sends them means it's probably never been tested.

This doesn't seem like a good idea, it has the potential to break lots of
things, while what you're getting in return could be done better in other
ways.

Peter.