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

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

>>>> IF a non-AEAD cipher is chosen AND there was no common MAC AND
>>>> there was a common AEAD cipher THEN re-compute the cipher
>>>> selection ignoring all non-AEAD ciphers.
>> This rule interacts very badly with the implementation of any other
>> encryption algorithm that similarly wants to ignore MACs, especially
>> if it defines an analogous rule.
> Surely such an encryption algorithm would be an AEAD algorithm,
> therefore there is no such interaction (since the rule still
> applies).

You truly believe that, for the entire lifetime of SSHv2, nobody will
ever come up with another way to roll tamper-evident-ness in with
encryption (or at least won't want to use such a thing with SSHv2)?

I find that...dubious, at best.

> Of course, Jeff's KEX_OPTION packet type needs negotiation too!

I don't see why.  Send it and let it get handled or rejected.

(I do not favour mollycoddling implementations that can't be bothered
to implement the spec's mandate for handling packet types they don't
understand.  Such implementations are broken, and need to be widely
shown to be, and recognized as, broken.  Compatability hacks in
implementations are an implementation matter, but there's no need to
tie the hands of protocol design for the sake of tolerating
implementation bugs, especially ones this severe.)

/~\ 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