On Thu, 9 Apr 2009, Peter Gutmann wrote:
What I mean here is that let's say there's some attack on step N of the
protocol, either the protocol itself or the complexity of the
implementation of certain steps. So you send an SSH_MSG_OPTION telling
the peer to switch to a limited-attack-surface version of the handshake,
with the exchange being:
Step 1: KEYEX
Step 2: OPTION
...
Step N: Vulnerable part
...
Step M: Detection of manipulation by MITM
Since a MITM can remove the OPTION message, they leave you vulnerable
at step N because you can't detect the modification until step M.
A post-KEX OPTION packet could work* and I don't think it could be
trivially elided by an on-path attacker - the MAC takes in the sequence
number, which would be off unless the attacker had some way of replacing
the packet (implying a total protocol break) and it would also
desynchronise any cipher state.
* except that it won't - OpenSSH just had to switch off a few channel and
global extensions for all but other OpenSSH peers because some other
implementations will disconnect as soon as they see an extension message
that they do not recognise. So we really are quite constrained in how we
can practically extend the protocol.