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

[Jeffrey Hutzelman <jhutz%cmu.edu@localhost>]

--On Wednesday, April 15, 2009 11:01:58 PM +0200 Niels Möller 
<nisse%lysator.liu.se@localhost> wrote:

> Jeffrey Hutzelman <jhutz%cmu.edu@localhost> writes:
>
> > What I'd suggest instead is defining a unique MAC alogrithm for each
> > AEAD encryption algorithm, which has the same effects as null but is
> > usable _only_ when the corresponding encryption algorithm is selected.
>
> I'm not sure I follow precisely what you mean, but I think the
> important structural change is that we say that should apply algorithm
> selection to the encryption algorithm first, before selecting the mac
> algorithm.

Yes, we need to say this.  The base spec makes the corresponding assertion 
for keyex and host key algorithms, though with a bit of a twist:

- keyex negotiation comes first, but the only algorithms considered are
 those whose needs are met by at least one host key algorithm the two
 peers have in common
- host key negotiation comes next, and the only host key algorithms
 considered are those which meet the needs of the selected keyex

In the case of encryption and MAC algorithms, I don't think we should have 
this sort of bidirectional dependency.  Rather we should simply say that 
the encryption algorithm negotiation happens first, which then allows us to 
modify the MAC algorithm in ways that depend on knowing which encryption 
algorithm was selected.



> Then the result of the selection of the encryption algorithm may
> trigger special behaviour when it comes to the MAC algorithm. The
> naive rule "If an AEAD-algorithm is selected for encryption, no other
> MAC is used, and it doesn't matter whatsoever what's on the MAC
> algorithm lists" is simple and I think it should work, although I'm
> open to other variations.

I'd prefer not to have that particular rule.  I think it would be better
to explicitly describe a MAC algorithm which does nothing has no effect,
and do one of these:

a) Define a rule that allows a MAC algorithm to depend on a particular
  encryption algorithm (or a particular set of algorithms), such that
  that MAC algorithm can be considered only if the selected encryption
  algorithm is one of the ones it depends on.  Then define multiple
  do-nothing MAC algorithms, one per AEAD encryption algorithm, and
  make them depend on the corresponding AEAD algorithm.

b) Allow a MAC algorithm to depend on encrpytion algorithm properties,
  in the way that keyex algorithms depend on properties of host key
  algorithms.  This means that such an algorithm can be considered
  only if the selected encryption algorithm has whatever property it
  depends on.  Then specify a single do-nothing MAC algorithm which
  depends on AEAD encrpytion algorithm.

One of the advantages of either of these approaches is that one can choose 
to use a traditional MAC in addition to an AEAD encryption algorithm, if it 
is discovered that the integrity-protection properties of the AEAD 
algorithm are weaker than previously thought.  This would be a fix that 
could be quickly deployed by making configuration changes using existing 
MAC algorithms.  Approach (a) has the additional advantage that such a 
workaround can easily be applied only to specific AEAD algorithms.



> Implementations not supporting AEAD need of course not know or care
> about this rule. A party that advertises only AEAD-algorithms for
> encryption can safely list "none" as the only MAC algorithm (IIRC,
> it's not allowed to send an empty list, and any value, not just
> "none", will work just as well), negotiation with a party not
> supporting AEAD will then fail in an orderly manner.

... unless someone decides to implement "none" and not AEAD.

-- Jeff