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 07:40:00PM -0400, Jeffrey Hutzelman wrote:
> On Monday, July 21, 2003 15:39:46 -0700 Nicolas Williams 
> <Nicolas.Williams%sun.com@localhost> wrote:
> 
> >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.

First extended KEXINIT pair of messages has no chained checksum - it
would have to have a field for negotiation of hash functions.

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

Agreed.  This is the crucial decision we'll have to make.

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

Ok.

Nico
--