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>]

> I do have a problem with it.  The reason the current KEXINIT sucks is
> that it negotiates two important aspects of the ultimate kex method
> independently.  While reversing the order of algorithm matching and
> treating the GSS-API mechanisms as "host key algorithms" would solve one
> problem we're dealing with I don't believe it to be a general solution.

What problem do you believe would actually be solved by the solution
you're proposing that isn't solved by the solution I'm proposing?  I
can see where you're proposing to introduce more generality, but I
don't see why anyone will ever benefit from that generality.

As I think I've said, it seems that you and jhutz think that someone
someday is going to have a burning desire to use group-exchange with
pgp and group1 with ssh-*, and I really don't see why that is going to
be especially useful.

> And then too, the selection of cipher algorithm maybe ought to have an
> impact on the selection of kex method - or else we should deprecate
> fixed-group dh kex methods (at the cost of an extra 1/2 round-trip or
> having the client always pick the group that satisfies the needs of the
> cipher with largest key size).

We can always introduce a fixed-group dh kex method with a larger
modulus later.  Chances are that the implementations supporting the
new fixed group are going to be the ones that support the support the
stronger encryption algorithms.

> I don't mind separating the one part from the other - I just mind
> treating that second aspect of kex methods (the host key or gss mech) as
> the same thing when they aren't obviously the same kind of thing.

So, stating that something is ``obviously [not] the same kind of
thing'' is not a useful way to communicate after we've had as many
round trips as we have establishing that we see things differently.
Can you explain why you believe this?

> Alternatively, we could break the key exchange and the key exchange
> authentication parts of kex apart and have a generic DH key exchange and
> a generic message exchange for signing the DH key resulting from the DH
> key exchange.  That way we'd need but a single key exchange method (or
> two, if the fixed-group (1 round-trip) vs. negotiated group (1.5
> round-trips) distinction is worth keeping) and a bunch of kex signature
> exchange methods (ssh-*, pgp-*, ... gss-*).  This may sound suspiciously
> like Joel's proposal, but the innovation here lies in changing the
> actual kex messages for the dh methods and getting rid of the gss kex
> name.

One of my goals was to avoid changing the actual key exchange
protocols, and change only the KEXINIT message itself.

I also suspect you'd end up adding a round trip or two in the GSSAPI
case if you did this.

>    Earlier I proposed the use of "alias" alg names to cure some of the
>    ills with KEXINIT that would solve the preference expression problem
>    that Joel had.

Ugh, but I suppose that could solve the problem.  (If I end up with a
client that does all of krb5, X.509, pgp, and bare host keys, I'll end
up listing 8 distinct algorithms, probably, assuming each of those
four types does both group1 and group-exchange.  Plus at the end I'll
end up listing diffie-hellman-group1 and
diffie-hellman-group-exchange, for a total of ten.  While this is
ugly, it is difficult to argue that it is a problem; I don't know of
any reason why listing ten algorithms will fail.)

>    We could also negotiate KEXINIT extensions through
>    the use of a bogus alg name.
>
>    If we then define the semantics of the reserved field of KEXINIT we
>    could add a field to KEXINIT (w/o revving the protocol version) for
>    chaining hashes of failed kex messages through to the next KEXINIT so
>    that the resulting session ID is bound to all kex messages and bingo,
>    we've got secure re-triable kex w/ downgrade attack detection and w/o
>    having to go back and modify the way each kex method defines the
>    session ID hash.

Right now, each kex method just includes the packet that negotiated
the algorithm usage in the hash.  The amount of code required to use
KEXINIT2 when KEXINIT2 is used is almost certainly less than this
chaining proposal.  And this bogus algorithm name also strikes me as
likely to add complexity.

> > > 3) The language optional field as it exists goes away.
>
> Why?  I agree that we don't need two sets of lang fields
> (server-to-client and client-to-server).  But we need a language
> negotiation for G11N.  And it has to happen _before_ userauth, and if it
> can be piggy-backed onto the kex then you save a round-trip - funny,
> that's how it is now, and it works too.

Because I want to treat it as just another optional field that has a
field name label, rather than having its mere presence there imply
that it is what it is.

I certainly want the language field content to remain just as
expressible as it is now.  (And shifting to only one field rather than
two was a mistake that came from not reading the draft carefully
enough to realize there were two, not from intending a change.)

> > Basically, the general idea is to create a new series of "magic" keyex
> > algorithm names (hm.. I see a theme here).  These would look something
> > like XX:diffie-hellman-group1-sha1:ssh-dss, with the 'XX:' a constant
> > defined in the spec.  There are some problems with this approach, which I
> > haven't yet had time to fully research; that's why I hadn't yet brought up
> > the idea.  But I'd much rather see a mechanism that allows negotiation of
> > { keyex, host-key } tuples rather than simply switching the order, which
> > doesn't eliminate the existence of a multi-level negotiation.

How does this interact with key exchange mechanisms and host key
mechanisms that contain at signs?

I think we need to figure out whether the problem of having extra
optional fields available is actually worth solving.  At one point I
thought it would be useful for SSH_MSG_KEXGSS_HOSTKEY public key
algorithm negotiation, but I no longer believe it is needed for that.
This leaves me feeling like I understand how to solve some problem
that might exist, without knowing what problem it solves.