[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openssh-unix-dev
Subject:    Re: Discussion: new terrapin resisting ciphers and macs (alternative to strict-kex) and -ctr mode qu
From:       "Bernd Eckenfels" <ecki () zusammenkunft ! net>
Date:       2023-12-20 13:32:59
Message-ID: 20231220133259.7C57D6602CF () dd33810 ! kasserver ! com
[Download RAW message or body]

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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

[prev in list] [next in list] [prev in thread] [next in thread]