Re: Terrapin

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> I just read the Terrapin vulerability paper, [...]

>> 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.

I'd say, instead, "is not appropriate for its intended use".

> 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.

Well, I'd say the _real_ issue is a design bug.  It can be worked
around by the crypto ignoring the value the protocol provides, but that
doesn't mean that there's no problem with the protocol.

> 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, [...]

That would be a usable workaround, yes.

I would actually prefer a protocol revision, though, to _fix_ the
issues instead of just working around them.  If the sequence number is
not usable for its intended use, then, unless someone has a use it _is_
usable for, it should be fixed or eliminated.  (And there *are* other
issues, such as the way it's possible to have pre-kex traffic that kex
doesn't sign over.)

> That's why I do not fully agree when the authors conclude that the
> "SSH protocol would benefit from a redesign from scratch"

I'm not sure I'd go with "from scratch".  It does need some changes,
but much of it still appears to be sound.

> [...].  Yet this is actually debatable because their approach is only
> useful when the client and the server both implement the
> countermeasure.

So is yours, to be fair.  The only countermeasures I've seen that have
any benefit when implemented unilaterally are (a) the one I suggested,
adding IGNOREs after NEWKEYS so as to make it difficult for the
attacker to delete the right number of bytes, and (b) disabling support
for some crypto.

Unfortunately (a) (1) still requires some of (b) (disabling EtM MACs)
and (2) is also a relatively weak countermeasure.

IIRC, EtM MACs went in to eliminate use of the timing of error replies
as a crypto oracle.  That is a weaker attack than this one, though, and
furthermore it can be defeated - unilaterally - by the implementation
replacing any unacceptable packet length with a random acceptable
packet length.  Is there any other need for EtM?

> 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?

I think it's a very good observation of yours, that it's possible to
work around the issue by respecifying the crypto.  I still consider it
a workaround, though, as I said above.

It does have the major advantage that, even though it brings practical
benefits only when implemented on both ends, it can be deployed
incrementally without breaking interoperability.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B