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

From: Adam Roach <[email-masked]>
Date: Tue, 12 Sep 2017 15:23:53 -0700

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?

---

From: denis bider <[email-masked]>
Date: Tue, 12 Sep 2017 23:34:08 -0600

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 <[email-masked]> wrote:

> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle
>

---

From: Adam Roach <[email-masked]>
Date: Wed, 13 Sep 2017 11:34:26 -0500

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

Thanks. I think an example would be very useful as an adjunct to an 
explanation. If there is some other place this "lists inside strings" 
construct is used, please point to it. Otherwise, please include one or 
two sentences that explain the intended structure.

/a