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

[Eric Rescorla <[e-mail]>]

It sounds like we have resolutions to both Adam's and Alexey's issues.
Denis, can you please submit a new draft and then (assuming it is
satisfactory to them) Adam and Alexey can clear.

-Ekr


On Wed, Sep 13, 2017 at 6:48 AM, denis bider <[e-mail]>
wrote:

> > 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
>>
>>
>>
>
> _______________________________________________
> Curdle mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/curdle
>
>