IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



Jeffrey Hutzelman wrote:
--On Thursday, April 16, 2009 12:35:15 PM +0300 "Timo J. Rinne" <tri%ssh.com@localhost> wrote:

Niels Möller wrote:
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.

This makes sense to me. I'd prefer this option, then. The name could
be "none-if-aead".

I must say I really hate this one.  Instead of one simply defined "magic"
cipher algorithm name that would have, if selected, a side effect of
abolishing MAC, we would have a "magic" MAC name with much more
complicated interdependency to cipher list.

To make it even more clear, the cipher name for aead could me something
like "aes128-aead-nomac".  Then if someone likes to implement aead with
additional mac (I don't know why anyone would do that) then
"aes128-aead%foo.bar@localhost" kind of name could be used.

The problem is, it's not _one_ simply defined "magic" algorithm. It's an arbitrarily large number of them.

But if we're going to go with Nico's "simpler" proposal, we need to address the question Niels brought up -- does selecting an AEAD type mean we don't do MAC selection at all, or does it mean we do MAC selection and then don't actually do anything with the resulting MAC?

The question is important because it controls what happens when an AEAD algorithm is selected but there is no mutually-supported MAC algorithm. One answer is simpler to implement, because it doesn't actually change the selection algorithm at all, but the other provides more interoperability. And, Niels brings up a third possibility of somehow noticing when only an AEAD encryption algorithm will work and filtering out all of the others, which seems really complicated to me.

I can live with both options 1 and 2. I agree that changing kex algorithm selection logic would be more complicated than requiring common mac to be found even in the situations where it's eventually ignored. I'd be inclined towards the simpler option.

Additional option might be introducing a mac name (could actually be used in ciphers and compressions too) that would be "fail-if-used". That would be put to the tail if mac list if aead modes are used as possible ciphers. In case some other mac is selected with aead cipher, it's simply dropped, if "fail-if-used" is selected with aead, it's dropped as well. In case "fail-if-used" mac gets selected with a traditional cipher it will fail in some implementation dependant way.

--
Timo J. Rinne <tri%ssh.com@localhost>        Valimotie 17       +358 20 500 7000 T
Chief Technology Officer           FIN-00380 Helsinki +358 20 500 7397 F
SSH Communications Security Corp.  Finland            http://www.ssh.com



Home | Main Index | Thread Index | Old Index