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

Adam Roach <adam@nostrum.com> Tue, 12 September 2017 22:23 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Adam Roach <adam@nostrum.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-curdle-ssh-ext-info@ietf.org, Daniel Migault <daniel.migault@ericsson.com>, curdle-chairs@ietf.org, daniel.migault@ericsson.com, curdle@ietf.org
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150525503378.30416.5679611796140295482.idtracker@ietfa.amsl.com>
Date: Tue, 12 Sep 2017 15:23:53 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/sQyMjeVksd_Y7oeaZBJBOEjYUVY>
Subject: [Curdle] Adam Roach's Discuss on draft-ietf-curdle-ssh-ext-info-12: (with DISCUSS and COMMENT)

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] Adam Roach's Discuss on draft-ietf-curdl… Adam Roach
Re: [Curdle] Adam Roach's Discuss on draft-ietf-c… denis bider
Re: [Curdle] Adam Roach's Discuss on draft-ietf-c… Adam Roach