Re: applying AES-GCM to secure shell: proposed "tweak"

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> With regard to the negotiation itself, I think it might be cleaner to
> have three separate messages: [...]

That would work too.  I was trying to conserve (scarce) message number
space by using a single message number with the distinction conveyed by
your three messages being part of the option negotiation, but this
looks sufficiently general it'd be OK too.  (And options which really
need more elaborate negotiation can always make REQUEST and REPLY
rubber-stamps and do the real work with DATA.)

One thing is not clear from this: is option support negotiated
separately in each direction?  If not, what happens if two REQUEST
packets for the same option, one in each direction, cross in flight?
(It seems to me most ssh-like to negotiate separately in each
direction.  This means two packets each way instead of one, but they
are streamable packets, so I don't see that as a big deal.)

Oh, the spec also needs to define what SSH_MSG_UNIMPLEMENTED means in
response to these.  Presumably this counts as a nak reply when in
response to _REQUEST and a protocol error for the other two, but it
needs to be stated.

> In the case of the cleartext-packet-lengths option, the option data
> in the _REQUEST must be empty, and any implemention supporting the
> option MUST respond to the _REQUEST with an ack; that is, the nak
> response may not be sent for this option.  [...] The side sending the
> _REPLY message may begin using cleartext lengths immediately by
> including option data of "on" in the _REPLY packet.

This makes it sound as though you're assuming option support is not
negotiated separately in each direction.

> Once the option has been negotiated, either side may switch between
> sending cleartext and encrypted lengths whenever it wants, by sending
> SSH_MSG_OPTION_DATA with option "cleartext-packet-lengths" and data
> "on" to indicate lengths will be cleartext starting with the next
> packet, or "off" to indicate they will be encrypted (when encryption
> is in effect).

> I think this is cleaner than the approach der Mouse suggested,

Yes, I think I agree.  It's certainly simpler; since I think it's also
sufficient for the task, that makes it cleaner. :)

> because it allows either side to switch modes at any time and makes
> it clear what the new mode will be on every switch.  It does this at
> the expense of eliminating the ability of the peer to accept or
> reject any mode change, instead requiring that once the option has
> been negotiated, each peer be willing to accept either encrypted or
> unencrypted lengths at any time (though an encryption algorithm may
> require the option be enabled).

What happens if such an encryption algorithm is in use and the
implementation receives a _DATA/"off" packet?  (Yes, it would be a
strange thing for an implementation to send, but I think it needs to be
addressed, even if only with a "this is a protocol error from which no
recovery is specified" remark in the encryption algorithm definition.)

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