Subject: RE: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation

From: Peter Gutmann <[email-masked]>
Date: Sun, 8 Nov 2015 02:22:44 +0000

denis bider <[email-masked]> writes:

>(1) I have uploaded a new version of the RSA SHA-2 draft:
>
>https://tools.ietf.org/html/draft-rsa-dsa-sha2-256-02

Has anyone else implemented this?  I've dropped in some quick partial support
for it, and I can't see why it wouldn't work transparently to replace the
existing form, but being able to test against someone else would be good.

Hmm, just saw an issue, I used "ssh-rsa-sha2..." instead of rsa-..., should
the new names also have the "ssh-" prefix to match existing usage?  As I see
it the name has to identify the format used, "ssh-", and the signature
algorithm, "rsa-sha...", having just the latter makes it difficult to specify
other signature formats.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 8 Nov 2015 02:41:20 +0000

denis bider <[email-masked]> writes:

>I can make available an experimental build of our SSH Server that will implement these algorithms.
>
>Might need to give me a few hours.

No hurry, I'm in the middle of hacking my code to pieces with a static source
analyser, which could take days...

Peter.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sat, 07 Nov 2015 22:09:25 -0500

On Sun, 2015-11-08 at 02:30 +0000, denis bider wrote:
> The "ecdsa-sha2-..." algorithm names (RFC 5656) do not use the "ssh-" prefix.
> 
> Neither do the new formats in RFC 6187, i.e. "x509v3-rsa2048-sha256" and "x509v3-ecdsa-sha2-...".
> 
> In my opinion, the "ssh-" prefix is superfluous. The context of SSH is
> implied by where the names are used.

It's superfluous except for "ssh-rsa" and "ssh-dsa", where it serves in
various out-of-protocol contexts to distinguish between these and the
corresponding SSHv1 key types.

> The prefix would make sense if it were needed to disambiguate from
> something. However, I am not aware of any proposal for SSH to do a
> wholesale import of algorithm names from some other, SSH-unaware spec.
> Moreover, if such names were imported, then THOSE names would be
> prefixed with something, not the SSH native algorithm names.

Right, agreed.

---

From: denis bider <[email-masked]>
Date: Sun, 8 Nov 2015 09:10:53 +0000

I have set up a server where we can test support for RSA SHA-2.

You can connect to it at:

experiment.bitvise.com:10712

It is set up to test the new RSA SHA-2 signature methods - rsa-sha2-256 and rsa-sha2-512 - as currently defined here:

You can test support for these new algorithms for both host and user authentication.

To test host authentication, set the list of host key algorithms in your KEXINIT to "rsa-sha2-256" or "rsa-sha2-512". You will need at least one of these for successful key exchange - the server doesn't offer anything else.

To test user authentication, log into the account "test" using "rsa-sha2-256" or "rsa-sha2-512" as the signature method. You will need to use the following 2048-bit RSA private key for the server to accept the public key:

-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----

denis bider <[email-masked]> , 11/8/2015 2:36 AM:
I can make available an experimental build of our SSH Server that will implement these algorithms.

denis bider <[email-masked]> , 11/8/2015 2:24 AM:
The "ecdsa-sha2-..." algorithm names (RFC 5656) do not use the "ssh-" prefix.

In my opinion, the "ssh-" prefix is superfluous. The context of SSH is implied by where the names are used.

The prefix would make sense if it were needed to disambiguate from something. However, I am not aware of any proposal for SSH to do a wholesale import of algorithm names from some other, SSH-unaware spec. Moreover, if such names were imported, then THOSE names would be prefixed with something, not the SSH native algorithm names.

I think the use of "ssh-" prefixes for all kinds of names was a (small) mistake in the original design. I think we can safely migrate away from it.

Therefore, I have specified no "ssh-" prefix for these algorithms.

Peter Gutmann <[email-masked]> , 11/8/2015 2:23 AM:

Peter.

---

From: denis bider <[email-masked]>
Date: Sun, 8 Nov 2015 03:24:21 +0000

Oh; thanks for the clarification. We never implemented SSHv1, so I haven't been exposed to that.

The public key format used by the "rsa-sha2-XXXX" signature algorithms remains "ssh-rsa", so I think that distinction will remain, to the extent it is needed.

Jeffrey Hutzelman <[email-masked]> , 11/8/2015 3:09 AM:

 
 
