Re: I-D ACTION:draft-galb-secsh-publickey-subsystem-02.txt

["Brent McClure" <mcclure%swcp.com@localhost>]

----- Original Message ----- 
> Under ``2.1 Opening the Public-Key Subsystem'', it is said that
> clients SHOULD reject a request for this subsystem.  I suspect that
> that should instead be a MUST.

It seems to me that leaving it SHOULD would be more consistent with
at statement in draft-ietf-secsh-connect-17.txt, Section 4.5 
"Starting a Shell or a Command". With regard to clients receiving
subsystem requests, it just says "The client SHOULD ignore these messages".
It also seems like a client receiving an open request for this subsytem
falls into the category of being something abnormal rather than something
that could expose a risk.

The requests in that document that SHOULD be rejected seem to be
the ones that don't make sense for a client (like receiving a "pty" or 
"session" request). The ones that MUST be rejected seem to be ones
that may be indication of possible foul play (such as unsolicited X11 forwarding).
I think this case is more the former.

> 
> Under ``2.2 Requests'', is there a good reason to disallow a client
> sending more than one request and expecting that the server will
> respond to them in order?  (If there is, I think the draft should
> probably have a sentence explaining what problem that requirement is
> solving; if not, pipelined requests should be allowed.)

Our view was that this was the simplest thing to implement. And, given
that this is a low-bandwidth and intermittently-used protocol, a 
one-request-at-a-time scenario seemed sufficient. Most of the
time a client will get a listing of keys, add a new one or delete one
and that's it. It could be argued that the one-at-a-time requests
requires more state to be maintained than being able to shove a bunch
of requests down a pipe, but if you are checking the results of each
request then even the pipelined implementation is going to require state.
Anyhow that was our take on it.

--Brent