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

[Nicolas Williams <Nicolas.Williams%sun.com@localhost>]

On Mon, Jul 21, 2003 at 10:41:10AM -0400, Jeffrey Hutzelman wrote:
> On Fri, 18 Jul 2003, Nicolas Williams wrote:
>
[...]
> Hm.  On some reflection, I don't believe the bogus algorithm name is
> necessary to prevent a downgrade attack, nor do I believe that a KEXINIT2
> message is required.  It should be sufficient to define a non-zero value
> of the reserved field to indicate that additional fields follow.  These
> fields should include advanced algorithm negotiation information (such as
> I described above, or whatever we end up agreeing on) and also a boolean
> to indicate whether keyex retries are supported.

Right, I've been toying with this.  We need to have the transport I-D
fixed to describe the semantics of the last field of KEXINIT.  I just
posted separately about that with proposed I-D changes.

> 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);

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

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

> I also don't believe it's necessary to repeat algorithm negotiation in the
> case of a retry -- just go on to the next algorithm in the selection
> process, as if the one that just failed had not been available.  However,

Correct.

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

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

Whereas including a hash of the failed key exchange method's packets in
subsequent kex attempts results in binding the failed attempts to the
subsequent attempts without having to change the actual kex methods.

I much prefer the latter as it will result in a cleaner document.

[...]
> > I don't know what Jeff had in mind, but in my proposal these would be
> > aliases of existing kex methods - taken to be limited to subsets of the
> > host key algorithms - so any implementors of non-standard kex methods
> > would not be affected (and to take advantage of this they'd have to
> > define their own aliases).
> 
> Actually, my proposal was intended to model the semantics of Nico's (I'll
> freely admit that's where I got the idea), in which these new things are
> aliases of existing kex algorithms, with limitations on what host key
> algorithms could be used.  However, I was going for a general solution, in
> which aliases would not have to be explicitly defined "by hand" for each
> possible combination -- IMHO this is always a good thing when the things
> being combined are defined independently, as keyex and host key algorithms
> are.

:)

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"}).

> In this context, Joel's question about the handling of '@' indeed makes
> sense.  I don't yet have a good answer; probably the '@' would be mapped
> to some other character, such as '%', with a quoting mechanism for literal
> occurances of '%', ':', and whatever the quoting character is.

I think we can come up with a tuple encoding that preserves @ signs.
Again, details.

> Unfortunately, there is a fixed limit on algorithm name lengths, so I
> don't yet see how my proposal can work.  I suppose we could have a model
> in which we use a hash if the concatenation is too long, but I'd prefer
> not to make implementations compute hashes of all the possible
> combinations just to see what the peer supports.  Hm...

With a new field for negotiating kex/host key type tuples the length
issue can go away.

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

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.  :) :)

Nico
--