Right, agreed.

---

From: denis bider <[email-masked]>
Date: Sun, 8 Nov 2015 02:14:47 +0000

Changes:

- Based on feedback from Peter, now again includes rsa-sha2-256 as RECOMMENDED.
- rsa-sha2-512 is now OPTIONAL.
- The signature algorithm discovery method described in -01 is removed. Instead:

(2) I have written a new draft for a general SSH Extension Negotiation mechanism:

https://tools.ietf.org/html/draft-ssh-ext-info-00

Summary:

* Special indicator names are included in KEXINIT to indicate support for this mechanism.

I have looked at alternatives, but:
- libssh handles the KEXINIT reserved field incorrectly (ignores actual value, so key exchange fails if it's not zero)
- I'm hesitant to increase the protocol version number for a change that does not affect security, and does not touch KEXINIT, or affect key exchange
- Fields cannot be added to existing packets without negotiation, due to reasons discussed previously (implementations take a restrictive view of packet formats)

* If both parties indicate support for extension negotiation, the SERVICE_REQUEST and SERVICE_ACCEPT messages are replaced with a new message, SSH_MSG_EXT_INFO.

This is more useful than SERVICE_REQUEST, and saves at least half a round-trip because the server sends EXT_INFO immediately, and does not wait for client.

* The EXT_INFO message contains a list of name-value pairs, each identifying an extension and optional parameters.

* Three extensions are defined upfront:

server-sig-algs: Allows efficient discovery of signature algorithms supported by the server. For public key authentication, the client only needs to wait for the EXT_INFO message sent by the server. This should arrive half a round-trip sooner than SERVICE_ACCEPT. The client can then immediately send a public key authentication request with an appropriate signature method.

client-req-ok: Allows clients to affirm that the server can send a global request (especially an unrecognized global request) without risking the client disconnecting. This should be supported by all clients. It is necessary so that servers can enable active keep-alive, which is not otherwise possible generally because some clients do disconnect when they receive a global request.

no-handbrake: Peter ought to like this. :) A few years late, but this makes window size infinite for both directions in a channel, at the cost of restricting the session to one simultaneous channel. This should help file transfer applications for which the channel flow control in SSH is an impediment, rather than a feature.

If you guys like this, then - if anyone else has an extension they would like to add, now might be the time to define them!

denis

---

From: denis bider <[email-masked]>
Date: Sun, 8 Nov 2015 02:36:25 +0000

Peter.

---

From: denis bider <[email-masked]>
Date: Sun, 8 Nov 2015 02:30:18 +0000

Peter.

---

From: [email-masked] (Niels Möller)
Date: Mon, 09 Nov 2015 19:42:47 +0100

> implied by where the names are used.

The "ssh-" prefix specifies the encoding to use for keys and signatures.
My understanding is that for ecdsa- and x509v3-, the encoding is
specified by appropiate other standards. While for ssh-rsa and ssh-dss,
the encoding is ssh-specific: It is specified in the ssh transport
protocol (RFC 4253), and include strings like "ssh-rsa" as part of the
encoding.

I belive the new rsa-sha2-256 algorithm name ought to also have an
"ssh-" prefix, because the format is equally ssh specific.

> I think the use of "ssh-" prefixes for all kinds of names was a
> (small) mistake in the original design.

I disagree. And even if it were a small mistake, we should strive to
keep naming consistent.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.

---

From: [email-masked] (Niels Möller)
Date: Mon, 09 Nov 2015 20:05:42 +0100

denis bider <[email-masked]> writes:

> - libssh handles the KEXINIT reserved field incorrectly (ignores
> actual value, so key exchange fails if it's not zero)

Is this a bug or not? The reserved field is intended for extensions, but
from a quick look I can't see that the spec (RFC 4253) defines any valid
behaviour when a client or server receives a non-zero value there. I
think a complient implementation ought to disconnect.

It would make some sense to combine client's and server's value in some
way, e.g., bitwise and, or taking the maximum value, and use the result
to enable extensions. But we really have to define that mechanism first,
before we can define extensions using it... So in the short term, this
field seems pretty useless.
 
> client-req-ok: Allows clients to affirm that the server can send a
> global request (especially an unrecognized global request) without
> risking the client disconnecting. This should be supported by all
> clients. It is necessary so that servers can enable active keep-alive,
> which is not otherwise possible generally because some clients do
> disconnect when they receive a global request.

This is essentially an extension saying "I don't have known bug X". I
think we should avoid those things. If we want to interoperate with
buggy implementations, I'd actually prefer hacks based on the version
strings. Sooner or later we'll see an implementation which advertises
"no bug X" but actually has bug X, and then we're back to square one.

> no-handbrake: Peter ought to like this. :) A few years late, but this
> makes window size infinite for both directions in a channel, at the
> cost of restricting the session to one simultaneous channel. This
> should help file transfer applications for which the channel flow
> control in SSH is an impediment, rather than a feature.

