Speaking of implementation quirks...

[pgut001%cs.auckland.ac.nz@localhost (Peter Gutmann)]

While we're talking about implementation quirks/bugs, there are two (somewhat
minor) problems with the handling of 5.1 Maximum Packet Length in -transport.

The first is possible confusion with the definition in 5.1 Opening a Channel
in -connect.  I recently found an implementation that thinks that "maximum
packet size" is the maximum payload size (not the packet size), and when given
a max.packet size of nK, sends n+mK data (if anyone wants the ID string to
detect this for bug-workaround purposes, send me mail).  Based on this, it'd
be useful if the text could emphasise that the value refers to the total
packet size by adding the "(including length, padding length, payload,
padding, and MAC)" in -transport... I know that it seems pretty clear as it
is, but at least one implementor couldn't tell what was being referred to.

The second one is the requirement for "MUST be able to process packets with
uncompressed payload length of 32768 bytes or less".  My code runs in a
variety of embedded systems that don't have 32K of memory to play with, and
more to the point never *need* 32K packets, since all they're processing is
individual keystrokes, and can work quite well with 1K or less buffers.  So
far I've never found an implementation that refuses to handle shorter packets,
but I can just see something cropping up in the future that insists on the
other side using 32K packet buffers to send a single keystroke because that's
the magic number given in the spec.  Given that -connect 5.1 makes the packet
size negotiable, why does -transport 5.1 require non-negotiable 32K
packets/buffers?  Wouldn't it be better to say:

  ... MUST send packets no larger than the size requested during the channel-
  open negotiation in [SSH-CONNECT] (including length, padding length,
  payload, padding, and MAC).

My main concern here is that there are implementations that either can't or
don't need to support 32K packet sizes, but the text seems to imply that you
have to do this even if you'll never need (or don't have) more than 1K
buffers.

Peter.