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

[denis bider <[e-mail]>]

Submitted. :-)

On Thu, Sep 14, 2017 at 6:22 AM, Eric Rescorla <[e-mail]> wrote:

> 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/stat
>>> ement/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
>>
>>
>