Makes some sense. Is the intention that the endpoints should buffer
arbitrarily large amounts of data, or is the receiver of the data stream
allowed to block and stop processing ssh messages while delivering the
data?

I think I'd prefer to do it per-channel, and if enabled, let the parties
do their best if other channels are starved for data or get blocked. And
if it is intended to be a global state, a GLOBAL_REQUEST seems more
appropriate than an extension to the *transport* layer of the ssh
protocol.

If we want to improve on the flow control in ssh-connection, it might
also make sense to look at what other recent multiplexing protocols do,
e.g, http/2.

Regards,
/Niels

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 10 Nov 2015 06:31:15 +0000

>experiment.bitvise.com:10712

So I figured this would be the quickest RFC (draft) implementation ever, one
line of code:

  { "rsa-sha2-256", 12, CRYPT_ALGO_RSA, CRYPT_ALGO_RSA, CRYPT_ALGO_SHA2 },

However, this doesn't work, for several reasons... the biggest problem is that
the hash algorithm HASH is already specified in the keyex method, for "diffie-
hellman-group-exchange-sha1" it's SHA-1 and for "diffie-hellman-group-
exchange-sha256" it's SHA2-256.  So specifying "rsa-sha2-256" for "diffie-
hellman-group-exchange- sha1" doesn't make sense, and specifying it for
"diffie-hellman-group-exchange-sha256" is redundant.

Another problem is shown up by the argument about naming, that since this is a
standard SSH signature, the "ssh-" isn't needed.  Looking at the draft, this
isn't anything like any other SSH signature, it uses RSA-PSS not PKCS #1,
which no other SSH signature uses.  So it needs some indicator in the name
that it's a nonstandard signature type, not a standard SSH signature, e.g.
"ssh-rsa-pss" to contrast with the standard "ssh-rsa".  It also means that you
need to do an implementation of RSA-PSS just to support this signature type.

The result is that the draft is really "Use of RSA-PSS with SSH", not "Use of
RSA Keys with SHA-2 256 and 512 in Secure Shell (SSH)", since they're already
in use with SHA-2 when "diffie-hellman-group-exchange-sha256" is used.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 10 Nov 2015 06:50:31 +0000

Niels Möller <[email-masked]> writes:

>Is this a bug or not? The reserved field is intended for extensions, but from
>a quick look I can't see that the spec (RFC 4253) defines any valid behaviour
>when a client or server receives a non-zero value there. I think a complient
>implementation ought to disconnect.

I would consider it a bug in the spec, indicating that there's a reserved
field but not saying how it's meant to be handled.  My code checks for its
presence, but explicitly doesn't try and interpret it in any way.  OTOH the
following:

  execl("/usr/games/hack", "#pragma", 0); // try to run the game NetHack

would also be perfectly valid behaviour.  Or at least, you could argue that
rejecting it if it's nonzero is valid, not rejecting it if it's nonzero is
valid, and ignoring it is valid.

It's a bit of a strange field in any case, unless your entire protocol
extension is a single bitflag it's more or less useless for specifying
extensions because there's no room for anything.

>Is the intention that the endpoints should buffer arbitrarily large amounts
>of data, or is the receiver of the data stream allowed to block and stop
>processing ssh messages while delivering the data?

The latter.  Implementations would, I assume, be doing this anyway, if your
incoming data stream is faster than what you can write to disk (or whatever),
you use TCP's flow control to manage things.

