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

[Damien Miller <djm%mindrot.org@localhost>]

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.

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

Represent binary packet protocol changes though new cipher names.

-d