Re: [Curdle] Adam Roach's Discuss on draft-ietf-curdle-ssh-ext-info-12: (with DISCUSS and COMMENT)

[denis bider <[e-mail]>]

Comment 1: Good point. Example is useful. Will add example.

Comment 2: This is meant along the lines of "*If* the server sends a second
EXT_INFO, it MUST be sent at this point". Will look into clarifying the
language.

On Tue, Sep 12, 2017 at 4:23 PM, Adam Roach <[e-mail]> wrote:

> Adam Roach has entered the following ballot position for
> draft-ietf-curdle-ssh-ext-info-12: Discuss
>
> 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/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> I am concerned that the syntax of "delay-compression" is not specified with
> enough detail to ensure compatible interoperation. I may have missed
> something
> in the protocols this document relies upon; but if I haven't, I think this
> needs additional specification.
>
> The current definition for "delay-compression" is:
>
>     string         "delay-compression"
>     string:
>       name-list    compression_algorithms_client_to_server
>       name-list    compression_algorithms_server_to_client
>
> In reading through this document (and skimming RFC4251), I don't see
> anything
> that indicates the on-the-wire encoding for "string containing multiple
> name-lists." I suspect that the intention is something like
> [string-length][list-length]value[list-length]value; however, that
> requires
> making a number of unstated assumptions, and I doubt that all implementors
> will
> make the same assumptions.
>
> To be clear, what I mean by my formulation above would result in the value
> field of client_to_server="foo,bar" and server_to_client="bar,baz" being
> encoded as:
>
> 00 00 00 16 00 00 00 07 66 6f 6f 2c 62 61 72 00 00 00 07 62 61 72 2c 62 61
> 7a
>
> If this is the intention, please be explicit (and, ideally, provide an
> example).
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Section 2.4:
>
>   (*) The message MUST be sent at this point for the following reasons:
>
> It's not clear how this normative requirement interacts with this MAY:
>
>   The second opportunity is just
>   before (*) SSH_MSG_USERAUTH_SUCCESS, as defined in [RFC4252]. The
>   server MAY send EXT_INFO at the second opportunity, whether or not it
>   sent it at the first.
>
> One seems to merely allow it, while the other seems to demand it. Could
> you add
> some text that clarifies this apparent contradiction?
>
>
> _______________________________________________
> Curdle mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/curdle
>