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

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

> If we're going to make this change, could we also consider moving
> *all* ciphers to nonencrypted lengths?  This currently requires
> horribly complex code to process,

That wasn't my experience as an implementor.  Perhaps you're trying to
(ab)use cryptosystem interfaces not designed for that style of use?

> There's a 32-bit flags field in the handshake that's currently
> unused, one bit could be used to indicate unencrypted lengths.

I suspect that will not interoperate well with implementations not
supporting plaintext lengths.  I see no guidance in 4253 as to what
protocol speakers should do if that flags field is nonzero (or, more
generally, has non-understood bits set) in an incoming packet, and
suspect I'm not the only implementor who's simply ignored it (which
won't interoperate) or checked it and errored if it's nonzero (which
won't interoperate either).  That flags field was ill-thought-out, and
I wish I'd noticed it before the drafts were turned into RFCs.

I would suggest creating new packet type for negotiating options like
this.  As a strawman:

      byte         SSH_MSG_OPTION (value = 7)
      string       option name
      ...          option-specific data

The option name uses the DNS-based extensibility mechanism (4251
section 6); all data after the option name, including types and values,
is option-specific and is described in the definition of the option.
SSH_MSG_OPTION may be sent at any time, except that specific option
definitions may impose additional restrictions for packets naming that
option.  Implementations that do not understand SSH_MSG_OPTION MUST
respond to it with SSH_MSG_UNIMPLEMENTED, as specifeid in 4253 11.4.
The option name "unimplemented" is reserved; it is used to indicate
that SSH_MSG_OPTION is implemented but that a particular option is not
implemented (or is disabled for the connection in question by a
configuration mechanism).  Its additional data consists of a single
string, which contains the unimplemented option name from the request
that provoked the packet.  SSH_MSG_OPTION packets with "unimplemented"
as the option name MUST NOT be sent under any other circumstances.
Option definitions MUST indicate what semantics SSH_MSG_UNIMPLEMENTED
and "unimplemented" responses have for the options they define.

As a further strawman:

I propose the option name "cleartext-packet-lengths".

Option-specific data is a single string, which MUST be "on", "off",
"ack", "nak", or "mark".  Packets for this option with other than
exactly one string of additional data, or with other than one of those
five strings as the additional data string, are reserved for future
standardization; an implementation of this spec MUST respond with a
"nak" message to any such packet it recieves.

Cleartext packet length use is negotiated separately in each direction.
There are two states (in each direction): the negotiated state and the
live state.  The negotiated state is used to negotiate the option; the
live state controls whether packet generation is affected.  Both states
are "off" at connection startup.

Negotiation for each direction is initiated by the peer sending packets
in that direction; the sender sends an "on" or "off" packet, indicating
whether it proposes to turn the option on or off, to which the receiver
MUST respond with an "ack" or "nak" packet, indicating acceptance or
rejection of the request.  A sender MUST change its record of the
negotiated state to match the corresponding "on" or "off" packet, upon
receiving an "ack" response; it MUST NOT make any such change upon
receiving a "nak" response.  A sender may also send a "mark" packet;
when it does so, it MUST, between sending that packet and the packet
immediately following, copy the negotiated state to the live state.  A
sender MUST NOT change its live state under any other circumstances.
(To avoid indeterminate behaviour, a sender MUST NOT send a "mark" when
an "on" or "off" packet has been sent but no corresponding "ack" or
"nak" has been received, unless the resulting negotiated state would be
the same regardless of which response is received.)

A sender MAY choose to delay, or not send at all, a "mark" after a
negotiation, even one that changes the negotiated state.

There also is no requirement that any change to the negotiated state,
nor indeed any negotiation at all, take place before sending a "mark"
(though the "mark" will, of course, not correspond to a change in the
live state in such a case).

An SSH_MSG_UNIMPLEMENTED packet or an "unimplemented" SSH_MSG_OPTION
packet (collectively, an "error packet") must always be handled so as
to disable the option - that is, when it is in response to an "on", it
is to be treated as a "nak"; in response to "off", as an "ack".
Implementations MUST NOT generate error packets in response to packets
for this option after responding in any other way to any packet for
this option on the same connection (but MAY switch in the other
direction, responding with a non-error packet after responding with an
error packet).  This means that an error packet in response to a "mark"
can be ignored, since the "mark" must not mark any actual change in the
live state, and that an error packet in response to an "ack" or "nak"
indicates a broken implementation.

When the live state is "off", the connection operates as it would if
this option were not implemented.  When the live state is "on", the
binary packet protocol described in 4253 section 6 is modified.  The
definition of the value in the packet_length field is unchanged, but
that field is not part of the encryption data stream; it is effectively
removed from the packet for purposes of computing padding amounts and
encryption.  It is sent in the data stream, unencrypted, before (the
encryption of) the rest of the packet.

/~\ 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