Re: SSH_MSG_KEXGSS_HOSTKEY (was: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt)

["Joel N. Weber II" <ietf-secsh%joelweber.com@localhost>]

> What problem are you trying to solve that treating GSSAPI mechanisms as
> host keys will solve?  The multi-layer negotiation problem (keyex must be
> selected before host keys) is not unique to GSSAPI, and treating GSSAPI
> mechanisms as host keys makes the problem _WORSE_, not better.

Note that I proposed making two changes together (each GSS mechanism
is a host key algorithm, and you negotiate first on host keys rather
than first on key exchange algorithms).  It's obvious that if you make
either change without the other, the situation gets worse than it is
now.

However, I believe that if you make the two changes together, you
solve the problem I want to solve.

> I think you're limiting your vision to the mechanisms you happen to see
> today, and what you can think of yourself using.  All of the algorithms
> are replaceable, which can lead to arbitrary combinations, including
> algorithms not presently in use.  For example, you'd have exactly the same
> problem if you substituted the SRP algorithm that was discussed in another
> thread instead of one of the GSS algorithms.

How would this fail?

If my host key algorithms are

pgp-sign-rsa,pgp-sign-dss,Se3H81ismmOC3OE+FwYCiQ==,srp,[GSI],x509v3-sign-rsa,x509v3-sign-dss,ssh-rsa,ssh-dss

and my key exchange algorithms are

diffie-hellman-group-exchange,diffie-hellman-group1,gss-group-exchange-sha1,gss-group1-sha1,srp

(assuming for the moment that srp ends up being its own keyex
mechanism and not a GSS mech, not that it matters for this discussion)

I don't see why going through the list of host key algorithms, finding
the first one that will work, and then picking the first suitable key
exchange algorithms will fail.

> The problem is a general problem; let's use a general solution.

Yes, but we shouldn't design in generality that doesn't provide value,
which I think your tuples proposal does.