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

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> 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?

You could simply decree that options packets for the option in question
are not acceptable if sent before the first kex completes.  (I'd
hesitate to do that for all options packets, but it may be necessary.)

> 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.

Too late for what?  You need to be careful to send nothing important
until after MitM detection, but if you are then what's the risk?

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B