Terrapin

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

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'm wondering if people can point out
flaws in them that I've missed.

The first one relies on their observation that their prefix truncation
attack depends on being able to delete the first N messages post-kex
(N=1 for most of their practical uses).  This requires knowing the
total length of those N messages.  The countermeasure: always send one
or more IGNOREs, with random payload sizes, as the first packet(s)
after kex.  To avoid leaking the length via side-channels such as TCP
segment sizes, push part - or even none - of this data to the TCP layer
immediately, deferring the rest until there is something more to send.
(While writing this mail, it occurs to me that it might be more
effective to send numerous small IGNOREs instead of one large IGNORE.)
This is moderately weak, especially since the effective packet size is
rounded up to an encryption block size, thus reducing the number of
possible lengths available, but every additional bar to be cleared,
even one as low as one-in-32 or one-in-8192, reduces the overall attack
success rate.

My second thought: always make the first message after kex a verifier
message, with content depending predictably on kex output, as a final
test of the integrity of the encrypted channel.  (I am tempted to say
"all-zero content" or some such, but that makes too good a crib for
attacking the bulk crypto.)

The first one can be done with full backward compatibility.

The second one requires a protocol change, to mandate that message's
presence, but in that respect it's no different from their sequence
number reset or full transcript hash countermeasures.

/~\ 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