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.