Discussion: new terrapin resisting ciphers and macs (alternative to strict-kex) and -ctr mode question.

[Bernd Eckenfels]

Fabian Bäumer wrote on 20. Dec 2023 13:48 (GMT +01:00):

> So I wonder what would be the benefit 
> of having those over strict key exchange? 

There are two benefits, first of all I can only enable the secure versions but not require strict kex.

This way I can still connect with old clients with save ciphers or Macs
(because the unsafe are only with their new names enabled) and with
peers which support the new ciphers I not only can use the more
modern etm or non-NIST Chacha20 but also those constructs use a
more sound composition - that was exactly the critic of your paper
on the ssh protocol.

> As far as 
> we are aware, there is no way for an attacker to realign the keystream 
> to allow the session to continue. Note however, that the attack still 
> passes MAC verification and that an exception is only thrown at the 
> application layer (i.e. wrong message format of SSH_SERVICE_REQUEST / 
> _ACCEPT).

Ok, That was my understanding, it is further area of research and that’s why you
would be on the safe side to disable ETM (while risking to use EAM again).

Internally I will implement strict-kex-required if it is available, but we are working in
a space where partners notoriously not keep their software current, That’s why I can’t
use strict-kex-required for those services (with thousands of partners) - or only on 
a new dedicated port where I need to have my partners migrate to.
In this scenario the new v2 cipher (and to a lesser extend mode since there is still GCM)
would still restore the protection niveau for those partners who are current with their clients.

After all, aes-cbc is disabled, aes-gcm not yet supported by everybody, so only* aes-ctr is left
so for algorithm diversity, it would be really good if a different base cipher (cc20 variant) can
be re-enabled without locking out older clients.

* this is for a non-OpenSSH impl.

Gruß
Bernd
— 
https://bernd.eckenfels.net