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

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

Jeffrey Hutzelman <jhutz%cmu.edu@localhost> writes:

> Yes, it is.  The twist you describe is complicated.  It's a funny
> special case.  What's going to happen when we have another funny
> special case?

We already have another one, which we may learn from: The rules for
the keyexchange algorithm! (Section 7.1, RFC 4253)

I have now reread these rules. Mirroring these rules for the current
situation, we get the following:

         The following algorithm MUST be used to choose a an
         encryption method (independently for each direction): Iterate
         over client's encryption algorithms, one at a time. Choose
         the first algorithm that satisfies the following conditions:

         +  the server also supports the algorithm,

         +  if the algorithm is not an aead algorithm (i.e., needs
            separate mac), there is a mac algorithm, different from
            "none-if-aead", on the server's list that is also
            supported by the client.

         When processing the mac algorithm lists, consider the client's
         mac algorithms, one at a time. Choose the first algorithm
         that satisfies the following conditions:

         +  the server also supports the algorithm,

         +  if the selected encryption algorithm is not of aead type,
            the algorithm must be different from "none-if-aead".

The final condition matters only if "none-if-aead" occurs on both the
client's and the server's lists, which is why implementations that
don't support aead need not know about the updated selection rules.

A different, more general, way to state the same selection rules would
be as follows:

  1. When an algorithm on a lists of type A has a requirement on the
     selection of algorithms of a different type B (current examples:
     A = key exchange, B = host key algorithm, or A = encryption, B =
     mac in the same direction), check if there is some common entry
     on the client's and server's type B list that satisfy the
     requirement. If it does not, delete the entry in question from
     list A and continue.

  2. If the type A algorithm that is selected has a requirement on the
     type B selection, delete all entries on the type B lists that
     don't satisfy the requirement. By (1), the remaining lists have
     at least one common element.
     
As long as we don't introduce any circular dependencies, this should
work just fine. (I haven't thought much about the case that A depends
on B which depends on C, but as long as there are no cycles, I'd
expect that should not cause any fundamental problems).

We could ignore the problem for AEAD, but I think there's a value in
consistency. The problem key exchange / host key is very similar, and
then it makes a lot of sense, at least to me, to reuse the same
solution.

Again, it would be nice to hear from someone who has actually
implemented the above logic if it works well in practice. (My
implementation uses only signature algorithms and only dh keyexchange,
so it's not an issue, so up to now, I haven't cared much about it).

Regards,
/Niels