Re: KEX problems

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

On Mon, Jul 21, 2003 at 05:20:56PM -0400, Jeffrey Hutzelman wrote:
> On Monday, July 21, 2003 09:12:07 -0700 Nicolas Williams 
> <Nicolas.Williams%sun.com@localhost> wrote:

I too am glad to see that we're mostly in agreement.

> >IMO, problem (B) is the problem most worth solving, but it requires
> >extending the key exchange phase of the protocol, one way or another.
> 
> IIRC this is what I called problem (2), the keyex retry problem.  I'm not 
> sure whether it occurs often enough to be worth solving; I'd love to hear 

You need only have two kex methods (in any permutation with host key
algs) to trigger this problem from time to time.

Whereas you need at least three for problem (A), at least two of which
must be the traditional kex methods, and at least one of which must not.

I think (B) is much more likely than (A) - and I have experienced it
myself; I have never experienced (A).

> comments from people other than you, me, and Joel on this point.  I do 
> agree that solving it requires extending the keyex protocol, probably along 
> one of the three general paths I described in my message, none of which are 
> terribly appealing to me.  I believe the bar to be passed before solving 
> this problem should be rather high.

I agree, but I think we MUST fix the transport I-D wrt KEXINIT
extensibility.  If we do that now then we can wait till later to solve
(A) and/or (B).

> [...]
Yes, you can solve (A) with aliases.  You can also solve (B) with the
"bogus" alg name approach (and modifying the session ID specs to include
the failed kex attempt's messages in the session ID hash).

Before we do either we really ought to fix the transport I-D wrt KEXINIT
extensibility, and in the process find out what implementations do today
about extended KEXINITs.  Though I've proposed the alg aliases/bogus alg
approach I think extending KEXINIT is the right approach and the clean
approach.

Cheers,

Nico
--