Re: applying AES-GCM to secure shell: proposed "tweak"

[Peter Gutmann <pgut001%cs.auckland.ac.nz@localhost>]

Damien Miller <djm%mindrot.org@localhost> writes:

>I think any option that changes the binary packet format would need to be
>included in the kex hash to prevent downgrade/upgrade attacks. This is
>somewhat annoying implementation-wise if it is a separate packet.

Is there any way of doing some sort of pre-auth to prevent tampering with the
options packets?  A problem with the rather late handling of MITM detection is
that if you negotiate more secure options via SSH_MSG_OPTION and a MITM
subjects you to a downgrade attack then by the time you've detected the MITM
it's too late.

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.

I can think of a pile of Rube Goldberg hacks for this, but I'm wondering if
there's a clean way to handle it.

Peter.