Re: Protocol extension / signaling supported signature algorithms

In general, your trigger-happy approach to disconnects creates much more trouble than it benefits. For another example, our SSH Server cannot use active keep-alives (based on fake global-requests that require a response) because old clients of yours disconnected when they received a global request from the server. Surely someone thought this was a wise choice, based on the exact reasoning you've now presented. "Let's disconnect - just to be safe."

Implementing a security protocol doesn't mean you get to be a lunatic and make decisions that are really stupid from a compatibility perspective.


denis bider <[email protected]> , 11/6/2015 3:19 AM:
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 ----- From: Damien Miller  Sent: Thursday, November 5, 2015 20:19 To: denis bider  Cc: [email protected]  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 trying to do here.   > 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.   -d