Connection hangs after delivery of 256GB of data

[AlexPeshkoff]

ChaCha wire encryption, used by default since FB4, is using 32-bit counter. When counter overflows secure packets delivery becomes impossible without reconnect.

[AlexPeshkoff]

Added configuration parameter CounterSize (in ChaCha.conf). Setting it to 64 makes it use 64-bit counter which is able to exchange with very big volume of data, practically unlimited.

Using this setting makes firebird server incompatible with 4.0.0 client

[mrotteveel]

This is not an appropriate fix. The client has no way to know to know the counter size the server expects. In addition, this is no longer ChaCha20 as defined in RFC-7539, which makes it harder to support. If a bigger counter is needed, then a new variant of ChaCha needs to be added with a separate name, to distinguish it from the standard 32-bit counter variant.

[AlexPeshkoff]

The client has a way to know the counter size the server expects. IV (nonce) is sent to client, and depending on it's size client does know what counter size should be used.

What about use of .conf for choosing chacha variant: we are not the only one who met this problem, see for example https://libsodium.gitbook.io/doc/advanced/stream_ciphers/chacha20. Pay attention - "The original ChaCha20 cipher with a 64-bit nonce". I.e. it has all reasons to be called 'ChaCha'.

And I disagree with you about "harder to support" - having single plugin with reasonable parameter much simpler to support compared with duplicated copies of same code.

[mrotteveel]

On 2021-12-13 09:53, Alexander Peshkov wrote: The client has a way to know the counter size the server expects. IV (nonce) is sent to client, and depending on it's size client does know what counter size should be used. What about use of .conf for choosing chacha variant: we are not the only one who met this problem, see for example https://libsodium.gitbook.io/doc/advanced/stream_ciphers/chacha20. Pay attention - And I disagree with you about "harder to support" - having single plugin with reasonable parameter much simpler to support compared with duplicated copies of same code.

It is harder to support, because for example Java only supports the standardized ChaCha20 with 32-bit counter. And given a client can't know in advance whether or not the server is configured with a 64-bit counter, Jaybird could incorrectly try to offer ChaCha, but then can't use it because the server wants to use a 64-bit counter which I don't actually support, and I either have to use the less secure ARC4, or maybe even forgo encryption entirely, which then means that - depending on the server config - Jaybird cannot connect at all. Having a separate plugin **name** (which IMO doesn't necessarily implies entirely separate plugin **code**), allows the server to prioritize ChaCha with 64 bit counter, while a client that only supports the standard ChaCha20 (with 32-bit counter) will still able to establish a connection using that plugin. Standard ChaCha20 (with 32-bit counter) as defined in RFC-7539[1] is a different encryption than ChaCha with 64-bit counter, and thus needs to be named separately. [1]: https://datatracker.ietf.org/doc/html/rfc7539#section-2.4

[AlexPeshkoff]

Java only supports ... ChaCha20 with 32-bit counter

That's what you could say at once instead of loosing so many words... Will rework - never new that original for one people variant is not supported by others :-)

[aafemt]

May I suggest to leave ChaCha as is and just move it deeper in configuration so rc4 is used by default with added warning that ChaCha while is "more secure" cannot be used for long lasting connections?

[asfernandes]

Then ChaCha must be deprecated. I see no point in have this limitation.

[AlexPeshkoff]

@asfernandes - chacha with 32-bit counter is IETF recommended solution and looks like the only one supported by java.
I know that RC4 is quite enough for us (with our use of secure key it has no security problems), but I can't explain it to some users. I.e. chacha is 'must be' to avoid loosing such users. What's cool is that now (with Mark's suggestion implemented) our default configuration has no 256Gb limitation.

@mrotteveel I've checked current default configuration for compatibility with FB4.0.0 client but additional check with jaybird is also welcome.

[mrotteveel]

On 2021-12-13 12:18, Adriano dos Santos Fernandes wrote: Then ChaCha must be deprecated. I see no point in have this limitation.

The counter limitation could also be "solved" by extending the protocol to allow the wire protocol encryption to be re-keyed (either by changing key + nonce, or maybe just changing nonce), but this brings additional challenges and complexity. Mark