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

From: Alexey Melnikov <[email-masked]>
Date: Wed, 13 Sep 2017 05:00:27 -0700

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?

---

From: denis bider <[email-masked]>
Date: Wed, 13 Sep 2017 06:56:21 -0600

> 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

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.

> Also, as the client can always disconnect at any point, why mentioning
this

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 <[email-masked]>
wrote:

> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle
>

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 13 Sep 2017 14:12:05 +0100

On Wed, Sep 13, 2017, at 01:56 PM, denis bider wrote:
> 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.
> > null bytes at any position; in an unknown extension's extension-
> > value.> 
> 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.
> > It would be less confusing if you used the latter consistently
> > everywhere.> 
> NEWCOMPRESS, and USERAUTH_SUCCESS.> 
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
> <[email-masked]> wrote:>> Alexey Melnikov has entered the following ballot position for
>>  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"
>> 
>>  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:
>>    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:
>> 
>>    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.>> 
>>  in this>>  context?

---

From: denis bider <[email-masked]>
Date: Wed, 13 Sep 2017 07:48:59 -0600

> 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 <[email-masked]>
wrote:

> separately for each direction. Both lists are sent by both parties. Not
> just here, but also in KEXINIT.
>
> 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).
>
> 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:
> I implemented multiple capability negotiation frameworks and very few of
> everywhere.
> Oh, do you mean that this is never supposed to be sent by the client? In
> unknown public key algorithm (e.g. "rsa-sha2-256"). This can result in the
> client's IP address being locked out.
>
> I think explaining this in the document would be useful. "Penalties"
> sounds a bit vague.
>
> including

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 14 Sep 2017 05:22:31 -0700

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 <[email-masked]>
wrote:

> 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.
>
>
>> mean it is
>> that the server supports e.g. "rsa-sha2-256" before it attempts to use it,
>> to avoid a potential IP lockout.
>>

---

From: denis bider <[email-masked]>
Date: Thu, 14 Sep 2017 07:08:19 -0600

Submitted. :-)

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

>> > If you can list an example here for both the client side and the
>> server side, that would be great.
>>
>> 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).
>>
>> Note that it takes zero effort to allow for this use; and requires
>> writing unnecessary code to prevent.
>>
>> > My gut feeling is that you will never need this, so I wanted to know
>> if you actually
>> Common example - Extension A favored by Linux servers, Extension B
>> favored by everyone else. The story of SFTP.
>>
>>
>>> 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
>>> from the above quoted snippet.
>>>
>>> On Wed, Sep 13, 2017 at 6:00 AM, Alexey Melnikov <[email-masked]
>>> > wrote:
>>>
>>> certain that

---

From: Adam Roach <[email-masked]>
Date: Thu, 14 Sep 2017 09:15:25 -0500

> Submitted. :-)

Thanks. This newest version includes an example, but no further 
explanation of the encoding. Normative examples that implementors have 
to reverse engineer are generally bad for interoperability, since 
implementors have to guess at the handling for corner cases. Could you 
please add text that describes the encoding itself? It doesn't need to 
be overly complex, but it does need to be explained.

/a

---

From: denis bider <[email-masked]>
Date: Thu, 14 Sep 2017 11:16:36 -0600

But seriously, the spec defines the encoding. There needs to be no
guessing. The definition is right there. The example further fool-proofs so
there's no excuse for anyone to misunderstand.

Nested strings in SSH are not weird. They are used ubiquitously. For
example, in public key authentication, the public key is encoded as a
string. This string itself contains other strings which are part of the
public key format. This is not unusual. Anyone who works with SSH would be
familiar with this.

On Thu, Sep 14, 2017 at 8:15 AM, Adam Roach <[email-masked]> wrote:

> explanation of the encoding. Normative examples that implementors have to
> reverse engineer are generally bad for interoperability, since implementors
> have to guess at the handling for corner cases. Could you please add text
> that describes the encoding itself? It doesn't need to be overly complex,
> but it does need to be explained.
>
> /a
>

---

From: Adam Roach <[email-masked]>
Date: Thu, 14 Sep 2017 12:24:27 -0500

Ah, okay. I thought I'd asked earlier for an example of nested strings, 
and was interpreting your lack of response as a lack of such thing. If 
this kind of nesting is commonplace for the base protocol, then I'm okay 
with the current formulation. My concern was that this looked like 
something novel, but with only a loosely implied encoding.

I'll clear my discuss. Thanks for the explanation.

/a

On 9/14/17 12:16, denis bider wrote:
> guessing. The definition is right there. The example further 
> fool-proofs so there's no excuse for anyone to misunderstand.
>
> string. This string itself contains other strings which are part of 
> the public key format. This is not unusual. Anyone who works with SSH 
> would be familiar with this.
>
> On Thu, Sep 14, 2017 at 8:15 AM, Adam Roach <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     explanation of the encoding. Normative examples that implementors
>     have to reverse engineer are generally bad for interoperability,
>     since implementors have to guess at the handling for corner cases.
>     Could you please add text that describes the encoding itself? It
>     doesn't need to be overly complex, but it does need to be explained.
>
>     /a
>
>

---

From: denis bider <[email-masked]>
Date: Thu, 14 Sep 2017 11:31:21 -0600

Just to be sure, I've uploaded a new version that does contain the extra
explanation as well. Let me know if it's clearer.

On Thu, Sep 14, 2017 at 11:24 AM, Adam Roach <[email-masked]> wrote:

> and was interpreting your lack of response as a lack of such thing. If this
> kind of nesting is commonplace for the base protocol, then I'm okay with
> the current formulation. My concern was that this looked like something
> novel, but with only a loosely implied encoding.
>

---

From: Adam Roach <[email-masked]>
Date: Thu, 14 Sep 2017 12:46:46 -0500

Thanks! The changes look good.

/a

On 9/14/17 12:31, denis bider wrote:
> Just to be sure, I've uploaded a new version that does contain the 
> extra explanation as well. Let me know if it's clearer.
>
> On Thu, Sep 14, 2017 at 11:24 AM, Adam Roach <[email-masked] 
>     Ah, okay. I thought I'd asked earlier for an example of nested
>     strings, and was interpreting your lack of response as a lack of
>     such thing. If this kind of nesting is commonplace for the base
>     protocol, then I'm okay with the current formulation. My concern
>     was that this looked like something novel, but with only a loosely
>     implied encoding.
>
>>     But seriously, the spec defines the encoding. There needs to be
>>     no guessing. The definition is right there. The example further
>>     Nested strings in SSH are not weird. They are used ubiquitously.
>>     For example, in public key authentication, the public key is
>>     encoded as a string. This string itself contains other strings
>>     which are part of the public key format. This is not unusual.
>>     Anyone who works with SSH would be familiar with this.
>>
>>         Thanks. This newest version includes an example, but no
>>         further explanation of the encoding. Normative examples that
>>         implementors have to reverse engineer are generally bad for
>>         interoperability, since implementors have to guess at the
>>         handling for corner cases. Could you please add text that
>>         describes the encoding itself? It doesn't need to be overly
>>         complex, but it does need to be explained.
>>
>>         /a
>>
>>
>
>