Re: [Curdle] Mirja Kühlewind's No Objection on draft-ietf-curdle-ssh-ext-info-12: (with COMMENT)

Hello Mirja:

> What happens if the server received more than one (different)
> EXT_INFO messages or the client receives more than two?

Such sender behavior is incorrect according to the spec. Receiver behavior
is implementation dependent.

In the absence of a specific reason to do so, I think it's
counter-productive to define receiver behavior for all possible ways a
sender could violate the spec. It complicates both the implementation and
the spec. It seems best to let implementations handle that in whatever way
is convenient.

> One question regarding flow control: I understood that some
> implementation simply set the max value for the initial window,
> however, if you don't even have a max window how do you
> ensure that the receiver is not over loaded and what do you
> do if you receive more data that you can handle?

The max value hack and the no-flow-control extension behave similarly until
4 GB of data is transferred. When amount of data transferred approaches 4
GB, the max value hack has to send a window adjust, whereas an
implementation using the no-flow-control extension can just keep going.

In both cases, flow control is provided by TCP. If the receiver can't
handle the data, it doesn't read it from the socket.

It is for this reason that the no-flow-control extension specifies there
can be at most one SSH channel at a time when this extension is in effect.
The TCP flow control only works satisfactorily with a single channel. In my
view at least, applications that implement multiple channels should
implement proper per-channel flow control as originally specified by SSH.

>  I'm by far not an expert but I would have expected that
> there are additional security consideration for elevation
> and mybe even flow control... no?

Not that I know of. There's certainly no impact on flow control.

If there's a security consideration, it's that this extension would be nice
for everyone to implement - including vendors who hate Windows - so that
SSH sessions made by administrators to Windows servers could be established
without elevation by default; and with elevation only if requested by the
user (e.g. through a client command line flag).

Presently, without this extension, SSH sessions made by administrators to
Windows servers have to always be elevated by the SSH server by default.
This decision needs to be made before authentication, because after
authentication, the security context for the session is already
constructed. If there's no way for the client to indicate this choice, the
server always needs to create an elevated session in case the user wants to
exercise their administrative access.

If this extension is supported, the user has the option to request no
elevation, e.g. because they know they're only going to need their regular
use permissions, not their administrative access. If the extension were to
become universally supported, then no elevation (being the safer choice)
could become the server-side default.

On Mon, Sep 4, 2017 at 7:18 AM, Mirja Kühlewind <ietf@kuehlewind.net> wrote:

> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-curdle-ssh-ext-info-12: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> 1) What happens if the server received more than one (different) EXT_INFO
> messages or the client receives more than two?
>
> 2) One question regarding flow control: I understood that some
> implementation
> simply set the max value for the initial window, however, if you don't even
> have a max window how do you ensure that the receiver is not over loaded
> and
> what do you do if you receive more data that you can handle?
>
> 3) I'm by far not an expert but I would have expected that there are
> additional
> security consideration for elevation and mybe even flow control... no?
>
> 4) Thanks for quickly addressing the genart review!
>
>
> _______________________________________________
> Curdle mailing list
> Curdle@ietf.org
> https://www.ietf.org/mailman/listinfo/curdle
>