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

[since my understanding is that Bill has asked us to not discuss how
to solve the problems we are trying to solve until we figure out what
problems we are trying to solve, there are some parts of your message
that I am not replying to here.]

> Joel, I think you're failing to see the big picture.  You seem to be
> seeing the multi-level negotiation problem only in terms of the mechanisms
> that exist today.  You talk about wanting to prefer a traditional exchange
> with PGP-signed keys over GSS-krb5, and GSS-krb5 over an exchange with
> non-PGP-signed keys.  That's all well and good, but you are proposing a
> "solution" which assumes that the _only_ alternative algorithm you'll ever
> want to put in the second slot is a GSS-based one, and fails to have any
> benefit in any other case.

I don't think that's true.  I even mentioned a hypothetical example
involving an srp kex algorithm when I said ``here's a list of possible
kex algorithms and ``host key'' algoithms; if we invert the order of
negotiation, why won't my proposal work?''

> When I point this out, you seem to think I am thinking of some situation
> in which the second slot is occupied by diffie-hellman-group1-sha1 or
> group exchange, combined with pgp-* or ssh-* host keys.  I am not.  I am
> envisioning a situation in which the second slot is occupied by a
> yet-to-be-defined keyex algorithm, or perhaps an existing one which uses a
> yet-to-be-defined host key algorithm.  Since both of these spaces are
> highly open to future extension, it is unacceptable to dismiss potential
> extensions as irrelevant.  The problem is a general one, and requires a
> general solution.

What sort of new requirements do you think we'd get using a new host
key algorithm with an existing key exchange algorithm that provide
different problems than negotiating PGP vs X.509 vs a bare ssh host
key?  As far as I can guess, while the future is very much open to new
host key algorithms in this space, the problems in negotiating them
shouldn't be any different than what we have with the current
algorithms.

And what sort of new requirements do you expect would exist with new
host key algorithms?

If you could give a concrete example of a hypothetical new algorithm,
even if it had a few properties which were rather contrived, and
explain why it would have substantially different negotiation
requirements, I'd probably have an easier time understanding.

I think at some point in the past I may have also pointed out that
the current multilevel approach doesn't do the right thing if you
introduce key exchange algorithms that support encryption rather than
signing keys, and pgp-encrypt-dss, ssh-encrypt-dss, etc, and that
switching the host key vs key exchange algorithm order ought to fix
the problems with that, too.  Of course, I'm assuming that the thing
you care about primarily is being able to pick the most trusted
trusted-third-party scheme, since in practice host key verification
seems to be the weak link.

I just got thinking that another question we might consider is what
happens when you have an ssh server that wants to provide multiple
X.509 keys, each signed by a different CA.  (Last time I dealt with a
well-known CA, I distintively remember them not handling the private
key, but let's hypothetically assume a world where the CA hands you
the private key and the public key; it's probably a good thought
experiment for understanding what problem we're trying to solve if
we're going for generalization.  And I'm also not sure if the X.509
standard allows you to get your cert signed by more than one CA.)  I
could imagine solutions involving an extra field to negotiate which CA
to use; or creating x509v3-sign-rsa-verisign, x509v3-sign-rsa-thawte,
x509v3-sign-rsa%joelweber.com@localhost, etc, though I don't think either of
these schemes is necessarily ideal.  The latter at least could be done
in a way that doesn't require any changes to the negotiating
infrastructure.

I'm starting to think that the last paragraph may be an argument in
favor of doing a KEXFAIL message with a reason code, where the reason
code indicates what kind of retry to do.  Because for some failure
modes, retrying the same thing with a different key is an option.  In
the extreme case, consider a GSSAPI mechanism where both the client
and the server have alternate credentials.  I don't think that KEXINIT
has much hope of being the right way to efficiently negotiate what to
retry when in that case.

> Currently, solutions to (1) and (2) are defined by every "key exchange"
> algorithm, which results in a lot of duplication.  For example, it means
> that group exchange needs to be defined separately for every algorithm, as
> does the exchange hash.  I agree that this is an unfortunate situation,
> and that it would be better had these operations been separate.  However,
> I also feel that, for those host authentication algorithms which require
> the use of public-key encryption, it would be as inappropriate to bind the
> key type to the host authentication algorithm as it is to bind key
> exchange to that algorithm, or the symmetric cipher used for the session
> to the particular key exchange method used.

Why is it inappropriate to bind the public key algorithm to the key
exchange algorithm, yet appropriate to bind a GSSAPI mechanism to a
key exchange algorithm?

> > > 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.
>
> Joel...  Why is this?  Is the solution of adding a transport message to be
> used for host key exchange after keyex is complete acceptable to you?

Yes, a transport message to deal with that is acceptable to me, but it
was fairly recently that I realized that it was a valid option.
Indeed, I believe that I will end up wanting to define such a message
for PGP regardless of what GSSAPI ends up doing, though if it's
possible to use the same message for both (and I believe it is) I'd
like to do so.

(In practice, I believe that openssh has bugs such that we probably
want to recommend that you wait until after you've established a
connection with the userauth service before sending that transport
message, but I believe the IETF spec ought to allow its use anytime
after SSH_MSG_NEWKEYS.)

> > > This leaves me feeling like I understand how to solve some problem
> > > that might exist, without knowing what problem it solves.
>
> Indeed, while I thought the named-field idea was a good general extension
> mechanism when you proposed it, I'm not convinced it's necessary right
> now.  Perhaps we should drop it, and focus exclusively on multi-level
> algorithm negotiation and the possibility of keyex retries...

Probably.