Protocol extension / signaling supported signature algorithms

I'm not sure that any part of RFC 4253 specifies that you must disconnect if a message contains additional info that you don't recognize. The security benefits of doing so are dubious. If there's any way that this could be exploited, it means you (or the other party) have much bigger issues. On the other hand, by implementing this, you absolutely guarantee that future extensibility is impossible without additional signaling.

That being said, my anger is misplaced because if you didn't pull this, someone else would, and god knows there's any number of implementations out there that do... things.

The flaw is really in the protocol, which doesn't provide room for this additional signaling. In hindsight, the SERVICE_REQUEST and SERVICE_ACCEPT messages are useless. They waste an entire roundtrip on the idea that there might be other services for the client to request than user authentication. A decade later, there aren't any such services.

The very least that these messages could have done was add a simple name-list of extensions supported. In that case, at least, this extra round trip would be useful for extension signaling.

You propose signaling via a "publickey2" method. Unfortunately, this still requires the client to waste a round-trip: either by requesting "none" authentication to discover methods supported, or by requesting "publickey2" authentication and finding that it isn't supported.

I think the SSH_MSG_IGNORE strategy is superior - it allows the client to immediately fire the correct public key authentication request with signature.

----- Original Message -----

Sent: Thursday, November 5, 2015 20:19

Cc: ietf-ssh%netbsd.org@localhost

Subject: Re: OpenSSH sabotages protocol extension

On Thu, 5 Nov 2015, denis bider wrote:

> Obviously, same thing for SSH2_MSG_USERAUTH_FAILURE:

> authlist = packet_get_string(NULL);

> partial = packet_get_char();

> packet_check_eom();

RFC4242 section 5.1. I'll quote it for you:

> 5.1. Responses to Authentication Requests

> If the server rejects the authentication request, it MUST respond

> with the following:

> byte SSH_MSG_USERAUTH_FAILURE

> name-list authentications that can continue

> boolean partial success

Note the lack of extension fields and the "MUST".

> Awesome work, guys! You have locked down every possible clean way that the

> protocol could be extended, so as to spare the client several round-trips to

> discover which signing algorithms it can use for RSA keys.

It sounds like you want to redefine the information flow of public key

authentication. If you want to do this (and I don't think it is a good

idea - I'll comment separately on the draft), then the right way to do

it is to design a new authentication method that can be negotiated by

implementations that support it.

By implementing a new "publickey2" (or whatever) method, you get to

define new SSH_MSG_USERAUTH messages, which is basically what you are

> You've made it so that the only way to convey such information, and not risk

> a client disconnect, is to use a specially crafted SSH_MSG_IGNORE.

Again, RFC4252 made it this way. We just implemented it as it was written.