(Oh, and as Denis pointed out, I'd definitely support this one :-).

Peter.

---

From: Damien Miller <[email-masked]>
Date: Tue, 10 Nov 2015 18:29:08 +1100 (AEDT)

On Tue, 10 Nov 2015, Peter Gutmann wrote:

> However, this doesn't work, for several reasons... the biggest problem
> is that the hash algorithm HASH is already specified in the keyex
> method, for "diffie- hellman-group-exchange-sha1" it's SHA-1 and for
> "diffie-hellman-group- exchange-sha256" it's SHA2-256. So specifying
> "rsa-sha2-256" for "diffie- hellman-group-exchange- sha1" doesn't make
> sense, and specifying it for "diffie-hellman-group-exchange-sha256" is
> redundant.

I don't think this is right: the hash used in the signature algorithm has
always been independent of the key exchange hash. Moreover, the key
exchange hash is only tangentially involved for publickey authentication.

> Another problem is shown up by the argument about naming, that since
> this is a standard SSH signature, the "ssh-" isn't needed. Looking
> at the draft, this isn't anything like any other SSH signature, it
> uses RSA-PSS not PKCS #1, which no other SSH signature uses. So it
> needs some indicator in the name that it's a nonstandard signature
> type, not a standard SSH signature, e.g. "ssh-rsa-pss" to contrast
> with the standard "ssh-rsa". It also means that you need to do an
> implementation of RSA-PSS just to support this signature type.
>
> The result is that the draft is really "Use of RSA-PSS with
> SSH", not "Use of RSA Keys with SHA-2 256 and 512 in Secure
> Shell (SSH)", since they're already in use with SHA-2 when
> "diffie-hellman-group-exchange-sha256" is used.

IMO it's both. I don't really care for bikeshedding names, but if
I were picking it, then it would be "rsa-pss-sha256".

-d

---

From: Damien Miller <[email-masked]>
Date: Tue, 10 Nov 2015 19:18:11 +1100 (AEDT)

Some feedback on the draft:

> 1.  Overview and Rationale

The DSA bits in here don't seem very relevant. Could I suggest ditching
them or putting them in an appendix?

>   All aspects of the "ssh-rsa" format are kept, including the encoded
>   string "ssh-rsa", in order to allow users' existing RSA keys to be
>   used with the new signature formats, without requiring re-encoding,
>   or affecting already trusted key fingerprints.

I can see the argument for keeping "ssh-rsa" as the key name and
another name for the revised signature format. I'm not entirely sure
about it, I guess because I'm used to there being an identity between
key types and signature types in the SSH protocol.

> 3.  Discovery of signature algorithms supported by servers
> 
>   When a public key format can use multiple signature algorithms, it can
>   be useful for a mechanism to exist which a client can use to discover
>   signature algorithms accepted by a server for user authentication
>   without resorting to trial and error in authentication requests.
> 
>   Such a mechanism is defined in [SSH-EXT-INFO], which describes general
>   purpose extension negotiation for SSH, and specifies discovery of
>   signature algorithms as a usage case.

IMO a "publickey2" (or somesuch) method that included a custom failure
message to list the supported key types seems like a better way to offer
this.

>     Public Key Algorithm Name      Reference          Note
>     rsa-sha2-256                   [this document]    Section 2
>     rsa-sha2-512                   [this document]    Section 2

As mentioned in my other email, I don't feel super-strongly about
naming, but "rsa-pss-sha2-*" seems slightly more descriptive and
future-proof.

Is it worthwhile to specify a minimum key size for the new signature
schemes?

-d

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 10 Nov 2015 08:53:53 +0000

Damien Miller <[email-masked]> writes:

>always been independent of the key exchange hash. 

Is it?  I hope I'm not reading this wrong, but the exchange hash H is what's
signed, and that's what's calculated using the hash algorithm HASH, which is
specified by e.g. "diffie-hellman-group-exchange-sha256".  So
"server_host_key_algorithms" can say RSA or DSA or ECDSA, but not the hash,
since that's implicit from "kex_algorithms".

>I don't really care for bikeshedding names, but if I were picking it, then it
>would be "rsa-pss-sha256".

It definitely needs to indicate quite clearly that it uses a signature form
that's not compatible with anything else that SSH has ever used.  I'd vote for
"crunchy-raw-unboned-real-dead-frog-rsa-pss".

Could I also suggest that the draft include a facility to use standard PKCS #1
sigs?  I really don't want to have to implement a nonstandard (meaning not
used by any other part of SSH, or any other protocol like PGP, S/MIME, TLS,
etc) signature format just to be able to use SHA-256 in a sig.

