Re: Feedback on draft-ssh-ext-info-00

[denis bider <ietf-ssh3%denisbider.com@localhost>]

I'm not sure that we have a guarantee that the server must properly handle this chaining.

A well-written server should. But a server could also perform preprocessing of SSH packets before sending responses, and it could notice that it has received USERAUTH_REQUEST before it has sent SERVICE_ACCEPT. The server could then choke on this.

One would imagine people would not do this, but I've dealt with an implementation that discards KEXINIT if it's received in the same network frame as the SSH version string.

Niels Möller <nisse%lysator.liu.se@localhost> , 12/3/2015 8:32 AM:

Damien Miller <djm%mindrot.org@localhost> writes:

>> But but but I waaaant to replace this awful SSH_MSG_SERVICE_REQUEST. :)
>>
>> Does no one agree that SERVICE_REQUEST + ACCEPT are pointless?
>>
>> A whole round-trip delay? For no benefit - in any known usage
>> scenario?

I think the entire point of the "awful" design, where you don't get a
second chance, just a disconnect in case the service isn't available, is
to eliminate that roundtrip delay.

You can send a service request for "ssh-userauth", followed back-to-back
by userauth requests for "none", PK_OK, whatever querying you like. And
one roundtrip later, you can compute the needed signature for a
likely successful publickey userauth request.

Regards,
/Niels

--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.