Re: Terrapin

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

>>> [...EtM...]
>> Anything that leads to sending packet lengths in the clear will make
>> prefix truncation trivially easy.
> I certainly agree that it would be nice not to send packet lengths in
> the clear.  [...]

As I understand it (which even more than usual may be wrong!), this
happened largely in respose to the SandP attack, which used peer
behaviour in response to invalid packet lengths as an oracle for
attacking the crypto; combined with certain crypto modes, it leads to a
plaintext-revealing attack.  It can however be stopped by either
replacing invalid packet lengths with random valid packet lengths, or
by not using the relevant crypto modes (any stream cipher, including
block ciphers used in counter mode, is immune).

> For my money, the big problem with the Terrapin-vulnerable modes is
> that they reinitialise the cipher and/or MAC per packet, based only
> on the sequence number.

Thank you.  I think that's a very incisive remark.  I certainly hadn't
noticed it.

> I think that a redesign of the BPP ought to ensure it explicitly ties
> the packets together into an unbreakable stream.

Indeed.  In the meantime, this could be done in the crypto algorithm
layer, by defining a new MAC type that includes not just the sequence
number and packet data but also the previous packet's MAC in the data
being signed over.  (If I understand you correctly, this is close to
one of the alternatives you give, just doing it in the crypto algorithm
layer rather than the BPP proper.)

> This also ensures that the first encrypted packet sent in each
> direction can be used to verify the integrity of all the cleartext
> data beforehand.

Well, not really for the MAC version such as I sketched above, because
the MAC is `none' during the initial exchange.  It would stop prefix
truncation, because the MAC on the original second packet would include
the MAC for the deleted packet, so the other end will (with, as the
Terrapin paper puts it, "overwhelming probaility") error on that MAC.

> Then there's no need for the strict-kex bodge of _forbidding_
> extraneous things like SSH_MSG_IGNORE during key exchange; instead,
> you permit them, but expect that once crypto is established, the
> verified peer confirms that it really did send them.

Agreed.

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