Peter.

---

From: "Mark D. Baushke" <[email-masked]>
Date: Tue, 10 Nov 2015 01:01:05 -0800

> Some feedback on the draft:
...elided...
> Is it worthwhile to specify a minimum key size for the new signature

Hmmm... I am not sure. I would suggest a minimum of 2048 or 3072 would
seem to fit, but that might already be covered from RFC 4251 which has:

RFC 4251 Section 4.4 Security Properties says:

"All algorithms are used with cryptographically sound key sizes
 that are believed to provide protection against even the strongest
 cryptanalytic attacks for decades."

Do we believe that 112 bits of security will (i.e., RSA 2048-bit keys)
will last for decades? If not, do we want to go for RSA 3072-bit keys
with 128 bits of security (like AES-128) and SHA2-256?

Or, should we let the developers just choose what they will and hope for
the best?

	-- Mark

---

From: Damien Miller <[email-masked]>
Date: Tue, 10 Nov 2015 20:11:31 +1100 (AEDT)

> since that's implicit from "kex_algorithms".

Yes, the kex method specifies an output hash. The output hash is reused for
key derivation too.

The signature methods *also* have implicit (or explicit in the ecdsa cases)
input hashes.

I.e. a current ssh-rsa kex signature is roughly

RSA( PKCS1_PAD( SHA1( KEX_HASH( ... ) ) ) )

Over the banner+kexinit+etc blob.

The publickey authentication hash isn't as redundant, since it doesn't
have the inner kex hash.

> >I don't really care for bikeshedding names, but if I were picking it,
> >then it would be "rsa-pss-sha256".
>
> It definitely needs to indicate quite clearly that it uses a signature
> form that's not compatible with anything else that SSH has ever used.
> I'd vote for "crunchy-raw-unboned-real-dead-frog-rsa-pss".
>
> Could I also suggest that the draft include a facility to use standard
> PKCS #1 sigs? I really don't want to have to implement a nonstandard
> (meaning not used by any other part of SSH, or any other protocol like
> PGP, S/MIME, TLS, etc) signature format just to be able to use SHA-256
> in a sig.

Please no; I was counting the absence of ASN.1 formatting in the
proposed signature scheme as a significant improvement.

-d

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 10 Nov 2015 10:14:56 +0000

>The signature methods *also* have implicit (or explicit in the ecdsa cases)

Ah, OK, I missed this bit:

   Most signature algorithms include hashing and additional padding (e.g.,
   "ssh-dss" specifies SHA-1 hashing).  In that case, the data is first hashed
   with HASH to compute H, and H is then hashed with SHA-1 as part of the
   signing operation.

So the new IDs just signal a switch of the hash from SHA-1 to SHA-256.

>Please no; I was counting the absence of ASN.1 formatting in the proposed
>signature scheme as a significant improvement.

What the formatting is isn't a big deal since it's already present in the
code.  Every version of SSH over the last 20 years has used PKCS #1.  The only
change for SHA-256 support is to add an OID to a table somewhere.  If you're
using a general crypto library, chances are it'll already support this out of
the box.

OTOH for RSA-PSS sigs you need to implement, debug, and test a completely new
signature scheme that's incompatible with pretty much everything else (PGP,
TLS, etc) out there.

Peter.

---

From: t.petch <[email-masked]>
Date: Tue, 10 Nov 2015 10:53:09 +0000

---- Original Message -----
From: "Peter Gutmann" <[email-masked]>
Sent: Tuesday, November 10, 2015 8:53 AM

>always been independent of the key exchange hash.

Is it?  I hope I'm not reading this wrong, but the exchange hash H is
what's
signed, and that's what's calculated using the hash algorithm HASH,
which is
specified by e.g. "diffie-hellman-group-exchange-sha256".  So
"server_host_key_algorithms" can say RSA or DSA or ECDSA, but not the
hash,
since that's implicit from "kex_algorithms".

>I don't really care for bikeshedding names, but if I were picking it,
then it

It definitely needs to indicate quite clearly that it uses a signature
form
that's not compatible with anything else that SSH has ever used.  I'd
vote for
"crunchy-raw-unboned-real-dead-frog-rsa-pss".

<tp>
Sounds appropriate:-)

