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

[denis bider <[e-mail]>]

Thank you for providing this link, Eric.

What this TLS section terms Zero-RTT, and what Peter appears to imply is
0RTT, seem to be completely different things.

In TLS, "0RTT" data appears to be data that are sent upfront in the
client's first packet to the server, encrypted using a pre-shared key
before the handshake has derived a traffic secret.

In SSH, there is no such concept at all. This would be equivalent to
sending data encrypted with some type of pre-shared key as part of the
client's KEXINIT, which is not what is happening here.

The EXT_INFO packet sent by the client after NEWKEYS is not Zero-RTT. It is
data sent after a full and completed key exchange.



On Fri, Apr 7, 2017 at 9:21 AM, Eric Rescorla <[e-mail]> wrote:

>
>
> On Thu, Apr 6, 2017 at 10:32 PM, denis bider <[e-mail]>
> 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 <[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
>>>
>>
>>
>> _______________________________________________
>> Curdle mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/curdle
>>
>>
>