Re: Secure Shell WG: what's left?

[der Mouse <mouse%Rodents.Montreal.QC.CA@localhost>]

>> I believe my implementation does it correctly according to some
>> version of the draft (probably -01).
> But having implemented it, you know there are problems, like what to
> do for the links that are not over IP.

Right - though that's not a problem in practice for me, because I don't
yet support anything else.

> I believe that particular collision is deliberate, to allow a client
> to tell which version of the protocol is supported.  It's possible
> the mechanism needs some work, in which case we should do that.

Hmm.  I'd feel more comfortable about it if the previous protocol were
documented.  But that's part of what we're talking about, so I think
this point is actually spurious.

>> How can I best help this happen?  Should I sit down with the 1.x
>> code and try to glark a spec for its agent forwarding protocol?
> As I understand it, there isn't really an agent forwarding protocol,
> aside from the messages defined in the ssh spec for that purpose.
> They basically just channel the same protocol that is spoken between
> ssh client and agent, with no changes.

Ah, very much like agent-02 but without FORWARDING_NOTICE?  Then what
we need is to document that fact, and write up something for the
client<->agent protocol (which I believe we should do if we try to
retain the backward-compatability feature).

> I think it's premature to write up a spec based on the old protocol,
> unless/until we decide we want to document and extend that and
> abandon what's in the agent draft.

Agreed - except that, as I remarked above, if we try to retain
compatability, I think a document describing the old protocol should
exist somewhere.

> Before we can do that, I think we need to answer a few questions...

> - Is the tracing of forwarded connections worth keeping?

I'm not sure.  My agent implementation doesn't do anything with
FORWARDING_NOTICE packets but skip them - but on the other hand, I
certainly can see a potential desire that the agent not respond to
"distant" requests.  In my own ssh_config (I'm still using ssh 1.x on
some machines) I have a lot of stanzas controlling whom I turn on agent
forwarding to.  It would be really convenient to be able to control
this in agent configuration, controlling whom the agent is willing to
act for, rather than in the ssh client configuration.

The agent does need to trust the client to insert the notices, but the
local ssh client is presumably trusted.

> - Are the messages used by the old protocol too limited, such that
>   new messages need to be defined in order to do everything we need?

As you note, this is approximately impossible to answer without knowing
the old protocl - which for me, at least, means having some kind of
description of it.

But I will note that in my implementation I found I had to use private
requests and channel types in order to make agent forwarding work right
with connection sharing, and that's without any attempt at backward
compatability.

> - Is there some way we can add extensions to the old protocol in a
>   sane fashion, so we don't crash the agent or desync the protocol if
>   one side doesn't understand an extension?

Again, I couldn't say without seeing a spec for the old protocol - and,
if it contains the lacunae I expect it to, some kind of description for
existing implementations as well.

But if the existing protocol and implementations are not designed with
any extension mechanism in mind, I don't think there is anything we can
do here.  If agents are not designed to support extensions, anything
not conforming to their protocol will break them, so clients can't send
anything not conforming; and if clients are not designed to support
extensions, the agent cannot return anything beyond the old behaviour
when responding to old requests, or it risks breaking old clients.
This locks both sides into sticking to the old protocol.

The only reason the existing agent drafts can do old-version sensing at
all is that they aren't using the old protocol - there is a message,
conforming to the old protocol, to which they assign a different
meaning from what the old protocol does.

We could do the same thing, but then we're not just adding extensions
to the old protocol; then we're designing a new protocol with some
compatability.  (The major difference is that a new agent will break an
old client, because it will respond in the new-protocol way to an
old-protocol request.  The reason the draft protocol doesn't have this
problem is that they are depending on a hole in the spec interacting
with a lucky property of existing implementations: the old
list-identities request can, de-facto if not de-jure, exist in multiple
forms, all of which the old agents accept but only one of which the old
clients generate.)

I see no major difference between adopting the old protocol with some
extension hooks (such as taking advantage of the loophole agent-02
does) and designing a new protocol with backward compatability.  It's
really a question of how much of the old protocol we can steal intact
and how much we need to invent - a difference of degree rather than
kind.  It's also something I can't really speak to without a
description of the old protocol at hand, too.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse%rodents.montreal.qc.ca@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B