Re: [Curdle] Comments on draft-ietf-curdle-ssh-ext-info

[Peter Gutmann <[e-mail]>]

denis bider (Bitvise) <[e-mail]> writes:

>Can you point out some of these subtle problems that could occur in this
>regard in SSH?

I was thinking of the problem that it's essentially impossible to safely do n-
RTT, n < 1, for TLS, which meant that doing the same thing for SSH wasn't
going to be any better.  I was reasoning by analogy from TLS rather than
sitting down and drawing diagrams for SSH to try and figure out all the
possible issues.

>Under the assumption that such an extension were defined, can you point out
>at least one way that sending this info right after NEWKEYS can help an
>attacker?

It depends on the extension.  Without one defined, there's no way to tell at
the moment.  I could invent something that works out badly, but that'd be
creating a strawman... my concern is that in the future someone may define a
problematic extension without realising that they're creating a problem.
Perhaps adding an implementation note to say that at this point the crypto
hasn't been confirmed yet and so you may want to be careful about what you put
into your extension data would be useful?

>But the extension value field is generically a string (it must be same type
>for all extensions, so unsupported extensions can be decoded and ignored).
>"p" and "s" are therefore fitting ways to express this boolean.

Wouldn't "true" and "false" be a better way to express a boolean?  I realise
this is kinda bikeshedding, but having to look up the spec just to figure out
what mysterious magic values in a boolean field specify seems a bit awkward.

>Properly implemented flow control is superior. However, this extension is a
>nod to that not everyone will be using an SSH library that does this right,
>and "no-flow-control" is a better option if your needs are simple, and you
>don't have a few years to get this right.

Given that there are a nonzero number of implementations that send a window
size of ~0 to indicate no flow control, it may be useful to add an
implementation note to point this out.  I enabled some diagnostic code to
throw an exception in my code if it found this from another implementation
(other than mine) and got, uh, feedback from beta-testers about it, so at
least some implementations are using a pseudo-infinite window size to indicate
no flow control.  I'm not saying it should be adopted as an alternative to
"no-flow-control", but merely to alert implementers about the practice, e.g. a
certain big iron vendor whose device would crash and reboot as it tried to
allocate ~0 bytes of memory to match the widow size.

Peter.