Re: Transport I-D: KEXINIT reserved field needs description

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

On Tue, Jul 22, 2003 at 09:00:58AM -0600, Joseph Galbraith wrote:
> Nicolas Williams wrote:
> >	 ["Implementations must be careful to include the entire
> >	   SSH_MSG_KEXINIT packets in the session ID hash, not just the
> >	   fields they know about." ??]
> > 
> >
> I do think we want the sentance clarifying that the entire KEX packet must
> be included in session id hash.  Should it say key exchange hash instead?
> Since only the first key exchange hash becomes the session id.

Hmmm, doesn't matter much if it's "key exchange hash" or "session ID
hash" since re-keying is protected anyways.  But yes, it probably should
say "key exchange hash."

And of course, KEXINIT extensions should apply to re-keying as much as
to the initial kex.

> I assume we don't want to define the extension format now because of 
> last call?

If we define the semantics of how we extedn KEXINIT we can let the core
drafts progress and describe any KEXINIT extensions in subsequent I-Ds.

> We might be able to use the extensions field as a count field:
[...]
> And give extension name the same semantics that is used else where in the
> document-- @dns name extendable.

This is like Joel's named fields proposal and it does sound reasonable
to me, though in this form it does mean that the extensions field is a
one-shot extension device, mitigated by the permanent extensibility of
the named fields.

> Remember, what is being extended here is algorithm negotiation, not
> (as the packet name might have you think) key exchange (well, key exchange
> algorithm is part of what is being negotiated.)

Yes.

> I wouldn't want to assume we are smart enough to anticipate all future 
> needs, or that everyone's needs will actually need to be standardized
> by the IETF.

Me neither.  As long as any extension to KEXINIT leaves in extensible we
should be ok.

> By allowing extensibility, we prevent those people that have needs not
> met by the IETF from producing broken, non-complaint implementations.

A very strong argument for Joel's and your named fields proposals.

> But this is all probably discussion for a new I-D.

Indeed.  A small amount of text will fix transport so we can fix KEXINIT
later.  Later is good too - we ought not hurry in this case, as long as
we fix the transport I-D.

Cheers,

Nico
--