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

On Thu, Apr 6, 2017 at 10:32 PM, denis bider <denisbider.ietf@gmail.com>
wrote:

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

Here is the section of TLS 1.3 that describes the security implications of
0-RTT data:

https://tlswg.github.io/tls13-spec/#zero-rtt-data

FWIW, it's less clear to me that these apply to SSH because at least the
replay issues stem from the desire to have loosely coupled distributed
servers and seamless fall back from server state or synchronization failure.

-Ekr

>
> > 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 <pgut001@cs.auckland.ac.nz>
> wrote:
>
>> denis bider (Bitvise) <ietf-ssh3@denisbider.com> 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
>> Curdle@ietf.org
>> https://www.ietf.org/mailman/listinfo/curdle
>>
>
>
> _______________________________________________
> Curdle mailing list
> Curdle@ietf.org
> https://www.ietf.org/mailman/listinfo/curdle
>
>