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

[Eric Rescorla <[e-mail]>]

On Sat, Apr 8, 2017 at 3:40 AM, denis bider <[e-mail]>
wrote:

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

That's more-or-less correct. You don't actually use the PSK but derive a
separate key from the PSK. The security challenges mostly derive from the
fact that the
server doesn't have an opportunity to provide a nonce.




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

I'm not familiar enough with SSH to have an opinion here.

-Ekr


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