Mailing List Archive

Hello,


in addition to my last thread about a new config option to make strict-kex mandatory,
I also wonder if a new mechanism for ciphers/macs can be introduced and is reliable
by simple both sides using it.

So there could be a Chacha20-Poly1305v2@openssh.com which uses AD data to chain the
messages together, so it will be resistant against terrapin even without the strict-kex.

Consequently the hmac-etmv2@openssh.com mode could be deviced in a similar manner, to
also include the transcript hash or similar things.

The impact of removing the only "alternative" cipher cc20p1305 because of terrapin hardening as well
as falling back to the old eam-macs is really bad for ssh best practice. And while "enforce strict-key"
could gain some of the trust back, the attack also shows, that those constructs are just very fragile.

And while a redesign of the protocol might be a good option, its not the fastest to standardize and implement.
Whereas openssh project has done it before both new ciphers.

On that note - maybe combine it with PQ hybrid modes?

I have a related question:

Has anybody analyzed the aes-ctr / hmac-etm properties, whats making this resist and is it rigid?
It looks like it is only the counter position which saves it?

So is keeping hmac-etm iff aes-ctr is offered used still a safe option (or just "not broken"). Because luckily many
have removed CBC already.

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Hi there,

> So there could be a Chacha20-Poly1305v2@openssh.com which uses AD data to chain the
> messages together, so it will be resistant against terrapin even without the strict-kex.
>
> Consequently the hmac-etmv2@openssh.com mode could be deviced in a similar manner, to
> also include the transcript hash or similar things.
This would still require both, client and server, to receive an update
to support these new algorithms. So I wonder what would be the benefit
of having those over strict key exchange? Also, existing security proofs
for ChaCha20-Poly1305 and Encrypt-then-MAC constructions in SSH would
become meaningless then.

> Has anybody analyzed the aes-ctr / hmac-etm properties, whats making this resist and is it rigid?
> It looks like it is only the counter position which saves it?
Yes, we did. We describe this mode as "vulnerable, but not exploitable"
in our paper. Terrapin works against the general Encrypt-then-MAC
construction, although some cipher specifics may prevent exploitation in
a real world scenario. In this case, dropping a message from the secure
channel causes the AES-CTR keystream to become out of sync (similar
issue with stream ciphers like arcfour, just for reference). 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).

> So is keeping hmac-etm iff aes-ctr is offered used still a safe option (or just "not broken"). Because luckily many
> have removed CBC already.
From our current point of view, this combination can be used without
risking any real world attack. However, this may change if someone finds
a way to realign the keystreams. We suggest disabling Encrypt-then-MAC
over CBC as a workaround to be on the safe side here. I'd also like to
stress that this workaround is only meant as temporary stop-gap measure
until patches are available.

> And while "enforce strict-key"
> could gain some of the trust back, the attack also shows, that those constructs are just very fragile.
For reference, there has been a similar request over on Ars Technica.

M. Sc. Fabian Bäumer

Chair for Network and Data Security
Ruhr University Bochum
Universitätsstr. 150, Building MC 4/145
44780 Bochum
Germany

Am 20.12.2023 um 11:57 schrieb Bernd Eckenfels:
> Hello,
>
>
> in addition to my last thread about a new config option to make strict-kex mandatory,
> I also wonder if a new mechanism for ciphers/macs can be introduced and is reliable
> by simple both sides using it.
>
> So there could be a Chacha20-Poly1305v2@openssh.com which uses AD data to chain the
> messages together, so it will be resistant against terrapin even without the strict-kex.
>
> Consequently the hmac-etmv2@openssh.com mode could be deviced in a similar manner, to
> also include the transcript hash or similar things.
>
> The impact of removing the only "alternative" cipher cc20p1305 because of terrapin hardening as well
> as falling back to the old eam-macs is really bad for ssh best practice. And while "enforce strict-key"
> could gain some of the trust back, the attack also shows, that those constructs are just very fragile.
>
> And while a redesign of the protocol might be a good option, its not the fastest to standardize and implement.
> Whereas openssh project has done it before both new ciphers.
>
> On that note - maybe combine it with PQ hybrid modes?
>
> I have a related question:
>
> Has anybody analyzed the aes-ctr / hmac-etm properties, whats making this resist and is it rigid?
> It looks like it is only the counter position which saves it?
>
> So is keeping hmac-etm iff aes-ctr is offered used still a safe option (or just "not broken"). Because luckily many
> have removed CBC already.
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

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