Re: Core draft last call update.

[Derek Fawcus <dfawcus%cisco.com@localhost>]

On Mon, Mar 11, 2002 at 08:51:15AM -0700, Joseph Galbraith wrote:
> 
> Complexity is the enemy.  Complexity introduces bugs.  If it was
> just complexity in the client,  that the client could chose whether
> or not to deal with, I might be more inclined to 'not care'.

That is where I see the complexity,  the server behaviour would be fixed.
Instead of the current "shutdown complete SSH connection",  it would be
either "silent discard" or "generic error response".

> But, it also introduces complexity in the server (which in my opinion
> is more sensitive to bugs.)  And the server MUST bear that complexity.

Agreed.  However my contention is that this is only client complexity,
and then only if the client chooses to invoke the triggering condition.

> If a server implements the current language,  there is very little
> chance of a packet for a higher level being processed before
> the user correctly authenticates (due to server bug.)  Sure it could
> happen,  but it isn't likely.
> 
> On the other hand, it seems more likely to happen with the new complexity.

Disagree.  You're using the same flag (has authentication passed) to
simply perform a different action.  The packet in question has to be
inspected in either case,  instead of closing the connection you
simply silent discard or send a generic error response.

There is no additional complexity,  the server behaviour would change
from one fixed type of behaviour to another fixed type of behaviour.

> Also, since we are in last call,  we have very little time to
> analyze the implications and behaviors of the change.

We have as much time as we choose to take.

(i.e. the other thread about CBC mode...)

> It doesn't seem like we stand to gain enough to take the risk.

OK.  The granted,  gain is quite small.  It's the elimination of
one RTT.  The issue being that on long RTT links,  we already
have a multi RTT set up time.

Other parts (say the key exchange) are replaceable in the base spec,
and a protocol with a small number of RTs could be used.  This part
of the spec is fixed,  and precludes any form of client optimisation.

> Maybe we should discuss it more for 2.1 after we've gotten
> 2.0 to RFC status.

Well if the consensus is for that,  I'll accept it.

I threw the suggestion in 'cause it seemed a small change,  with no
security impact,  little implementation impact,  and because I couldn't
see a _security_ (as opposed to an implementation) reason for the
current language in the draft.

DF