Re: Terrapin

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

> 1. We need to get a clear statement of just how big a deal this
>    really is, not in theory, but in practice.  AFAICT it's more
>    checkered-trouser-time than brown-trowser-time.

Well, there are known workarounds.  That helps.

> 2. The problem isn't in the SSH protocol but in a third-party add-on
>    to it, which means the simple fix is just "don't do that, then",

Eh, I disagree.

Prefix truncation is a weakness in the BPP as it is currently defined.
Whether that weakness is exploitable now or not, it really should be
fixed.  (It currently appears to be exploitable in some, but only some,
circumstances.)

So there are two problems here.  The first is that there is a crypto
weakness in the early phases of the BPP; the second is that EXT_INFO
renders the first one relatively easy to exploit.  I don't think it's
fair to call either one a third-party add-on.

EtM crypto, which is much more of a third-party thing, makes prefix
truncation significantly easier to carry out, but all that does is
convert the (already far too high) success probability into 100%.

And, all that aside, while it may not be exploitable at present without
EXT_INFO, I really do think it is an extremely bad idea for BPP's
security to depend on details of what is layered atop it.

> 3. The long-term fix is to create an IETF-standardised EtM mechanism
>    to replace the third-party one.

Again, I disagree.  Anything that leads to sending packet lengths in
the clear will make prefix truncation trivially easy.

So any such mechanism will be a lose _unless_ it is coupled with fixing
the other issues: the lack of sequence number reset (or sequence number
verification - it would work as well for the first packet after NEWKEYS
to be a verifier that carries each side's idea of the current sequence
number, protected by the negotiated crypto).

>    For this I'd say it should hash the full handshake transcript not
>    just the current practice

That could help significantly, though it would have to be done right.
If the modified protocol has the potential for traffic to occur between
the last point the hash covers and the NEWKEYS, that possible traffic
needs very close attention; if not, correct handling (probably meaning
"rejection") of any such attempted traffic needs to be emphasized as
critical to security.

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