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

[Alexey Melnikov <[e-mail]>]

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