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

> It is not clear for me from the formatting whether the first
> name-list is sent by the client and the second by the server,
> or both lists are always included in the value. I suspect it
> is the former, but can you please clarify?

SSH negotiates compression, integrity, and encryption algorithms separately
for each direction. Both lists are sent by both parties. Not just here, but
also in KEXINIT.

This is used rarely in practice, but this draft keeps to the same practice,
so as not to bundle a reduction of functionality (i.e. requiring same
compression for both directions) in the same package as an extension (i.e.
providing a mechanism for delayed activation of compression).

The next draft will include an example of encoding, as suggested by Adam.
This should make things clearer, even for readers unfamiliar with SSH.

> 1) Sentences like:
> Use of  Receivers MUST tolerate any sequence of bytes; including
> null bytes at any position; in an unknown extension's extension-value.

Reads fine to me. Still, I changed these to use dashes.

> Can you provide an example of why depending on order
> would be useful? This potentially makes it harder to implement.

It is the nature of an extension mechanism that it intends to be open to
unforeseen circumstances. If we could come up with examples for all
possible future uses, extensions would not be required.

For this reason, I would prefer if you can demonstrate how allowing for
this possibility makes anything harder to implement. In my implementation
experience, it doesn't.

> In several places you use EXT_INFO instead of SSH_MSG_EXT_INFO.
> It would be less confusing if you used the latter consistently everywhere.

This doesn't just go for EXT_INFO, it also goes for KEXINIT, NEWKEYS,
NEWCOMPRESS, and USERAUTH_SUCCESS.

OK, I changed this to use the SSH_MSG_ prefix always.

>   This extension is sent by the server, and contains a list of public
>   key algorithms that the server is able to process as part of a
>   "publickey" authentication request. If a client sends this extension,
>   the server MAY ignore it, and MAY disconnect.
>
> Why would the client disconnect when seeing this extension? Does it mean
it is
> broken?
>
> Also, as the client can always disconnect at any point, why mentioning
this
> here?

I believe you have misread the text in this case. It should be clear from
the above quoted snippet.

> Can you elaborate on what do you mean by "authentication penalties"
> in this context?

SSH servers commonly implement some way of locking out or throttling IP
addresses that make frequent login attempts, so as to deter brute force
password guessing, username guessing, and similar undesired behaviors.

Some servers apply such penalties to clients that attempt to use an unknown
public key algorithm (e.g. "rsa-sha2-256"). This can result in the client's
IP address being locked out.

The "server-sig-algs" extension provides a way for the client to know that
the server supports e.g. "rsa-sha2-256" before it attempts to use it, to
avoid a potential IP lockout.

On Wed, Sep 13, 2017 at 6:00 AM, Alexey Melnikov <aamelnikov@fastmail.fm>
wrote:

> Alexey Melnikov 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:
> ----------------------------------------------------------------------
>
> This is generally a good and useful document. I have some minor comments I
> would like to discuss:
>
> 3.2.  "delay-compression"
>
>   This extension MAY be sent by both parties as follows:
>
>     string         "delay-compression"
>     string:
>       name-list    compression_algorithms_client_to_server
>       name-list    compression_algorithms_server_to_client
>
> It is not clear for me from the formatting whether the first name-list is
> sent
> by the client and the second by the server, or both lists are always
> included
> in the value. I suspect it is the former, but can you please clarify?
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> 1) Sentences like:
>   Use of  Receivers MUST tolerate any sequence of bytes; including null
> bytes
>   at any position; in an unknown extension's extension-value.
> or
>  In particular, applications MUST  tolerate any sequence of bytes;
> including
>  null bytes at any position;  in an unknown extension's extension-value.
>
> Use of punctuation is not my strongest point, but I am reasonably certain
> that
> use of ";" is not correct here. I think you should use (). Otherwise these
> sentences are reading as a list of 3 things, yet in both cases the 3rd is a
> continuation of the 1st.
>
> 2) In Section 2.5:
>
>  The relative order in which extensions appear in an
>   EXT_INFO message MUST be ignored by default; but an extension MAY
>   specify that the order matters for that extension, in a specific way.
>
> Can you provide an example of why depending on order would be useful? This
> potentially makes it harder to implement.
>
> In several places you use EXT_INFO instead of SSH_MSG_EXT_INFO. It would be
> less confusing if you used the latter consistently everywhere.
>
> 3) In 3.1:
>
>   This extension is sent by the server, and contains a list of public
>   key algorithms that the server is able to process as part of a
>   "publickey" authentication request. If a client sends this extension,
>   the server MAY ignore it, and MAY disconnect.
>
> Why would the client disconnect when seeing this extension? Does it mean
> it is
> broken?
>
> Also, as the client can always disconnect at any point, why mentioning this
> here?
>
>   If a server does not send this extension, a client MUST NOT make any
>   assumptions about the server's public key algorithm support, and MAY
>   proceed with authentication requests using trial and error. Note that
>   implementations are known to exist that apply authentication penalties
>   if the client attempts to use an unexpected public key algorithm.
>
> Can you elaborate on what do you mean by "authentication penalties" in this
> context?
>
>
> _______________________________________________
> Curdle mailing list
> Curdle@ietf.org
> https://www.ietf.org/mailman/listinfo/curdle
>