My experience is that encoding semantics into identifiers generates long
term problems.  An identifier should be easy to use, easy to read and
write, hard to confuse with other identifiers in the name space.  Using
it to identify e.g. which version of which model of kitchen sink is used
leads to overlong and easy to get wrong identifiers which then engenders
mistakes.

Since in this case, we are naming a replacement for
ssh-rsa
it would seem sound to use
ssh-rsa-(something short and snappy to show it is an update)
e.g.
ssh-rsa-sha256

Yes, I know about
x509v3-ssh-dss
x509v3-ssh-rsa

Not sound, IMHO;
ssh-dss-x509v3
ssh-rsa-x509v3
would have been better or even
ssh-dss-x509
ssh-rsa-x509

Relevant for me, but perhaps heresy to mention here, is the fact the TLS
Cipher Suite names make extensive use of SHA256 and SHA384 as an element
thereof.

Tom Petch

Could I also suggest that the draft include a facility to use standard
PKCS #1
sigs?  I really don't want to have to implement a nonstandard (meaning
not
used by any other part of SSH, or any other protocol like PGP, S/MIME,
TLS,
etc) signature format just to be able to use SHA-256 in a sig.

Peter.

=

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 12 Nov 2015 07:49:58 +0000

Niels Möller <[email-masked]> writes:

>Send 0, ignore received value, would have made it actually useful.

Can we get any figures on what effect making it nonzero would have?  We know
that there are at least some implementations who would have problems with
this, but if they're OSS and frequently updated then it may not be such a big
issue, push out a fix fairly soon and by the time the RFC is ready most of the
problem will have fixed itself.

Another workaround, although it's a bit of a hack, is if the two major client
and server implementations, putty and OpenSSH, could retry an initial connect
with a nonzero field that's failed with a zeroed field and if it works, report
to the user that the implementation needs an update.

>Also, I'm not sure it has to be restricted to a single channel, I think it
>would make sense to disable flow control independently for a single channel
>or a single unidirectional flow.

Ah, good point.  The number of users of multichannel that I have is pretty
minimal, so I never see this (it's used almost exclusively as a secure telnet
or for firmware upgrades, neither of which need multi-channel, to the point
where it's disabled by default in the source code).

>Do we have a common understanding of how it's going to work?

Not yet, I think :-).  I'd just seen it as all-or-nothing, is there any reason
why you'd have windowing on three channels but not a fourth?  That is, is
there a need for per-channel windowing enable/disable?  Can it be enabled mid-
flow or only on channel open?

Peter.

---

From: denis bider <[email-masked]>
Date: Thu, 12 Nov 2015 08:43:21 +0000

To be clear: when you stop reading from the SSH socket because the infinite-window channel is blocked, this affects:

- key re-exchange - can't be started while infinite-window channel is blocked

- keep-alive - can't be used while infinite-window channel is blocked

This definitely affects the transport layer, and requires the awareness of the transport layer if the feature has been enabled for any channel.

That's why I think it makes sense to negotiate it on the transport layer. The transport layer must be aware of this.

denis bider <[email-masked]> , 11/12/2015 8:24 AM:
It seems to me the only known applications that might want to use "no-handbrake" are those that don't want to use multiplexing. I don't know of a different usage case.

To support a different usage case that we do not know of, we would have to specify a mechanism for enabling this on a per-channel basis. This could be a channel request sent by the client. If supported and confirmed by the server, the channel request would switch the channel to infinite-window mode.

The way I see it, though, supporting infinite windows with multiple channels just doesn't seem to make sense.

The problem is not sending data. Yeah, in that case, you send in a round-robin fashion, no problem.

The problem is receiving. What happens when you can't write to the infinite-window channel, but the data keeps coming?

In this situation, you must stop reading from the SSH socket, which affects all channels. You must stop reading because you have no way of knowing whether the next packet you receive is going to be data for the infinite-window channel.

The way I see it, the only clean usage scenario for this feature is where there's a single channel. Anything else introduces dirty dilemmas that aren't even necessary, because the only actual usage case is single-channel.

Peter Gutmann <[email-masked]> , 11/12/2015 7:50 AM:

Peter.

---

From: denis bider <[email-masked]>
Date: Thu, 12 Nov 2015 08:39:41 +0000

Peter.

---

From: [email-masked] (Niels Möller)
Date: Thu, 12 Nov 2015 06:28:07 +0100

