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:

>> (and that all algorithms can be selected independently, except for a
>> somewhat vague dependency between key-exchange algorithm and hostkey
>> algorithm).
>
> What's vague about it?

Maybe it's not vague, it's long time since I thought about that. Maybe
that impression came from the fact that there's no widely supported
key exchange method that needs a public key encryption, so it's rarely
making a difference.

> 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? We have one magic interdependency
already (keyexchange/hostkey), introduced in the original spec some
ten years ago. Now we're discussing another one, from the introduction
of algorithms with "simultaneous" encryption and authentication. I
doubt we'll have to do things like that very often. New cryptographic
primitives, useful for this kind of protocol, don't appear very often.
Do you see any other potential magic dependencies down the road?

And if there are any conflicts in the future, say, with the
introduction of foo-mac, which we can't handle in any better way, we
could handle it by specifying that an implementation MUST NOT
advertise both the deprecated aead algorithms and foo-mac, and maybe
also deprecate the aead stuff we're discussing now. But I honestly
don't find that scenario very likely.

So what I'm saying, is that I understand that you care to maintain a
clean and beautyful spec. 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'm strongly against adding new general option or negotiation
frameworks just to support aead. That's simply not worth the effort.
If we can't come up with a reasonable way to "shoehorn" it into the
current algorithm selection precedures, I'd prefer to say "Sorry,
aead-style algorithms were not envisioned when the ssh protocols were
designed. It can't be supported. Maybe it'll be supported in ssh
protocol version 3 in the very distant future.".

/Niels