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

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

>> 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.
> Can you substantiate that feeling?

Of course not.  How can one substantiate a prediction about the future?

> We have one magic interdependency already (keyexchange/hostkey),

Hm, that's true.  Ugh.

I still don't like it, though; this argument feels like "we made this
mistake already in the past, so we might as well make it over again in
a different way here".  (Yes, I realize this phrasing of it is somewhat
question-begging, in that it assumes it _is_ a mistake.)

More generally, there are two aspects of this AEAD thing that are
relevant: there are compatability properties (eg, encryption using an
algorithm with a (notional) "aead" property means using a MAC algorithm
with a similar property (and only "none" has the "aead" property)), and
there are negotiation order dependencies (MAC negotiation depends on
encryption negotiation).

It's true that each of these is present in kex/hostkey (compatability,
in the form of "encrypt" and "sign" properties, and ordering, in the
form of "hostkey negotiation depends on the outcome of kex
negotiation").  But I don't see how that justifies introducing more of
either.

> My view is that I don't see much practical or aestetical problems
> arising from this particular "magic" dependency, which I think is
> similar in spirit to the key exchange/hostkey dependency, and that
> the alternatives are worse because they bring more complexity and
> hence more bugs.

I agree that this is similar in spirit to the kex/hostkey dependency.
But, as I said above, that doesn't justify it to me.

Are the alternatives worse?  I think this is true only if you restrict
yourself to a very small subset of the available alternatives - for
example, if you insist on doing it within an SSHv2 framework.  SSH is
not the be-all and end-all of secured communications, and it does not
mean there is anything wrong with either SSH or AEAD if the two don't
play nice together.

The more I think about this, the more I think what's really bugging me
about it is yet another form of the cross-product problem.  Algorithm
negotiation order can be dealt with; each partial order dependency can
be registered - separately - with dependency registrations rejected
when they would introduce dependency cycles.  But the algorithm
property problem is much harder.  We've got two properties ("sign" and
"encrypt") applicable to kex algorithms and host-key algorithms; this
AEAD thing introduces another property ("integrated-mac", say) which
applies to encryption and MAC algorithms.  To do this right (ie,
without ambiguities) requires that every new algorithm specify what
value it has for every previously-defined property, and every new
property specify its value for every previously-defined algorithm.
This becomse a huge - and fairly sparse - matrix, and a tremendous load
on proposers of new algorithms or properties, since they must
understand all propertyes (resp. algorithms) enough to figure out what
values to specify.  It also is a practical problem in the presence of
private algorithms and/or properties, or in the presence of multiple
people working on different algorithms and properties simultaneously.

> I'm strongly against adding new general option or negotiation
> frameworks just to support aead.  That's simply not worth the effort.

The point is that they _aren't_ "just to support aead".  If they were,
yes, it would not be worth the bother.  They are to support aead _and_
whatever other now-unforeseen issues arise down the line -
future-proofing, if you will.  Trying to solve the immediate problem
right and thereby solve various future problems as well, rather than
solving the immediate problem with a kludge that doesn't help and quite
likely may actually hinder solving future problems.  Akin to the remark
in the jargon File that "[r]eal hackers [] generalize uninteresting
problems enough to make them interesting and solve them - thus solving
the original problem as a special case".

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