Re: Terrapin

Mouse <[email protected]> writes:

> I'd recommend it; it's not all that long (16 pages, of which two are
> references and one is an appendix).=20

I'll try to get time do to that reasonably soon.

> For this particular point, see
> section 5 of the paper; it begins (manually patched up for email)
>
> 	While the fact that BPP does not implement a secure channel is
> 	troublesome enough, exploiting this vulnerability requires an
> 	analysis of the SSH protocol at the application layer.=20
[...]
> 	Historically, the first messages exchanged are
> 	SERVICE_REQUEST and SERVICE_ACCEPT.  Removing either causes the
> 	connection to go stale, as the client will not begin the user
> 	authentication protocol.  Then our attack, while
> 	cryptographically successful, fails at the application layer.

Technically, SERVICE_REQUEST and SERVICE_ACCEPT are *not* application
layer, they're clearly transport layer (defined in the transport layer
RFC, and with numbers in the transport layer "generic" range)... But I
find no hint in RFC 4253 that they may have cryptographic significance.

I'm not that familiar with EXT_INFO (never had a reason to implement it),
is there a good reason for the practice of squeezing those messages in
between NEWKEYS and the SERVICE messages? If everyone just stopped doing
that, that would go a long way to disabling this attack, it seems?

Regards,
/Niels

--=20
Niels M=C3=B6ller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.