Re: Terrapin

Peter Gutmann <[email protected]> Thu, 21 Dec 2023 22:19:49 +0000
Newsgroups gmane.ietf.secsh
Message-ID <SY4PR01MB6251573C7CD4D8B2BFC88112EE95A@SY4PR01MB6251.ausprd01.prod.outlook.com>
Before people get too caught up in kludging the SSH protocol and potentiall=
y=0Abreaking lots of implementations to try and get around this problem (if=
 there=0Ais one), some thoughts...=0A=0A1. We need to get a clear statement=
 of just how big a deal this really is, not=0A   in theory, but in practice=
.  AFAICT it's more checkered-trouser-time than=0A   brown-trowser-time.=0A=
=0A2. The problem isn't in the SSH protocol but in a third-party add-on to =
it,=0A   which means the simple fix is just "don't do that, then", not klud=
ging all=0A   sorts of stuff onto the existing SSH protocol.  If you don't =
do that,=0A   there's no need to kludge anything.=0A=0A3. The long-term fix=
 is to create an IETF-standardised EtM mechanism to=0A   replace the third-=
party one.  For this I'd say it should hash the full=0A   handshake transcr=
ipt not just the current practice of picking out little=0A   bits and piece=
s and only hashing those, which is practically begging for an=0A   attack (=
it's putting up a big "please attack here" sign on all the bits=0A   that d=
on't get hashed), and changing the metadata processing so the current=0A   =
attack is no longer possible.  Oh, and it should be reviewed by SAAG or=0A =
  CFRG or BYOG or whoever feels responsible for this sort of thing to look =
at=0A   it before being pushed into production.=0A=0APeter.