openssh unix dev - Apr 2018 - draft-miller-ssh-agent-02: extensions and success messages

Hi,

I've been reading the RFC draft for the OpenSSH agent protocol and
trying to understand the extension mechanism. It seems like a client,
after sending an extension message, will have to then interpret any
following success (0x6) message differently according to the extension
request just sent. The example with the "query" extension returning a
success message with extra data appended would seem to imply that, too.
Is that correct?

If so, I would love to get some insight into why this was chosen over
having an "extension reply" message number or something like that. It
seems to me that the protocol up until now has always been stateless --
you didn't have to know what you sent last in order to parse and
validate received data -- which generally makes implementations nice and
simple. After this change, client impls will have to change their
parsing of the success message dramatically after sending each extension
request message (and will have to track which ext they last sent etc),
since it doesn't include enough information in the message itself any
more to figure out what it should contain.

Sorry if I'm retreading on a discussion that's already been had (I did
search this list but couldn't find anything)

Thanks!

On Wed, 4 Apr 2018, Alex Wilson wrote:
> Hi,
> 
> I've been reading the RFC draft for the OpenSSH agent protocol and
> trying to understand the extension mechanism. It seems like a client,
> after sending an extension message, will have to then interpret any
> following success (0x6) message differently according to the extension
> request just sent. The example with the "query" extension
returning a
> success message with extra data appended would seem to imply that, too.
> Is that correct?
> 
> If so, I would love to get some insight into why this was chosen over
> having an "extension reply" message number or something like
that. It
> seems to me that the protocol up until now has always been stateless --
> you didn't have to know what you sent last in order to parse and
> validate received data -- which generally makes implementations nice and
> simple. After this change, client impls will have to change their
> parsing of the success message dramatically after sending each extension
> request message (and will have to track which ext they last sent etc),
> since it doesn't include enough information in the message itself any
> more to figure out what it should contain.
I don't follow - clients always have to know that the last message sent
was, otherwise they wouldn't be able to disambiguate the shared
SSH_AGENT_SUCCESS / SSH_AGENT_FAILURE.

If it's a problem in practice, then I guess I could add an extension-
specific reply message to a future draft, but I'm struggling to think of
a situation in which it would be needed.

BTW nothing at present implements any extensions AFAIK.

-d

On 04/04/18 21:56, Damien Miller wrote:
> 
> I don't follow - clients always have to know that the last message sent
> was, otherwise they wouldn't be able to disambiguate the shared
> SSH_AGENT_SUCCESS / SSH_AGENT_FAILURE.
The format of that message doesn't change though -- it's always a single
byte (so you don't need that information in the function that actually
parses the message). With this proposal that is no longer the case. I
mean, maybe it's a pointless concern and things are fine as proposed. I
wrote my client implementation to not have any of that state there for
parsing messages to make it easier to test and fuzz. I know other
implmentations don't necessarily do the same thing.
> 
> If it's a problem in practice, then I guess I could add an extension-
> specific reply message to a future draft, but I'm struggling to think
of
> a situation in which it would be needed.
> 
> BTW nothing at present implements any extensions AFAIK.
> 
In case you want an example, in the prototype code I've been working on
for a hypervisor-controlled SSH agent for each VM/machine at work I'm
presently squatting on some high message ID numbers for retreiving
additional information from the agent. I would like to change these to
use the extension mechanism as soon as it's finalised.

Thanks for entertaining my question anyway. :)