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

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

>> However, it is fairly easy to offer enc=aead,3des-cbc mac=hmac, and,
>> if that negotiation succeeds, immediately re-kex with enc=aead
>> mac=none.
> I'd consider it a spectacular failure of the ssh-with-aead
> specification if use of AEAD in the intended way (as both encryption
> and mac, with no additional mac) requires two rounds of keyexchange
> at connection startup.

There's not much choice, though, unless you either (a) break the
existing protocol design (eg, by having some encryption algorithms,
when chosen, magically rewrite the rules for MAC algortihm selection)
or (b) risk ending up with a bad match (like 3des-cbc/none).

>> That would be a rather unpleasant violation of the existing
>> definition.
> Well, the current rules are based on the assumption that encryption
> and mac are independent

Right.  This is a bad match for AEAD.

Experimental protocol redesign work (coming up with a good way to tie
algorithms together for negotiation) is a sane idea.  Trying to
shoehorn it into the existing protocol with magic level-violating
semantics for certain algorthm names is not.

IMO, of course.

If ssh starts going down that road, another dozen or so "special cases"
later it'll be a horrible mess of magic interdependencies, with
determining whether negotiation _can_ succeed bordering on NP-hard.

> (and that all algorithms can be selected independently, except for a
> somewhat vague dependency between key-exchange algorithm and hostkey
> algorithm).

What's vague about it?  kex may need signatures and/or encryption; host
key algorithms may provide signatures and/or encryption; host-key
algorithms that don't provide what the negotiated kex algorithm needs
are effectively removed from the algorithms lists.  (4253 7.1, p. 18.)

> I can understand your concern, but I think it's quite natural to
> require that if an implementation supports and advertises an aead
> algorithm, then it is aware that selecting aead for encryption makes
> the selection of mac algorithm moot.

That's reasonable.  The problem is, the protocol we have has no way to
express it.  I see three choices: (1) we can suffer an inefficiency
necessitated by this mismatch; (2) we can go back into experimental
protocol design to come up with a protocol that supports such
dependencies properly; (3) we can violate the existing protocol with a
magic interdependency and hope it doesn't break anything too badly.

(3) is what I wish to discourage.  It's just begging for trouble down
the line.

> We won't get into any real trouble for doing that until we also
> specify that if a particular mac algorithm is used, the encryption
> algorithm should be ignored.

Or some other set of cross-linked magic dependencies end up requiring
something effectively similar.  If we do this, it won't be the last
such piece of negotiation magic, I'm sure of that.

>> I'd much rather just re-kex if using a none MAC is that important.
> I also find it brittle to renegotiate with a subset of the previous
> algorithms, in particular when you exclude one of the *selected*
> algorithms.  Imagine that both sides attempt renegotiation, and that
> they do it slightly differently.  Then the connection may fall apart.

Yes; buggy code can break things.  This has always been true and always
will be.  I don't think requiring any implementation that supports
enc=aead to also support mac=none, at least when using enc=aead, is
unreasonable.  I certainly consider it less bad than violating the
existing algorithm negotiation protocol.

I think my preference for doing this within the existing protocol
framework would be a "suppress-mac" option (to dig out the
options-packets subthread), with AEAD-supporting implementations
expected to use it if AEAD is chosen for encryption.

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