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

[denis bider <[e-mail]>]

> If you can list an example here for both the client side and the server
side, that would be great.

There is no difference between what the two send. Added a line to explain
that as well.


> capability negotiation frameworks and very few of them (at the moment
> I can't think of any, actually) have dependencies on order

Not sure if I understand you correctly, but SSH is completely dependent on
order in algorithm lists (client algorithm order matters), and I believe so
is TLS (server algorithm order matters).

The list of extensions in SSH_MSG_EXT_INFO is order agnostic by default,
because the extensions are assumed to be independent. However, I see no
reason to prevent it from becoming an algorithm list for some purposes, if
the goals of some extensions overlap.

Note that it takes zero effort to allow for this use; and requires writing
unnecessary code to prevent.

I'm not enthusiastic about writing unnecessary code to prevent a particular
type of use, just to prevent people doing something in the future. The
idea, honestly, seems stupid.


> My gut feeling is that you will never need this, so I wanted to know if
you actually
> can provide an example that depends on order.

It would have to be two or more extensions with overlapping goals. For
example:

1. Extension A attempts to address situation X.

2. Extension A is flawed in situation Y, which bothers some people.

3. Extension B is developed to addresses situations X+Y. However, being
more complete, it is much more complex than Extension A. Past experience
shows that there will be existing servers which will only do Extension A
well. They might implement B, but it will be a hack job.

4. Therefore, Extension B specifies itself as a potential replacement for
Extension A, but allows servers to signal which one they prefer by
controlling the order in which the extensions appear. If both extensions
are advertised by both parties, then Extension B is used IF it is listed
first by the server. Otherwise, if Extension A is listed first, it is used.

Common example - Extension A favored by Linux servers, Extension B favored
by everyone else. The story of SFTP.


> I think explaining this in the document would be useful.
> "Penalties" sounds a bit vague.

Added footnote to explain.

denis




On Wed, Sep 13, 2017 at 7:12 AM, Alexey Melnikov <[e-mail]>
wrote:

> On Wed, Sep 13, 2017, at 01:56 PM, denis bider wrote:
>
> > 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.
>
> Yes, I think this will help. If you can list an example here for both the
> client side and the server side, that would be great.
>
>
> > 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.
>
> I implemented multiple capability negotiation frameworks and very few of
> them (at the moment I can't think of any, actually) have dependencies on
> order. Dealing with one element at a time seems a bit simpler.
>
> My gut feeling is that you will never need this, so I wanted to know if
> you actually can provide an example that depends on order.
>
> > 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.
>
> Thank you.
>
>
> >   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.
>
> Oh, do you mean that this is never supposed to be sent by the client? In
> this case, yes, I misread it. Never mind.
>
>
> > 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.
>
> I think explaining this in the document would be useful. "Penalties"
> sounds a bit vague.
>
> On Wed, Sep 13, 2017 at 6:00 AM, Alexey Melnikov <[e-mail]>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/curdle
>
>
>