Peter Gutmann <[email-masked]> writes:

> field but not saying how it's meant to be handled.

I think your (and Denis) is right. Send 0, ignore received value, would
have made it actually useful.

> (Oh, and as Denis pointed out, I'd definitely support this one :-).

I think the basic idea is sound, but I'm not sure enabling it belongs in
the *transport* layer. Also, I'm not sure it has to be restricted to a
single channel, I think it would make sense to disable flow control
independently for a single channel or a single unidirectional flow.

One can think of this feature as (1) disabling flow control, equivalent
to using an infinite ssh window size, and (2) disabling buffering of
received data (or limiting to a small buffer). This is my understanding
of how it would work:

If you are sending data on any channel without flow control, then you have
to pause reading from all data sources when writing to the ssh
connection blocks. And when it's possible to write on the ssh socket,
you can read in a round-robin fashion from all data sources for which
you either have available window space, or for which flow-control is
disabled.

If you are receiving data on any channel without flow control, you have
to pause reading from the ssh socket while delivering received data to
its data sink.

Some other thoughts:

Can it be made work with "connection sharing"/"gateway mode"? There are
similar flow-control isues there already, at least in my implementation.

Is it possible to do something similar by advertising a large window
size, but keep a smaller receive buffer? And then blocking the ssh
connection (preferably with some short timeout) as needed to deliver the
data? One alternative might be a channel request saying "please give me
a very large 100 MB windows size, but you don't need to buffer it all,
instead, please just close this channel if data delivery blocks for 10s."

Regards,
/Niels

---

From: [email-masked] (Niels Möller)
Date: Fri, 13 Nov 2015 07:21:37 +0100

denis bider <[email-masked]> writes:

> It seems to me the only known applications that might want to use
> "no-handbrake" are those that don't want to use multiplexing. I don't
> know of a different usage case.

One usecase: Make make s single general-purpose connection from my
workstation to my server, using it for one or more shell sessions, port
worfwarding, etc. I use "connection sharing", i.e., a local private unix
socket that can be used to create additional channels over the same
connection.

Then I decide to do a large file transfer, so I create a new channel
just for that purpose, and I really want it to finish as soon as
possible.

Now, this is a problem in my implementation which I haven't yet bothered
to solve, because it uses a fix and pretty small window size, and
typically I won't get close to full network utilization. So I don't know
if it's good enough to just set a much larger window size (but if it
doesn' I think that ought to solve all "no-handbrake" usecases).

> In this situation, you must stop reading from the SSH socket, which
> affects all channels.

Agreed. And we should note that the "no-handbrake" will not work well if
the bottleneck of the data flow actually is after ssh, so users need to
enable it with care. One option might be to timeout after a few seconds
and close the connection; then we kill the affected channel, without
hanging the connection indefinitely.

> The way I see it, the only clean usage scenario for this feature is
> where there's a single channel.

Also in this case, if you get overwelmed with data, you have to stop
reading the ssh socket, and hence making timely key reexchange
impossible.

> That's why I think it makes sense to negotiate it on the transport
> layer. The transport layer must be aware of this.

Maybe. but I'd prefer a solution to both the single-channel use-case and
the usecase above. I think we need to take a step back and sort out what
the use cases are. I've been thinking that the poor utilization I've
seen is simply a sign of poorly chosen window sizes in my
implementation. If it's a more general problem, we need to understand
what the usecases and failure modes are.

A different solution which I've been considering is a channel mechanism
to automatically increase the window size when the ssh flow control is
the bottleneck. It could be as easy as checking on reception of
SSH_MSG_DATA if the receive window goes down to 0, and if so increase
the size of the receive buffer and send a WINDOW_ADJUST which reflects
not delivery of data, but the increased buffer.

Regards,
/Niels

---

From: [email-masked] (Niels Möller)
Date: Fri, 13 Nov 2015 09:37:03 +0100

Peter Gutmann <[email-masked]> writes:

> Can we get any figures on what effect making it nonzero would have?

I think my implementation will disconnect.

Anyway, if we do a general smallish update, it would make sense to fix
this (not sure in which form, note in the algorithms update rfc, or an
errate on hte old rfc). And simply say that until any of the future
extensions are specified, implementations should accept and ignore
non-zero values for this field.

That will make our lives a little easier a few years from now.

Regards,
/Niels