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

[denis bider <[e-mail]>]

> 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.

OK, but I'm not familiar with the security implications of this on TLS.

Can you link to any resources where this was discussed? Whether for TLS, or
in any other context?


> 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?

 I agree, if this is a threat, we should add a warning in Security
Considerations. But to make that warning, I have to understand the threat.

If someone asks me about this warning, I want to be able to explain the
reason in detail. At this point, what I can say is, "Peter said this on the
list." That is, to me, insufficient backing.


> Wouldn't "true" and "false" be a better way to express a
> boolean?

Yes if you could choose the type. But you can't choose the type, because
all extensions have to use the same type. That type is a string.


> 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.

Booleans are equally mysterious.

The third parameter to the Windows API function WaitForMultipleObjects is a
boolean. Suppose an application passes "TRUE". Without checking the docs -
what does that mean?

If you check the docs, you know what "TRUE" in that context means. And if
you check the spec here, you know what "p" and "s" mean.

Booleans are not inherently self-documenting. (In fact - when used in
languages with positional parameters, they are more frequently
self-obfuscating.)


> 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.

OK. I added the following sub-section to my current working copy:


3.3.1.  Implementation Note: Prior "No Flow Control" Practice

  Before this extension, some applications would simply not implement
  SSH flow control, sending an initial channel window size of 2^32 - 1.
  Applications SHOULD NOT do this for the following reasons:

  - It is entirely within the realm of possibility to transfer more than
    2^32 bytes over a channel. The channel will then hang if the other
    party implements SSH flow control according to [RFC4254].

  - There exist implementations which cannot handle such large channel
    window sizes, and will exhibit non-graceful behaviors, including
    disconnection.


denis



On Thu, Apr 6, 2017 at 6:04 AM, Peter Gutmann <[e-mail]>
wrote:

> 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.
> _______________________________________________
> Curdle mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/curdle
>