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

[nisse%lysator.liu.se@localhost (Niels Möller)]

der Mouse <mouse%Rodents-Montreal.ORG@localhost> writes:

> 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. This gives unnececssary costs in both roundtrips
and computation, as well as in the implementation complexity that
comes with an extra negotiation round.

> 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 (and that all algorithms can be selected
independently, except for a somewhat vague dependency between
key-exchange algorithm and hostkey algorithm). With aead, this
assumption is not quite valid.

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.

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. And we won't do that, if we agree that
any algorithms with intimate dependencies between encryption and mac
should go inte the encryption list rather than the mac list.

Analogously, if we specify a keyexchange algorithm with integrated
server authentication (say, using SRP or something like that for the
key exchange), we can say that the hostkey algorithm is moot and
ignored.

> 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.
And if you want to avoid such problems by specifying in more detail
what the policy behind the renegotiation should be, then I'd much
prefer to specify *explicitly* what it is you want to achieve, e.g.,
that no mac should be used together with AEAD, and then implement that
policy at both ends with no extra negotiation.


BTW, I'm also curious about the motivation for the GCM mode. I just
had a first reading of the spec
(http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf).
The structure is almost the same as CTR mode with a separate MAC. The
only way I can make sense of it is if (i) GHASH is significantly
faster than common macs such as hmac-sha1, and (ii) GHASH has
properties that make it usable for GCM, but not suited for use as an
independent MAC. Is that the case, or what's the point?

Regards,
/Niels