Re: Terrapin

[Alexandre Becoulet <alexandre.becoulet%free.fr@localhost>]

Hello,

> I just read the Terrapin vulerability paper, as fetched from
> https://terrapin-attack.com/TerrapinAttack.pdf.
> 
> Their section 8 suggests two countermeasures.  Two other possible
> countermeasures occur to me;

I'am under the impression than one way to think of it would be that we
are facing an algorithm issue rather than a protocol issue. Then the
current protocol design would be safe.

There is this packet sequence number that is provided by the
protocol. The authors of the paper show that the way this sequence
number is computed is not appropriate for use by some algorithms. They
also show that algorithms like AES-GCM are immune because they simply
do not rely on it. This means that the real issue is related to some
algorithms that should not rely on this value. This is a good news
because, as we all know, the ssh protocol is designed so that
algorithms are not hardwired and can be replaced.

From what I understand reading the spec and implementations, the
sequence number is only used in the current MAC algorithms and also in
the chacha20-poly1305 cipher algorithm.

According to the paper, the situation is like this: All EtM MAC
algorithms are vulnerable. Original non-EtM (referred to as EaM in the
paper) are fine, provided that they are used in along with CBC and CTR
ciphers, for specific reasons. Because non-EtM MAC could actually be
used with any other cipher, we should probably consider them
problematic as well.

A way to fix this without breaking and bloating the protocol would be
to introduce variants of the problematic MAC and AEAD cipher
algorithms that would use their own sequence number, as already done
in AES-GCM. For instance, we could have "hmac-sha2-256-seq0" and
"chacha20-poly1305-seq0" algorithms that use a separate sequence
number that is set to zero when the algorithm is initialized.

Then the algorithm negociation mechanism will do its job and the
implementers and users will still be able to choose the degree of
safety and compatibility they want by tuning the list of algorithms,
as usual. That's why I do not fully agree when the authors conclude
that the "SSH protocol would benefit from a redesign from scratch"
when it is actually so well designed that the issue can be
circumvented cleanly thanks to an algorithm negociation mechanism that
has been designed on purpose.

> I'm wondering if people can point out
> flaws in them that I've missed.

The authors propose to introduce a mechanism similar to or relying on
ext-info to fix the issue. At first, I thought that this could be a
nice short term fix. It would bloat the protocol, but we could
deprecate and remove it later when the new algorithm variants
discussed above will be widespread. Yet this is actually debatable
because their approach is only useful when the client and the server
both implement the countermeasure. Up to date implementations would
also come with the proposed "*-seq0" algorithms anyway. Because
there is no improvement when a single peer implement the
countermeasure, I do not see the benefit of this non rfc conform
approach that tries to fix the protocol when we could just fix some
algorithms.

What do you think?

Regards,

-- 
Alexandre
https://www.nongnu.org/libassh/