Re: KEX problems

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

On Monday, July 21, 2003 09:12:07 -0700 Nicolas Williams 
<Nicolas.Williams%sun.com@localhost> wrote:

I'm glad that we pretty much agree on what the problems are.  You seem to 
have omitted the rekey-without-host-key problem, which I called problem 
(1), probably because it's only peripherally relevant to this discussion. 
I would like to hear more comments from people as to whether problem (1) is 
worth solving and whether the solution I described (rolling the semantics 
of Joel Weber's 'none' hostkey algorithm into the 'null' already described 
in the gsskeyex document) is the correct solution.  I believe the answers 
to both questions are "yes", but confirmation would be nice.


I think I need to disagree with you slightly on priorities for the other 
problems...


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

> IMO, problem (C) is the simplest to solve and does not require modifying
> the key exchange part of the protocol.

Well, no disagreement here.  Of the three problems you listed, this is 
clearly the simplest to solve, and I think we have already achieved 
concensus both that this is worth solving, and that the general approach 
we've discussed is correct.  Hopefully we'll have an I-D in short order, 
and people can comment on whether the specifics are right.  I would like 
some opinion from the WG members and the chair as to whether this should be 
a working group item or not.

> IMO, problem (A) is the problem least worth solving, but if we solve (B)
> then we should consider solving (A) as well.

This is the multi-level algorithm negotiation problem, which I called 
problem (3).  I can only partially agree here...  If we solve (B), we 
should certainly consider solving (A), since it's clearly possible to do so 
if we're extending the key exchange anyway.  However, I think it may also 
be possible to solve (A) without modifying the key exchange mechanism, by 
using an alias-based approach.  If such a solution is sufficiently simple 
and actually meets the need, then I think the bar should be significantly 
lower than for a solution which requires modifying or extending the key 
exchange.

> IMO, problems (A) and (B) can be solve backwards compatibly through
> extensions to the KEXINIT message (see its 'reserved' field).  For this
> we'd need draft-ietf-secsh-transport to have some text describing the
> meta-semantics KEXINIT extensions and their negotiation so that problems
> (A) and (B) can be solved in a separate I-D.  I will submit a last call
> comment on this point.

Agree.

-- Jeff