Re: [TLS] SSH channel handbrake (Re: Multi-Threaded Applications over TLS)

[Peter Gutmann <[e-mail]>]

Nicolas Williams <[e-mail]> writes:

>I don't believe that handbrake exists other than as an implementation
>artifact.

I agree, it's purely an implementation artefact.  On the other hand security
bugs in software don't exist other than as implemetation artefacts either, but
they're not going to go away if you ignore them.  The problem in this case
it's that it's a design for which the straightforward implementation (and even
many not-so-straightforward ones) produce very bad performance, and you need a
very carefully designed and coded implementation, and preferably the same one
at both ends of the link, to avoid problems.

>It's perfectly reasonable to have large channel windows, and even to grow the
>channel windows so as to avoid having to ever wait for an ACK.

No, that doens't work either, because my implementation does it and other 
implementations break in various unuusal ways once the window gets too large 
(there's a particular error message from OpenSSH which I can't recall at the 
moment that you can google for to see that other implementations run into the 
same problem).  More implementation artefacts there.

>The HPN OpenSSH patches don't make the window that dynamic, IIRC, but they do
>make it dynamic and get better performance, thus proving the point.

OTOH simply setting a huge-size window (assuming you don't run into one of the
implementations that exhibit artefacts :-) has the same effect.

The real problem though is that this is a fundamentally unsound design.  If
you put in a considerable amount of time and effort and whatever's at the
other end has done the same and if you're lucky enough, it won't be so bad,
but the default leads to quite poor performance.  From the SSH experience,
most implementations are going down the default path...

Peter.