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

[Jeffrey Hutzelman <jhutz%cmu.edu@localhost>]

On Monday, July 21, 2003 15:39:46 -0700 Nicolas Williams 
<Nicolas.Williams%sun.com@localhost> wrote:

> On Mon, Jul 21, 2003 at 10:41:10AM -0400, Jeffrey Hutzelman wrote:

> > There is some question as to what to do with a keyex retry, and how to
> > authenticate it.  I don't see how KEXINIT2 helps us here, but I don't see
> > how Nico's chaining proposal helps either.  The KEXINIT message is
> > constructed as part of the exchange hash, which is computed by each keyex
> > algorithm when the exchange is complete.  If key exchange fails, there is
> > and can be no hash, and thus nothing to chain.
>
> I think we should proceed by:
>
>  - describing the semantics of KEXINIT extensions (just posted on this)
>
>  - extending KEXINIT in a separate I-D to include:
>
>     - a field containing the checksum of the concatenation of previous
>       packets relating to FAILED kex attempts (if any); this is where
>       "chaining" comes in (and note that this checksum need not be
>       specified on a per-kex method basis);

I'm not totally convinced.  It can't be a fixed algorithm; there has to be 
an upgrade path so we don't get screwed if the algorithm we choose turns 
out to be broken.  IMHO the simplest way to handle this is by just allowing 
the keyex to checksum the concatenation of the whole mess at the end, but 
maybe you have a better idea.

Is it necessary to record the complete set of messages exchanged?  I guess 
it probably is, since otherwise the attacker could DoS a better keyex out 
of the way to get at a worse one.

>     - text stating that peers must not disconnect when kex fails if
>       there remain any untried kex methods (including host key types);

MUST NOT is too strong, I think.  I'd be happy with a SHOULD NOT, with the 
idea being that you either disconnect or send a retry message, with a 
strong preference for the latter.

>     - a field for expressing kex/host key preferences as a list of
>       tuples to override any values of the 'kex_algorithms' and
>       'server_host_key_algorithms' legacy fields of the KEXINIT.

Yes.

> > I do think we need a mechanism to signal keyex failure and the start of a
> > retry, as well as to carry information about the failure.  To this end, I
> > will propose that when a keyex fails and retry is supported, a
> > SSH_MSG_KEXFAIL message is sent, possibly containing information about
>
> I don't think this is necessary when keyex fails on the client side - it
> just should send a new [extended] KEXINIT.

I'm not sure.  I'd have to consider the semantics of this carefully, to 
make sure we don't have a deadlock.  I think you're probably right, but 
I'll have to reread the transport document.

> > what combination of algorithms failed.  We can then assert that for the
> > purposes of computing the exchange hash, "the SSH_MSG_KEXINIT message"
> > actually consists of the concatenation of the KEXINIT message and all
> > KEXFAIL messages sent as part of the same exchange.
>
> I don't like the idea of modifying the existing session ID
> specifications because those are spread over three I-Ds and never
> envisioned that the session ID hash specs would change.

I'm fine with chaining, as long as you can show me a reasonable way to 
determine what hash algorithm to use.

> Details.  We want to negotiate tuples - how we encode them is not very
> important right now (and "dh-group1-sha1-pgp-sign-dss" is really an
> encoding for {"dh-group1-sha1", "pgp-sign-dss"}).

Agreed.  A better question is, can we solve the problem adequately using an 
encoding that fits everything into the existing key exchange process, or do 
we have to extend it.  I believe this has a significant impact on whether 
the work is too complex to be worthwhile, and on whether we will be able to 
get implementors to adopt it.


> The reason named fields are a good ide here is that we may only have ONE
> shot at using the reserved uint32 last field of KEXINIT  (once there are
> several values defined for it, not just two, the semantics of KEXINIT
> extensions negotiation become more complex...).  Of course, we could
> just keep appending an extensions field to every KEXINIT extension, to
> avoid this problem.  :) :)

I guess I was thinking in terms of defining the extensions field as a sort 
of sub-version, which grows as more extension fields are added.  Yes, this 
means the extension mechanism can only be used by IETF consensus.  That 
does not strike me as a problem in this case. :-)

-- Jeff